Alexander Shukaev wrote:
> Dear Linda,
>
> It feels like Perl is not very trendy these days.
Trendy? How _trendy_ is international support? International and perl
support were the first things to be provided as optional modules not because
they were trendy, but considered essential. Perl is usually used for
'plumbing' type tasks. It hooks things together and can transform them.
However, it's hard to consider 'plumbing' trendy -- but one wouldn't build
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, 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...
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 core,
so 1.82 cores on a 12 core machine.
As a curiosity I wrote the exact same program in perl to see how it would
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+Sys)
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 they
are not loaded and -- if they don't use them -- they don't even need to be
on their machine.
> Support for that many languages was added because certain popular
> plugins are written partly (or fully) in these languages rather than
> Vim Script. 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 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 be
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?
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment