A response?

I'm trying to come up with a response that won't be offensive, but also point out reasons why perl should be included as well as why using trendy as a marker of 'inclusion' is really ... um... not serving the best interests of his audience (oh how politique).

I came up with something that, as usually, is a bit long, but I'm still not covering many points.

If anyone wants to point out better ways of saying things or better things to say, that would be great, as my persuasive skills are not so great. What I have at this point is:

 Alexander Shukaev wrote:
> Dear Linda,
>
> It feels like Perl is not very trendy these days.
Trendy?  How trendy is US English V. say UK english?  How about
Slovakian or Portugal?  Are they on the the trend list this year?
Should they be dropped?

Right now the trend is toward limiting user choice -- w/iphone and it'
+s
"walled-garden" being very popular.  They charge more / feature than
most other manufacturers, Users are expected to be "not bright" -- the
+y
can't be trusted to change a battery.  yet that's the current trend.

Trend is to put things in the cloud, more so, and give up home PC's an
+d
turn them into remotely controlled appliances (w/secure boot and
checksum'd software) making them more into game and entertainment
consoles than general purpose computing devices that allowed
circumvention of the previous controllers of what we "consumed" (i.e.
large publishers, the music industry that was mostly corrupt and
promoted a small cadre of "pop-stars", vs.  all the home made stuff th
+at
has come since the PC empowered individuals to publish their own
material (books (apple was sued and LOST for trying to promote deals
with the old publishers that would help them retain control); music an
+d
video.  Trendy is often a poor indicator of what is good.

The languages you cite are trendy because they are simple.  Python,
especially, is very good for teaching concepts because it restricts th
+e
user's choices and when asked to solve a problem, many will end up
looking very similar.  It is, today, what pascal was back in the late
70's.   A way to teach and use concepts and write libraries in.

But you say you haven't seen much in perl+vim -- how have you looked?
Or did you look at all?  Try "search.cpan.org" and search on "vim" I s
+ee
about 270 scripts that use vim as a debugger, or packager, wiki creati
+on
and editing packages, using LaTeX to do typesetting from vim, website
creation addons, and tons of system administration scripts.   Computer
system administration isn't very trendy -- but without it, you'd have
nothing you are using today.  No internet, no world connections, no
trends except what are set by the large corporations...

How about this -- how many filters can you write in python, without
using a separate file?  or -- more precisely, how many python 1-liners
can people easily write and use?   What is the option in python to wri
+te
and execute a line of code?  Can you write a 1 line python filter
capitalizes all occurrences of your name but deletes all occurrences o
+f.
Doing things fast and simple doesn't seem to be trendy -- people want 
+to
write "apps" to publish in the "app store".

How about multicore/multithreaded apps?  How trendy are those?

Recently someone did a program to test timekeeping in python.  It used
9 threads.  I completed in 67.35 seconds using 181.94% cpu (100%=1 cor
+e,
so 1.82 cores on a 12 core machine.

As a curiosity I wrote the exact same program in perl to see howit wou
+ld
perform (cuz I thought the MD5sum was slow)... turned on my head.

Same** program in perl 3.36 seconds using 870% cpu.

**-I didn't use any perl tricks -- I tried to follow the python
example as closely as possible (to see code for each, and
compare, see  http://www.perlmonks.org/?node_id=1076596).

So for the 9 threads:

lang    #thrds  #cores_used  %efficency   clocktime     cputime(Usr+Sy
+s)
python    9          1.82       20.2%        67.35s         122.53s
perl      9          8.70       96.7%         3.36s         29.23

>From the above, stated as percentages or multipliers,
perl is 478% more efficient in making use of multicore resources.

In real time, python takes 64 seconds longer over the base time
that was needed, of 3.36s.  Python is 1900% SLOWER.

Someone mentioned python might not be optimal in parallelism due to
threading problems.

So look at the actual amount of CPUtime used for each to do the work.
122.53/29.23.  For heavy number crunching, perl (with max precision
possible in x86-64 HW, takes less than 1/4th the time, i.e. perl
is 4.2x the speed of python.

Python may be trendy, but for getting actual work done, perl  is not
only considerably faster, but has most all the libraries needed to do
it's work *built-in*. -- know wondering about what to 'import'.

I could go on for WAY too long, on this, but lets look at who *sets*
the trends...

The most complicated and central function in text processing -- the
regular expression. 

Did python choose posix RE or extended RE syntax?  Nope.
javascript and python and most modern languages have copied the
perl's regex syntax and features -- and note-- perl has no problem
trying to make things *easier* for python developers.  When
perl implemented named subexpressions or captures in Regex's, in
addition to the perl syntax, the Python syntax as added as well
to make things easier for those familiar with that syntax.

Perl's Regex engine has been described as the 'best of breed' --
with java, javascript, ruby, python et al, all adopting the
Regex syntax developed in Perl.

If it wasn't for the groundwork laid by perl, you wouldn't be
doing scripting in the  other languages you are today -- as
they would have had to develop, "at least_,  their own regex engine.

Perl also, BTW has full unicode support, supporting the characters
*by name*.  No other language has this -- yet.

So ok, the other languages are more trendy -- but they are
as good as they are today because of the groundwork laid by perl.

Besides, you aren't really *adding* the languages to vim when you
create it -- aren't they ALL dll's -- that only load if the language
is used?

I.e. what you did is made a choice that *prevents* perl from being loa
+ded
as an option -- preventing current scripts from working, and new
ones being easily developed.  But for all of those languages (not sure
about lua), the actual support for them is in an external library -- s
+o
the users don't actually 'pay' for the languages they don't use as the
+y
are not loaded and -- if they don't use them -- they don't even need t
+o be
on their machine.

> Support for that many languages was added because certain popular pl
+ugins 
> are written partly (or fully) in these languages rather than Vim Scr
+ipt. 
> Python is probably the most popular language for extending Vim right
+ now,
> perhaps after Vim Script. Ruby goes next, then Lua. But I've never c
+ame
> across a single plugin which would rely on Perl to be honest. May I 
+ask
> why you think that Perl is so important for that Vim distribution?

#2 on the list for http://www.vim.org/sponsor/vote_results.php.
was an IDE.   You should check out:. https://metacpan.org/release/Vim-
+Debug.

It's already been done for perl and from the documentation it should
be extensible to other languages..but can't say for sure.  However, it
+ is written in perl...   

So honestly, you didn't come across a single plugin that would rely on
+ perl?
Where did you look?
[download]

Feedback? Corrections?...

Appreciated! I tried to stay civil and such, but it was pushing my buttons more than a bit...(*sigh*)...

Comment on A response? Download Code

Replies are listed 'Best First'.
Re: A response? by Discipulus (Canon) on Mar 12, 2014 at 09:57 UTC
Dear perl-diddler you have all my solidarity. Welcome in the world. Capital want to multiplicate himsefl: no matter what is good or beauty. They looks at trendy shiny (profitable) things. I think quite in the same way as you, but i think you would not reveal your emotions: sting them where they are more sensible, instead. I'm speaking about paragraph 1-3 and maybe 4 too in your presented answer. You are right there but think on the effect you provoke in the intended reader: "The medieval Perl writer has answered. Everyday the same crusade to defend good 'ol things.". Probably (as we know the person for the deep wise mail sent to you..) he stops reading very soon. Consider instead a subtle provocation in their delicate parts (cutting paragraph 1-4): Dear Alexander, Effectively Perl is no more as wide used as was some years ago. Thanks + for point this to my attention. Even if Perl is used by almost all L +inux and BSD distros, even if it is one of more used language to admi +nister crucial services over the Net, even if it is updated frequentl +y and new major realeases of the language had spread reguraly in last +s years, even if the Comprehensive Perl Archive Network (CPAN) curren +tly has 130,991 Perl modules in 29,153 distributions, written by 11,3 +03 authors, Perl now suffers the competition of some new launguages t +hat, wisely, Vim choosed to support. Many IT professionals, as me, had bring Vim to popularity as 'the prog +rammer editor' but we used Vim because of it's flexibility and wide p +urpose usability. Abandon Perl support force us to consider other opt +ions to continue administering a mess of petabytes of Perl code that +is running in this moment all over the world. Follow the trend of thinks, the evolution of the programming field, is + obviously a plus of Vim and for Vim's users, but break the compatibi +lty with a such historical, but still very alive and active language +as Perl may be not so wise. Viewing thinks by the point of a programmer please try "search.cpan.or +g" and search on "vim" I see about 270 scripts... [...] [download] Please consider all said as a personal tough, and rewrite it in good english as you can see is not my native language (it's Perl obviously..). Go on Linda and tell us the rest of the story. HtH L* There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.	[reply] [d/l]
Re: A response? by Arunbear (Prior) on Mar 12, 2014 at 18:30 UTC
The technical differences between Python and Perl aren't very relevant to this discussion (where the use case is extending Vim via Perl), and you will not do any favours to the Perl community by taking a (metaphorical) dump on Python. Perhaps you can simply point out that well known projects like PostgreSQL, Apache and Nginx all support extension via Perl, and that you and others would like to have the same facility with Vim.	[reply]
Re^2: A response? by locked_user sundialsvc4 (Abbot) on Mar 13, 2014 at 01:47 UTC
Another way to look at it is ... “do we really have A Problem here?” Most of us, I daresay, actually are well-versed in all of these languages. Chances are, many of us switch without pause between several of them every day. So, if Vim currently supports Python but not Perl, “hey, it’s really no big deal.” As long as we can write macros in the thing, one way or the other, “it’s all good.™” The digital computer doesn’t have to be versatile, since we are. So-o-o... is there, in fact, a business justification for Perl support in Vim (on all of the various environments that Vim is expected to simultaneously support)? ROI = Return On Investment? If the answer is “yes,” then I guess we need a Volunteer. If the pragmatic answer is “no,” that’s actually okay, too. Either way, it says absolutely nothing for/against Perl, “and ditto Python.” At the end of the day, all of them are just tools within our toolbox, and I think it’s kinda silly for a hammer to be arguing with a screwdriver. (I will very-diplomatically leave it as An Exercise To The Reader� which one is which ...) `;-)`
Re: A response? by syphilis (Archbishop) on Mar 12, 2014 at 11:51 UTC
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	[reply]
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]
Re: A response? by choroba (Cardinal) on Mar 12, 2014 at 09:09 UTC
The only problem might be the person. I know several people whose opinion, once they make their mind, cannot be changed by any means. Short e-mail, long e-mail, arguments, reasoning, fist fight, no way. I wish you Alexander were different. لսႽ� ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply]
Re: A response? by einhverfr (Friar) on Mar 25, 2014 at 14:49 UTC
Just a note. In an open source project, it is usually a waste of time to try to convince someone to change the project for your benefit. Nothing gets things done like volunteering to put in the effort. I would therefore suggest a different approach, namely: `Hi; I understand you don't have much use for Perl in vim but I do. I woul +d be very interested in helping to ensure that this is supported. I +understand that Perl is not as widely used on Windows as on Linux. Please let me know what I can do to make this happen. Any chance ther +e is some documentation available on how I can set things up to write + plugins in Perl? If I get it working, would you be interested in di +stributing it?` [download]	[reply] [d/l]