Something to meditate on -- the need for a trendy perl?

[perl-diddler]

New version of vim came out for windows... had x86 support -- went to look -- had support for running scripts in Lua, Ruby, Python 2 and Python 3 and no perl.

I asked if it was an error, and 1 version of perl might not be needed vs. 2 for python.

The reply I got:

Dear Linda,

It feels like Perl is not very trendy these days. Support for that man
+y languages was added because certain popular plugins are written par
+tly (or fully) in these languages rather than Vim Script. Python is p
+robably the most popular language for extending Vim right now, perhap
+s after Vim Script. Ruby goes next, then Lua. But I've never came acr
+oss 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?

Regards,
Alexander

I doubt benchmarks on multiple thread execution would be considered trendy. Ideas? Thoughts? Examples or counterpoints?

[zentara]

I think the problem is that college professors like heavily object oriented languages like C++, Python, Ruby, etc., because it makes their jobs easier. They just can't handle the freedom which Perl offers, as it makes grading student's code more difficult, with all the different ways Perl can do the job.

I think it's a reflection of the stodginess moving into corporate culture, where nobody wants risk, and they want all employees trained exactly the same. We are losing the lead in technology because of this mindset .... no risk, no gain.

[choroba]

I was a university teacher for several years. I quit half a year ago. I used Perl in my research, and I taught it to my students. The reason why my colleagues were shifting (mostly to Python) was different: laziness. They needed libraries for machine learning, and they already existed in Python. Maybe we, the community, are not working hard enough to keep Perl "trendy", whatever it might mean?

[LanX]

IMHO academics prefer axiomatic systems where a limited set of rules can be applied to derive the rest. Your colleagues can be lazy b/c other academics prepared the modules.

Maybe I don't know Python enough to tell, but it has this appeal ... while Perl is a pile of DWIM magic exceptions, which are fun for experienced coders who don't wanna miss their features from other languages (bash, sed, awk, c, lisp, ...) but do confuse many Asperger folks who only accept "one way to do it".

Ruby OTOH shows that it is possible to transport rich semantics into a more orthogonal syntax, by breaking compatibility to Perl5.

Should be noted that P5 never really broke compatibility to P4, thus giving it an incredible amount of obscure features and exception rules.

[zentara]

I thought laziness was one of the virtues of Perl? :-) The three virtues of Perl

[Arunbear]

"heavily object oriented languages like C++, Python ..."

What? C++ and Python are multi-paradigm languages where OOP is as optional as it is in Perl.

[zentara]

I stand corrected, especially for C++, but I still think of them being more OO than C or Perl.

From: everything is an object in Python :

"This is so important that I'm going to repeat it in case you missed it the first few times: everything in Python is an object. Strings are objects. Lists are objects. Functions are objects. Even modules are objects. "

[LanX]

Pythonistas like to claim having a multi-paradigm language and right in the next phrase they'll tell you that there shouldn't be more than one way to do it.

Perl for instance is far closer to LISP, lambdas (anonymous subs) are not restricted to one statement and Perl's my is provides a declaration like LISP's let lacking in Ruby, Python and to some extent even in JS.

I had the privilege to see a presentation of a Python module which was a port from Ruby, and it's almost ridiculous to see how they try to circumvent the limitations of their syntax to be able to reflect real lamdas ("code-blocks" in Ruby).

[perl-diddler]

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?

Feedback? Corrections?...

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

[Discipulus]

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...

[...]

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*

[Arunbear]

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.

[sundialsvc4]

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 ...)   ;-)

[syphilis]

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

[perl-diddler]

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).

[choroba]

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.

[einhverfr]

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?

[Your Mother]

I want to add that you're asking for a favor. Alexander's reply is perfectly cromulent. The onus in situations like this is on the requestor, not the provider. Be humble and deferential if you ask. vim+Win is a minor slice of the Perl dev world, trendy or not. When asking for someone to do work for free for you, remember to be and to act grateful.

[Anonymous Monk]

Locomotives are not trendy, either ... but, that is not what locomotives are for.

[LanX]

So VIM is trendy? (shrug! ;)

PS: honestly, the success of Ruby (which is semantically Perl plus a default OO system) shows that a trendy Perl was possible.

Take a time machine trip to 2000, put another lexer/parser on top of the P5 engine (still compatible to old modules) and give it a flashy name like "Brilliant (Perl)".

IMHO turning the wheel is still possible...

[Laurent_R]

choroba said: 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.

I am afraid you are right. I was definitely convinced by Linda's well-thought arguments, but, then, of course, there was no real need to convince me. Especially being a person who used Python for 2 or 3 years before switching to Perl about 10 years ago. Well, I keep telling 10 years, it is probably 11 years by now, as it was during the first quarter of 2003, if I remember the dates correctly (just checked the dates on my CV, yes, it was indeed in the early months of 2003). Even though I still think that Python is a nice language and certainly don't want to disparage it, I think someone trying to convince me to revert to Python would really have hard time.

I simply love Perl too much to be able to claim that I may be rational about that. And that's what I wanted to say: when it comes to programming language wars (or, say, language debates), most people are not or cannot be rational. I am not even sure that being rational about such topics really makes sense. After all, very often, the best language is often the one that you know the best.

Just as with spoken languages: if I want to express some very subtle idea or complicated personal feeling, I would probably prefer to use my mother tongue, French, because it is the one that I know best, but that does not prevent me to argue in English on this forum (and others), after all I passed a master degree in an American University: I certainly make some silly syntax mistakes, but I can (hopefully) express clearly what I want to express.

It is the same with programming languages: Perl has become what is closest to a native language for me, the language where I can be the most efficient, but I also have to use regularly half a dozen other languages (because I have to use a proprietary language for some applications, because C can be faster for some problems where speed matters, because I have to modify an existing application and cannot rewrite everything in another language, because the client wants PL/SQL scripts and does not want to hear about Perl Oracle modules, etc.). Although this is getting somewhat unlikely (I fell in love with Perl, I've never had a similar experience with another language), I might one day switch to another language, perhaps Ruby, Scala, Haskell or possibly some other new language that I might not even know about as of now. Very unlikely, though, that I would go back to Python or (even more unlikely) to the other dynamic language I used before Python, TCL. Perl is just better. Just as I would most probably not go back to Basic, Pascal, Fortran, ADA, Modula-2, Prolog and other languages I practiced in the past. In theory, I would also wish to avoid C, C++ and Java, but I know it is slightly more complicated, because they are dominant for some applications, especially as far as C is concerned.

[perl-diddler]

For better or worse, I sent the following response.

I rewrote more than one part due to feedback here... got rid of those first 3 paragraphs... thought about the locomotive example, but came up with plumbing as being a more relevant example.

Alexander Shukaev wrote:
> Dear Linda,
>
> It feels like Perl is not very trendy these days.
Trendy?  How _trendy_ is international support?  International and per
+l
support were the first things to be provided as optional modules not b
+ecause
they were trendy, but considered essential.  Perl is usually used for
'plumbing' type tasks.  It hooks things together and can transform the
+m. 
However, it's hard to consider 'plumbing' trendy -- but one wouldn't b
+uild
a house w/o plumbing because it isn't 'trend'.


But you say you haven't seen much in perl+vim -- how have you looked?
I tried  searching for vim plugins and scripts and adjuncts on
"search.cpan.org". I came up with about 270 hits.  Among those are
things that provide vim functionality to create IDE's debuggers,
packages, use for wiki creation to do LaTex typesetting from vim,  web
+site
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...

Maybe "utility" or "usefulness" should be considered before trendy (or
at least, as well)?  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?   Does python even have an option to 
execute a line of code from the command line or use it as a filter?

What is the option in python to write and execute a line of code? Can 
you write a 1 line python filter capitalizes all occurrences of
your name and replace all occurances of :-) with their unicode
equivalent, of a white smiling face (☺) using it's name "white
smiling face" .. could you do it in any of the languages you mention?
You can in perl.  It's the only language that has full unicode support
+.


Isn't multicore/multithreaded, 'Trendy'?

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 how it wo
+uld
perform (cuz I thought the MD5sum was slow)... I was turned on my head
+.

Same** program in perl took 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.

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

Aside from that, you are not really including the languages (are you?)
Aren't they DLL's that are loaded if present and not loaded if not
used?  Are you providing the DLL's for each language?  Usually, what
is added is the ability to load the DLL if it is present.  So really,
you don't need to include perl -- just the ability to make use of it
at run time if it is present, right?  Or did you really link all of
those languages in with your vim binary?   If that's the case...
then that's a bigger problem.

For most (all -- not sure about LUA) of those languages, the actual
support for them is in an external library -- so
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 Vi
+m Script. Python is probably the most popular language for extending 
+Vim right now, perhaps after Vim Script. Ruby goes next, then Lua. Bu
+t I've never came 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 b
+e extensible to other languages..   But it IS written in perl...

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

I thanks folks for the input. Yeah... at times I get a bit emo about topics dear to my heart.

[pmu]

Hi perl-diddler,

Forget Mr. Alexander's Vim...

Here's a version of vim that's compiled with Perl Version 5.18.1

http://tuxproject.de/projects/vim/

Unfortunately I am right now on Debian Wheezy, else I would have posted the vim version output.

On another note, please forgive Mr. Alexander. I mean, if that guy does not know that one can do ":% perldo s/dumbness/smartness/g" in vim (compiled with Perl Support), ain't his fault. He's got some learning to do. Pity him.

[perl-diddler]

Thanks for the pointer -- looks like they only have 32-bit right now.

I get spoiled when, *rarely*, I need to read in a multi-gig file and not have it spill to memory.

Also, windows usually runs a bit behind linux in terms of perl... Cygwin is still at 5.14, and I was going to suggest 5.16.3, myself, as I have a rather large code base that is incompatible with with some of the new 5.18 features.

As Murphy would have it, most of my small scripts and library routines aren't hit with the problem. The ones that are hit, are the larger(2-3k lines) and more complicated ones that do things like create and destroy file systems and partitions on a daily basis -- i.e. ones where you don't want anything to go wrong or rush through changes, and unfortunately, there was no way provided for a compatible upgrade (i.e. turn off the new conflicting features by default). Sigh.

[sundialsvc4]

There are just things in this world that usually are not worth the time actually responding to ... except for entertainment.   To me, things that mix programming languages with politics with conspiracy-theory, all in just one piss-cup, are one of those things.   A closed mind gathers no thoughts.™   It merely stitches-together irrelevancies to “confirm” what it already “knows.”

[Buk]

not worth the time actually responding to

And yet, you responded ...

[sundialsvc4]

As did you ... touché ... ;-)

[Anonymous Monk]

Perl is old and dying. More news at 11.

[Anonymous Monk]

Old is not dying. More news at 11:30:14.