Scripting languages are higher level than system programming languages, in the sense that a single statement
does more work on average. A typical statement in a scripting language executes hundreds or thousands of machine instructions,
whereas a typical statement in a system programming language executes about five machine instructions. Part of this difference
is because scripting languages use interpreters, which are less efficient than the compiled code for system programming languages.
But much of the difference is because the primitive operations in scripting languages have greater functionality.
For example, in Perl it is about as easy to invoke a regular expression substitution as it is to invoke
an integer addition. In Tcl, a variable can have traces associated with it so that setting the variable causes side effects; for
example, a trace might be used to keep the variable's value updated continuously on the screen.
This language sucks, I hate this language, my language is better than your language, this is not even a programming language, developers
who use that language are imbeciles, etc. We all know this type of discussions.
While heated words are used the discussion usually revolves around three issues:
language constructs divergence,
language structure
issues (lexical structure, syntax and semantic),
the language communities issues.
The scripting language divergence occurs on a spectrum from the deceptively trivial (e.g., what should the syntax of a loop be?) to
the debatably deeper (e.g., strong, lazy or weak typing? Do the language need inheritance mechanism or it is just a bad
fashion and the implementation of it involves unnecessary overhead?).
We probably can distibush between onwer/developers of the language, expect users, ordinary users and novices/accidental users.
The role of the owner is often literal: this is the person or a couple of person who acturally impremented the interpreter.
It also can be complnay (Oracle owns Java; Microsoft owns C++) or the ocmpnay that provides specific versiuon of interprer
like Microsoft for Python and Actrive state for Perl.
Owners, by definition, have a vested interest in the success of a language product (e.g., fame, interest, belief, money).
Whule users may not have the same motives as owners, they may also have vested interests.
For example, those that learned programming using C, and that are familiar with its syntax, might be more willing to adopt a C-like
language such as Java.
While owners and users may have their own motivations, there are some pverlap as extect users often submit patches and
enhancement to the interpreter and also serve as beta testers.
Ther is a also a spcial class of users which might be called "true belevers. " True believers are ready to defend the language
from critics and proseletite its use in communities. They are often those users who find a particular
language’s design convincing and who use this acitivty for status enhancement within the community.
large users have a huge stake in the future of the language. For example, if a software development house has a million lines of,
for the sake of argument, PHP code, then
they are dependent on the success of PHP financially (Facebook might serve as an exemplar for PHP, Yahoo for Perl). This can be the case regardless of whether
a group owns the language technology and develop the interpterer.
In this same respect, students are also dependents
but in a different way: they are required to use language products chosen for them by faculty and thus became "addicted" to the
particular language. In the past it tooks years to learn a language like C++ competently. Now with Python the situation
is similar and this huge investment makes students
are dependent upon the success of the language or its constructs. We call individuals in this situation intellectual dependents.
Formally, the logical opposite of the dependents is the volunteers. In this group, programmers may
experiment with, or otherwise use, a programming language for their own reasons. Such users may fall into categories like early adopters,
trying Apple’s Swift because they want to. Similarly, they may enjoy using a variety of language products for personal reasons. But
at asome point due to the time invested volunteers also acquire dependence and practical vested interest, financially or
intellectually
As part of the language wars, it makes sense to think about the roles the various actors have and how these roles impact the success
or failure of language products. In essence, there are many individual participants of the programming language wars, which
naturally encompasses a broad range of people (e.g., students, entry level professionals, CEOs at major corporations), harbor
different motivations for their participation.
We think one tangible area that may not benefit from divergence is syntax. Currently C-style syntax dominates the firled and
became standard fe-facto. Only feq popular language do not use it (Python, Roby).
We
think scholars and practitioners need to demand more evidence from scholars on benefit of alternative design such as for loop in
Python, especially when language designers make
claims. This is especially true given documented evidence from several studies showing that syn- tax has a significant impact on novices
18, 9, 44| and that compiler error design impacts professionals [40].
...Evidence issues aside, while the literature is currently sparse, given that the current authors have had considerable contact
with the language community, we want to be clear about one fact: from our perspective, while there may not be much evidence in the literature
in regard to issues like language impact, we do think language designers care deeply about such issues. We think one way in the future
that it might be possible to thus make progress is in the creation of a formal catalog of language features, their impact on people,
and standard reproducible tests, with corresponding evidence. For example, in psychology, scientists have created the DSM-5 [1], a rigorous
collection of assessment procedures for a variety of psychological conditions. With programming languages, creating a standard collection
of all assessments ever done on type systems, syntax, or other features and documents on how to easily replicate them, could go a long
way toward giving language designers reliable, replicable, scientific information about impact. This leads us to our next question:
RQ Can we create a catalog, using the DSM5 [1] as an exemplar, for reliable tests on language impact?
This essay is a first attempt to frame the debate about what is often colloquially termed the programming language wars. This struggle
was natural for the computer science community in its inception, when we had no experience, but this is no longer true. At the beginning
of the 21st century, we already know how to do a great deal in regard to designing languages and we need to use this as an objective
filter of what already exists. Further, we feel that we are duplicating effort at too large a scale, which needs to be carefully investigated
and considered. Perhaps the recent extensions of C++ are a good exemplar for what we feel has gone wrong. In the case of C++, new constructs
continue to be invented. While few would doubt that innovation can be positive, these constructs have no evidence foundation. Even in
academia, scholars are expressing less skepticism than we feel they should toward anecdotes and claims, while simultaneously showing
too much skepticism toward experimentation—an ironic truth, given that techniques like randomized controlled trials are the gold standard
in almost all other scientific disciplines. With that said, we imagine our email boxes saying, “But yes, this is how it’s done.” Our
argument is that the way it is done makes no sense. We are scientists, not bricklayers. The lack of a reliable evidence foundation is
at the core of the language wars and we may have to make changes to our discipline to fix the problem. This may include alterations
to peer review policies, adjustments to education, and an increasing unwillingness to accept claims made by language designers that
do not base their design decisions on verifiable and replicable scientific data. This is important because the language wars may be
part of the most massive duplication of effort in history. As such, it is poor stewardship if we continue to ignore the problem in perpetuity.
We imagine a large number of participants in the language wars, no matter what we have said in this essay nor how we have said it, will
object using anecdotes or personal experience. We imagine researchers will tell us they cannot provide evidence for all their steps
or that they find evidence gathering banal or control groups to be unimportant. We imagine other scholars will tell us that we should
not worry—empirical evidence is just an unhealthy trend in language design research and it will go away soon. Given the history of science,
which trends toward increasingly reliable empirical measurements, we have our doubts.
The problem is C-style
delimiters for conditional statements (round brackets) and overuse of curvy brackets. The
former is present in all C-style languages.
So IMHO omitting brackets in built-in functions was a false start; the problem that should
be addressed is the elimination of brackets in prefix conditionals.
One possible way is to have a pragma "altblockdelim" or something like that, which would
allow to use,say, ?? and ;; or classic "begin/end" pair instead of '{' and '}', which are
overused in Perl. That would decrease parenthesis nesting.
After all, we can write && as "and" and some people like it.
It's like within Perl 5 exists a language with more modern syntax that just wants to
emerge.
I'm not sure how a discussion about parenthesis ( ) morphed into too many
brackets ("curvy brackets" - { } ), but I don't see the problem in any case. The use
of brackets for block delimiters is visually quite distinct from any other use I'm familiar
with so I don't see the problem.
There is a usage of ;; that I don't quite grok, but seems to be fairly common so the ;;
option probably wouldn't fly in any case.
Perl's && and and operators have
substantially different precedence. They must not be used as interchangeable. Yes, subtle I
know, but very useful.
Optimising for fewest key strokes only makes sense transmitting to
Pluto or beyond
I'm not sure how a discussion about parenthesis ( ) morphed into too many brackets
("curvy brackets" - { }), but I don't see the problem in any case.
In C you can write
if(i<0) i=0
if Perl you can't and should write
if( $i<0 ){ $i=0 }
because the only statement allowed after conditionals is a compound statement -- a
block. Which was a pretty elegant idea that eliminates the problem of "dangling else"
https://www.sanfoundry.com/c-question-dangling-else-statements/
But the problem is that at this point round parenthesis become a wart. They are not
needed and they detract from readability. So if curvy brackets were not used anywhere else
you can simplify this to
if $i<0 {$i=0}
But you can't do this in Perl because curvy brackets are used for hashes.
There is a usage of ;; that I don't quite grok, but seems to be fairly common so the
;; option probably wouldn't fly in any case.
In Perl ; is an empty(null) statement. So the current meaning of ;; is "the
end of the previous statement followed by the null statement".
the new meaning will be "the end of the current statement and the end of the block", which is
pretty elegant idea in its own way. Because now Perl allows omitting semicolon before } as special
case, but in the new syntax this is just a general case and the special case is not needed.
Comment on Re^12:
What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO
staff
For programming languages to evolve and flourish, we all need to accept other people's
viewpoints and continue open-minded, civil and respectful dialogue.
In science, scientists always question everything; why shouldn't we question some features
and point out deficiencies of Perl 5 which after version 5.10 became really stale feature-wise
-- the last important addition was the addition of state variables in 5.10. Partially
this happened as most resources were reallocated to Perl 6 (The Perl 6 project was announced in
2000), a robust interpreter for which failed to materialize for too long: the situation which
also slowed down Perl 5 interpreter development.
The question arise: Should it be possible on perlmonks to criticize some aspects of Perl 5
current features and implementation as well as its use without being denigrated as a
reward?
At least after the split Perl 5 has theoretical chances to stand on its own, and evolve like
other languages evolved (for example, FORTRAN after 1977 adopted 11 years cycle for new
versions). As Perl 5.10 was released in 2007, now it is 13 years since this date and Perl 7 is
really overdue. The question is what to include and what to exclude and what glaring flaws need
to be rectified (typically a new version of a programming language tries to rectify the most
glaring design flaws in the language and introduce changes that could not be implemented while
retaining full backward compatibility.)
Brian D Foy post that announced this new version is really weak. It essentially states "We
decided to rename 5.32 and you all should be happy." It does not contain any new ideas, just
the desire to have new version of Perl as Perl 5.32 with few new defaults (which BTW will break
compatibility with old scripts at least with 5.8 and earlier versions scripts as not all of
them use strict pragma, and strict pragma implementation still has its own set of problems
).
The question arises: Whether the game worth candles? Unless the new editions of O'Reilly
books is the goal. That's why I provided this contribution, suggesting some minor enhancements
which might better justify calling the new version Perl 7. And what I got in return ?
I hoped that this post would be a start of the meaningful discussion. But people like you
turned it into a flame-fest.
It looks like it is impossible to have a rational fact-based discussion on this subject with
zealots like you.
PERL is not dead, only those guardians of PerlMonks dot org, who lie in wait to bounce
upon your most recent posts with spiteful replies loaded with falsehoods and hate and
jealousy.
Good luck trying to impart your acquired PERL knowledge there. They will do their very
best to attempt to discredit you and your ideas.Alex
Jones , works at Own My Own Business Answered January 12, 2020 ·
Author has 259 answers and 76.1K answer views
My answer refers to Perl 5 rather than Raku (Perl 6),
Perl 5 is a veteran computer language with a track record and pedigree of several decades.
Perl has been around long enough that its strengths and weaknesses are known; it is a stable,
predictable and reliable language that will deliver results with little effort.
In the new decade 2020 and beyond, Perl in my opinion, remains competitive in performance
against any other computer language. Perl remains viable as a language to use in even the most
advanced of information technology projects.
Simple market forces have driven Perl out of the top computer languages of choice for
projects. Because a business finds it hard to find Perl developers, they are forced to use a
computer language where there are more developers such as Python. Because fewer businesses are
using Perl in their projects, the education system selects a language such as Python to train
their students in.
Perl 5 will probably no longer be the universal language of choice for developers and
businesses, but may dominate in a particular niche or market. There is a major campaign
underway by supporters of Perl 5 and Raku to promote and encourage people to learn and use
these languages again.
My startup is involved in AI, and I use Perl 5 for the projects I am developing. There are a
number of strengths in Perl 5 which appeal to me in my projects. Perl 5 has a strong reputation
for the abilty to create and execute scripts of only a few lines of code to solve problems. As
Perl 5 is designed to be like a natural spoken language, it becomes the practical choice for
handling text. When handling complex patterns, the regex capabilities in Perl 5 is probably the
best of any computer language. Lastly, Perl 5 was the glue that enabled the systems of the
1990's to work together, and might offer a pragmatic solution to bridging the old with the new
in the modern era.
I would describe Perl as existing in a dormant phase, which is waiting for the right
conditions to emerge where it will regain its place at the leading edge in a niche or market
such as in artificial intelligence. Joe Pepersack , Just Another Perl Hacker
Answered May
31, 2015 · Author has 5.7K answers and 7M answer views
No. It's not dead. But it's not very active, either and it's lost a lot of mindshare to Ruby
and Python. Hopefully the recently-announced December release of Perl 6 (Finally!) will renew
interest in the language.
I found a really useful site the other day: Modulecounts . CPAN is Perl's greatest asset, but
unfortunately it seems to have stagnated compared to Pypi or RubyGems. CPAN is getting 3 new
modules per day whereas RubyGems is getting 53/day. Rubygems overtook CPAN in 2011 and Pypi
overtook it in 2013.
Personally I think Python is Perl on training wheels and represents a step backwards if
you're coming from Perl. Ruby is a great language and is pretty Perl-ish overall. Plus someone
just recently ported Moose to Ruby so that's a huge win.
I would argue Perl is still worth learning for a couple main reasons:
It's ubiquitous. Every Unix-ish system made in the last decade has some version of Perl
on it.
It's still unbeaten for text manipulation and for doing shell-scripty type things that
are too hard to do in bash.
Ad-hoc one-liners. Neither ruby nor python can match perl for hacking together something
on the command line.
There's a lot of Perl code still out there doing important things. It's cheaper to
maintain it than it is to re-write it in another language.
Perl is certainly not dead, but it does face an adoption challenge. For example, fewer
vendors are releasing Perl API's or code samples (but the Perl community often steps in at
least for popular platforms). Finding new developers who know Perl is more difficult, while it
is much less difficult to find developers with Python and Java. The emerging technology areas
such as big data and data science have a strong Python bent, but a lot of their tasks could be
done faster in Perl (from my own experience).
What is great about Perl is despite its quirks, is it is relatively easy to learn if you
know other programming languages. What I have found amazing is that when developers are "forced
to learn Perl" for a project, they usually pleasantly surprised at how powerful and unique Perl
is compared to their language of choice.
From a job value perspective, Perl knowledge has some interesting value quirks (just like
the language has some interesting quirks). The market for Perl developers is not as large as
other languages, but companies that need Perl developers have a hard time finding good
candidates. Thus, you might find it easier to get a job with Perl skills even though there are
fewer jobs that require it.
In short, Perl has an amazing ability to convert existing programmers, but fewer programmers
are coming into the workforce with Perl experience. Avi
Mehenwal , Ex-perl programmer, but still cannot let it go. I feel the RegEx Attachement
Answered April
2, 2016 · Author has 64 answers and 226.8K answer views
Perl has been around since 1987 and became an early darling of web developers. These days,
however, you don't hear much about Perl. Everyone seems to be talking about trendier languages
like PHP, Python and Ruby, with Perl left in the back as a neglected, not-so-hip cousin.
That might lead you to think that Perl is dying, but as it turns out, it's still used by
plenty of websites out there, including some pretty big hitters.
Here are some of the more popular sites that use Perl extensively today:
The language is still thriving. There's a new release every year and each release includes
interesting new features (most recently, subroutine signatures). More modules are uploaded to
CPAN every year. More authors contribute code to CPAN every year.
But I still think that Perl is dying and I would find it hard to recommend that anyone
should choose a career in Perl at this point.
Ask yourself these three questions:
When did you last read a general programming book that included examples in Perl?
Why did you last see an API that included usage examples written in Perl?
When did you last hear of a company using Perl that you didn't already know about?
I should be working 16 hours ago removelink
Hey guys: MAYBE WE SHOULD FOCUS ON GETTING GOOGLE UNDER CONTROL FIRST!play_arrow mike_1010 17
hours ago (Edited)
Source code information is a closely guarded secret for all IT companies. Because if hackers
get access to it, then they can find many ways to compromise its security and to spy on its
users.
So, it makes sense that the Chinese government might want to protect the source code of apps
that are used by many people in China.
I'm sure the US government would say the same thing, if some Chinese company wanted to buy
the source code of Microsoft's Windows 10 operating system or something like that.
From the point of view of cybersecurity, this makes perfect sense.
Every country has legitimate security concerns. And these concerns were heightened, when
Edward Snowden revealed the extent of US government hacking and spying of the rest of the
world, including China.
The Chinese government has actually more evidence and more reasons to be concerned about
possible hacking and spying by the US government, than the other way. USA has only been
accusing China of doing the same. But they've never shown any conclusive evidence to back their
claims, the way Edward Snowden has revealed such evidence about USA.
The only thing that surprises me in this whole affair is that it took the Chinese government
this long to say the obvious. If the situation was reversed and the issue was about the source
code of some US company software, then US politicians and security experts would've been
yelling about this kind of thing right from the start.
All of the following satisfy your criteria, are valid and normal Perl code, and would get a semicolon incorrectly inserted based
on your criteria:
use softsemicolon;
$x = $a
+ $b;
$x = 1
if $condition;
$x = 1 unless $condition1
&& $condition2;
Yes in cases 1 and 2; it depends on depth of look-ahead in case 3. Yes if it is one symbol. No it it is two(no Perl statement can
start with && )
As for "valid and normal" your millage may vary. For people who would want to use this pragma it is definitely not "valid and
normal". Both 1 and 2 looks to me like frivolities without any useful meaning or justification. Moreover, case 1 can be rewritten
as:
Both 1 and 2 looks to me like frivolities without any useful meaning or justification
You and I have vastly differing perceptions of what constitutes normal perl code. For example there are over 700 examples of the
'postfix if on next line' pattern in the .pm files distributed with the perl core.
There doesn't really seem any point in discussing this further. You have failed to convince me, and I am very unlikely to work
on this myself or accept such a patch into core.
You and I have vastly differing perceptions of what constitutes normal perl code. For example there are over 700 examples of
the 'postfix if on next line' pattern in the .pm files distributed with the perl core.
Probably yes. I am an adherent of "defensive programming" who is against over-complexity as well as arbitrary formatting (pretty
printer is preferable to me to manual formatting of code). Which in this audience unfortunately means that I am a minority.
BTW your idea that this pragma (which should be optional) matters for Perl standard library has no connection to reality.
A very large proportion of the replies you have received in this thread are from people who put a high value on writing maintainable
code. "maintainable" is short hand for code that is written to be understood and maintained with minimum effort over long periods
of time and by different programmers of mixed ability.
There is a strong correlation with your stance of "defensive programming"
... against over-complexity as well as arbitrary formatting . None of us are arguing with that stance. We are arguing with
the JavaScript semicolon that you would like introduced based on a personal whim in a context of limited understanding of Perl
syntax and idiomatic use.
Personally I use an editor that has an on demand pretty printer which I use frequently. The pretty printer does very little
work because I manually format my code as I go and almost always that is how the pretty printer will format it. I do this precisely
to ensure my code is not overly complex and is maintainable. I do this in all the languages that I use and the hardest languages
to do that in are Python, VBScript and JavaScript because of the way they deal with semi-colons.
Oh, and in case it is of interest, dave_the_m is one of
the current maintainers of Perl. He is in a great position to know how the nuts and bolts of an optional semi-colon change might
be made and has a great understanding of how Perl is commonly used. Both give him something of a position of authority in determining
the utility of such a change.
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
Parser lookaheads are implemented in terms of tokens, not characters. The first token of yada is a triple-dot, not a dot. While
you may think it starts with a dot, that's not how the parser sees it, so the existence of yada is not relevant here.
You also completely ruin maintainability and extensibility. Consider a filter module ...
my $fixed = $bad =~ y/\x{00d0}/\x{0110}/r # Eth != D-stroke =~ y/\x{0189}/\x{0110}/r # LETTER AFRICAN D != + D-stroke =~ s{\bpra[ck]ti[sc]e\b}{practice}gr
# All 4 seen in docume + nt AB12.38C =~ s{\bX13\.GtrA\.14\b}{X13_GA12}gr # Product got renamed =~ s{\b1234\s*zip\b}{1234ZIP}gir
# Reciever will crash + on badly formed ZIP code =~ s{\bpays\s*-?\s*bas\b} {The Netherlands}gir # French forms :( =~ ....;
Why you are concentrating on just one proposal. Are all other equally bad ?
As for soft-semicolon you completly misunderstood the situation:
First, nobody force you to use this pragma. And if you do not use it you are not affected. I am thinking now that it should
be enabled only with option -d.
It does not make sense to conduct something like "performance review" in a large corporation for my proposals concentrating
on "soft-semicolon" idea and ignoring all others. As if it is the only one worth any discussion. It might be the easiest one to
piss off, but it is far from being the most important or far reaching among those proposals.
There is no free lunch, and for some coding styles (including but not limited to coding styles used in many modules in Perl
standard library) it is definitely inappropriate. Nobody claim that it is suitable for all users. It is an optional facility for
those who want and need it. In a way, it is a debugging aid that allows to cut the number of debugging runs. And IMHO there is
not a zero subset of Perl users who would be interested in this capability. Especially system administrators who systematically
use bash along with Perl. And many of them do not use sophisticated editors, often this is just vi or Midnight Commander editor.
Detractors can happily stay with the old formatting styles forever. Why is this so difficult to understand before producing
such an example?
Moreover, how can you reconcile the amount of efforts (and resulting bugs) for the elimination of extra round brackets in Perl
with this proposal? Is not this the same idea -- to lessen the possible number of user errors?
For me, it looks like a pure hypocrisy - in one case we are spending some efforts following other scripting languages at some
cost; but the other, similar in its essence, proposal is rejected blindly as just a bad fashion. If this is a fashion, then eliminating
round brackets is also a bad fashion, IMHO.
And why only I see some improvements possible at low cost in the current Perl implementation and nobody else proposed anything
similar or better, or attempted to modify/enhance my proposals? After all Perl 5.10 was a definite step forward for Perl. Perl
7 should be the same.
I think the effort spend here in criticizing my proposal would be adequate to introduce the additional parameter into index
function ("to" limit). Which is needed and absence of which dictates using substr to limit the search zone in long strings. Which
is sub-optimal solution unless the interpreter has advanced optimization capabilities and can recognize such a use as the attempt
to impose the limit on the search.
Or both this and an option in tr that allows it to stop after the first character not is set1 and return this position.:-)
Constructive discussion does not mean pissing off each and every my posts ( one has -17 votes now; looks a little bit like
schoolyard bulling ) -- you need to try to find rational grain in them, and if such exists, try to revise and enhance the proposal.
The stance "I am happy with Perl 'as is' and go to hell with your suggestions" has its value and attraction, but it is unclear
how it will affect the future of the language.
As for soft-semicolon you completly misunderstood the situation: First, nobody force you to use this pragma. And if you
do not use it you are not affected. I am thinking now that it should be enabled only with option -d.
In the OP you make no mention of a pragma in proposal 1, you just say that it would be "highly desirable" to have soft semicolons.
This implies that you would like it to be the default behaviour in Perl 7, which, judging by the responses, would hack a lot of
people off, me included. If you are proposing that soft semicolons are only enabled via a pragma perhaps you should add a note
to that effect in the OP, being sure to make it clear that it is an update rather than silently changing the text.
And IMHO there is not a zero subset of Perl users who would be interested in this capability. Especially system administrators
who systematically use bash along with Perl.
I spent the last 26 years of my career as a systems administrator (I had no ambition to leave technical work and become a manager)
on Unix/Linux systems and started using Perl in that role in 1994 with perl 4.036, quickly moving to 5. The lack of semicolon
statement terminators in the various shell programming languages I had to use was a pain in the arse and moving to Perl was a
huge relief as well as a boost to effectiveness. I would not be the slightest bit interested in soft semicolons and they would,
to my mind, be either a debugging nightmare or would force me into a coding style alien to my usual practice.
to which I say, nonsense! Why add unnecessary round brackets to perfectly valid code? Use round brackets where they are needed
to disambiguate precedence but not where they just add superfluous noise. Nothing to do with fascination, I've never touched Python!
You should be commended on the amount of thought that you have put into your proposals and such efforts should not be discouraged.
It is unfortunate that your first proposal has been the most contentious and the one that most responses have latched onto. Sticking
to one's guns is also a praiseworthy trait but doing so in the face of several powerful and cogent arguments to the contrary from
experienced Perl users is perhaps taking it too far. Making it clear that soft semicolons would not be the default behaviour might
apply some soothing balm to this thread.
It does not make sense to conduct something like "performance review" in a large corporation for my proposals concentrating
on "soft-semicolon" idea and ignoring all others. As if it is the only one worth any discussion.
Others have already contributed their thoughts on the rest of your proposals, which I generally agree with and (more significantly)
you haven't disputed. IMO, the primary reason that all the discussion is focusing on soft semicolons is because it's the only
point you're attempting to defend against our criticisms. There was also a brief subthread about your ideas on substring manipulation,
and a slightly longer one about alternate braces which close multiple levels of blocks, but those only lasted as long as you continued
the debate.
In a way, it is a debugging aid that allows to cut the number of debugging runs.
Seems like just the opposite to me. It may allow you to get your code to run sooner, but, when it does, any semicolon errors will
still be there and need to be fixed in additional debugging runs. Maybe a marginal decrease in overall debugging time if there's
a line where you never have to fix the semicolon error because that line ends up getting deleted before you finish, but it seems
unlikely to provide any great savings if (as you assert) such errors are likely to be present on a significant proportion of lines.
Also, even if it does cut out some debugging runs, they're runs with a very fast turnaround and little-to-no cognitive effort
involved. According to your "BlueJ" paper, even rank beginners need only 8 seconds to fix a missing semicolon error and initiate
a new compile.
if we assume that somebody uses this formatting to suffix conditionals
I do, pretty much all the time! The ability to span a statement over multiple lines
without jumping through backslash hoops is one of the things that makes Perl so
attractive. I also think it makes code much easier to read rather than having excessively
long lines that involve either horizontal scrolling or line wrapping. As to your
comment regarding
excessive length identifiers, I come from a Fortran IV background where we had a maximum
of 8 characters for identifiers (ICL 1900 Fortran compiler) so I'm all for long,
descriptive and unambiguous identifiers that aid those who come after in understanding my
code.
It might make sense to enable it only with -d options as a help for debugging, which
cuts the number of debugging runs for those who do not have editor with built-in syntax
checking (like ActiveState Komodo Editor; which really helps is such cases ).
That list includes most Linux/Unix system administrators, who use just command line
and vi or similar. And they also use bash of daily basis along with Perl, which increases
the probability of making such an error. And this is probably one of the most important
category of uses for the future of Perl: Perl started with this group (Larry himself,
Randal L. Schwartz, Tom Christiansen, etc) and after a short affair with the Web
programming (yahoo, etc) and bioinformatics (bioperl) retreated back to the status of the
scripting language of choice for the elite Unix sysadmins.
That does not exclude other users and applications, but I think the core of Perl users
are now Unix sysadmins. And their interests should be reflected in Perl 7 with some
priority.
BTW, I do not see benefits of omitted semicolons in the final program (as well as, in
certain cases, omitted round brackets).
if we assume that somebody uses this formatting to suffix conditionals
I do, pretty much all the time! The ability to span a statement over multiple lines
without jumping through backslash hoops is one of the things that makes Perl so
attractive. I also think it makes code much easier to read rather than having excessively
long lines that involve either horizontal scrolling or line wrapping. As to your
comment regarding
excessive length identifiers, I come from a Fortran IV background where we had a maximum
of 8 characters for identifiers (ICL 1900 Fortran compiler) so I'm all for long,
descriptive and unambiguous identifiers that aid those who come after in understanding my
code.
It might make sense to enable it only with -d options as a help for debugging, which
cuts the number of debugging runs for those who do not have editor with built-in syntax
checking (like ActiveState Komodo Editor; which really helps is such cases ).
That list includes most Linux/Unix system administrators, who use just command line
and vi or similar. And they also use bash of daily basis along with Perl, which increases
the probability of making such an error. And this is probably one of the most important
category of uses for the future of Perl: Perl started with this group (Larry himself,
Randal L. Schwartz, Tom Christiansen, etc) and after a short affair with the Web
programming (yahoo, etc) and bioinformatics (bioperl) retreated back to the status of the
scripting language of choice for the elite Unix sysadmins.
That does not exclude other users and applications, but I think the core of Perl users
are now Unix sysadmins. And their interests should be reflected in Perl 7 with some
priority.
BTW, I do not see benefits of omitted semicolons in the final program (as well as, in
certain cases, omitted round brackets).
We present a rationale for expanding the presence of the Lisp family of programming
languages in bioinformatics and computational biology research. Put simply, Lisp-family
languages enable programmers to more quickly write programs that run faster than in other
languages. Languages such as Common Lisp, Scheme and Clojure facilitate the creation of
powerful and flexible software that is required for complex and rapidly evolving domains like
biology. We will point out several important key features that distinguish languages of the
Lisp family from other programming languages, and we will explain how these features can aid
researchers in becoming more productive and creating better code. We will also show how these
features make these languages ideal tools for artificial intelligence and machine learning
applications. We will specifically stress the advantages of domain-specific languages (DSLs):
languages that are specialized to a particular area, and thus not only facilitate easier
research problem formulation, but also aid in the establishment of standards and best
programming practices as applied to the specific research field at hand. DSLs are particularly
easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred
to as the 'programmable programming language'. We are convinced that Lisp grants programmers
unprecedented power to build increasingly sophisticated artificial intelligence systems that
may ultimately transform machine learning and artificial intelligence research in
bioinformatics and computational biology.
The programming language Lisp is credited for pioneering fundamental computer science
concepts that have influenced the development of nearly every modern programming language to
date. Concepts such as tree data structures, automatic storage management, dynamic typing,
conditionals, exception handling, higher-order functions, recursion and more have all shaped
the foundations of today's software engineering community. The name Lisp derives from 'List
processor' [ 1 ], as
linked lists are one of Lisp's major data structures, and Lisp source code is composed of
lists. Lists, which are a generalization of graphs, are extraordinarily well supported by Lisp.
As such, programs that analyze sequence data (such as genomics), graph knowledge (such as
pathways) and tabular data (such as that handled by R [ 2 ]) can be written easily, and can be made to work
together naturally in Lisp. As a programming language, Lisp supports many different programming
paradigms, each of which can be used exclusively or intermixed with others; this includes
functional and procedural programming, object orientation, meta programming and reflection.
But more to the point, we have empirical evidence that Lisp is a more productive
general-purpose programming language than the other usual suspects, and that most Lisp programs
run faster than their counterparts in other languages. Gat [ 3 ] compared the run times, development times and
memory usage of 16 programs written by 14 programmers in Lisp, C/C ++ and Java.
Development times for the Lisp programs ranged from 2 to 8.5 h, compared with 2 to 25 h for
C/C ++ and 4 to 63 h for Java (programmer experience alone does not account for
the differences). The Lisp programs were also significantly shorter than the other
programs.
And although the execution times of the fastest C/C ++ programs were faster than the
fastest Lisp programs, on average, the Lisp programs ran significantly faster than the
C/C ++ programs and much faster than the Java programs (mean runtimes were 41 s for Lisp
versus 165 s for C/C ++).
Lisp applications and dialects
In bioinformatics and computational biology, Lisp has successfully been applied to research
in systems biology [ 4 ,
5 ], high-performance
computing (HPC) [ 6 ],
database curation [ 7 ,
8 ], drug discovery [
9 ], computational
chemistry and nanotechnology [ 10 , 11 ], network and pathway -omics analysis [ 12 , 13 , 14 , 15 , 16 ], single-nucleotide polymorphism analysis [ 17 , 18 , 19 ] and RNA structure prediction [ 20 , 21 , 22 ]. In general, the Lisp family of programming languages, which
includes Common Lisp, Scheme and Clojure, has powered multiple applications across fields as
diverse as [ 23 ]:
animation and graphics, artificial intelligence (AI), bioinformatics, B2B and e-commerce, data
mining, electronic design automation/semiconductor applications, embedded systems, expert
systems, finance, intelligent agents, knowledge management, mechanical computer-aided design
(CAD), modeling and simulation, natural language, optimization, risk analysis, scheduling,
telecommunications and Web authoring.
Programmers often test a language's mettle by how successfully it has fared in commercial
settings, where big money is often on the line. To this end, Lisp has been successfully adopted
by commercial vendors such as the Roomba vacuuming robot [ 24 , 25 ], Viaweb (acquired by Yahoo! Store) [ 26 ], ITA Software (acquired by Google Inc. and
in use at Orbitz, Bing Travel, United Airlines, US Airways, etc.) [ 27 ], Mirai (used to model the Gollum character
for the Lord of the Rings movies) [ 28 ], Boeing [ 29 ], AutoCAD [ 30 ], among others. Lisp has also been the driving force behind open source
applications like Emacs [ 31 ] and Maxima [ 32 ], which both have existed for decades and continue to be used
worldwide.
Among the Lisp-family languages (LFLs), Common Lisp has been described as the most powerful
and accessible modern language for advanced biomedical concept representation and manipulation
[ 33 ]. For concrete
code examples of Common Lisp's dominance over mainstream programming languages like R and
Python, we refer the reader to Sections 4 and 5 of Ross Ihaka's (creator of the R programming
language) seminal paper [ 34 ].
Scheme [ 35 ] is an
elegant and compact version of Common Lisp that supports a minimalistic core language and an
excellent suite of language extension tools. However, Scheme has traditionally mainly been used
in teaching and computer science research and its implementors have thus prioritized small
size, the functional programming paradigm and a certain kind of 'cleanliness' over more
pragmatic features. As such, Scheme is considered far less popular than Common Lisp for
building large-scale applications [ 24 ].
The third most common LFL, Clojure [ 36 , 37 ], is a rising star language in the modern software development
community. Clojure specializes in the parallel processing of big data through the Java Virtual
Machine (JVM), recently making its debut in bioinformatics and computational biology research [
38 , 39 , 40 ]. Most recently, Clojure was used to
parallelize the processing and analysis of SAM/BAM files [ 39 ]. Furthermore, the BioClojure project provides seeds
for the bioinformatics community that can be used as building blocks for writing LFL
applications. As of now, BioClojure consists of parsers for various kinds of file formats
(UniProtXML, Genbank XML, FASTA and FASTQ), as well as wrappers of select data analysis
programs (BLAST, SignalP, TMHMM and InterProScan) [ 39 ].
As a whole, Lisp continues to develop new offshoots. A relatively recent addition to the
family is Julia [ 41
]. Although it is sometimes touted 'C for scientists' and caters to a different community
because of its syntactical proximity to Python, it is a Lisp at heart and certainly worth
watching.
Rewards and challenges
In general, early adopters of a language framework are better poised to reap the scientific
benefits, as they are the first to set out building the critical libraries, ultimately
attracting and retaining a growing share of the research and developer community. As library
support for bioinformatics tasks in the Lisp family of programming languages (Clojure, Common
Lisp and Scheme) is yet in its early stages and on the rise, and there is (as of yet) no
officially established bioinformatics Lisp community, there is plenty of opportunity for
high-impact work in this direction.
It is well known that the best language to choose from should be the one that is most well
suited to the job at hand. Yet, in practice, few programmers may consider a nonmainstream
programming language for a project, unless it offers strong, community-tested benefits over its
popular contenders for the specific task under study. Often times, the choice comes down to
library support: does language X already offer well-written, optimized code to help solve my
research problem, as opposed to language Y (or perhaps language Z)? In general, new language
adoption boils down to a chicken-and-egg problem: without a large user base, it is difficult to
create and maintain large-scale, reproducible tools and libraries. But without these tools and
libraries, there can never be a large user base. Hence, a new language must have a big
advantage over the existing ones and/or a powerful corporate sponsorship behind it to compete [
42 ]. Most often, a
positive feedback loop is generated by repositories of useful libraries attracting users, who,
in turn, add more functional libraries, thereby raising a programming language's popularity,
rather than reflecting its theoretical potential.
With mainstream languages like R [ 2 ] and Python [ 43 ] dominating the bioinformatics and computational biology scene for
years, large-scale software development and community support for other less popular language
frameworks have waned to relative obscurity. Consequently, languages winning over increasingly
growing proportions of a steadily expanding user base have the effect of shaping research
paradigms and influencing modern research trends. For example, R programming generally promotes
research that frequently leads to the deployment of R packages to Bioconductor [ 44 ], which has steadily grown into
the largest bioinformatics package ecosystem in the world, whose package count is considerably
ahead of BioPython [ 45 ], BioClojure [ 38 ], BioPerl [ 46 ], BioJava [ 47 ], BioRuby [ 48 ], BioJulia [ 49 ] or SCABIO [ 50 ]. Given the choice, R programmers interested in deploying large-scale
applications are more likely to branch out to releasing Web applications (e.g. Shiny [
51 ]) than to
graphical user interface (GUI) binary executables, which are generally more popular with
lower-level languages like C/C ++ [ 52 ]. As such, language often dictates research direction, output and
funding. Questions like 'who will be able to read my code?', 'is it portable?', 'does it
already have a library for that?' or 'can I hire someone?' are pressing questions, often
inexorably shaping the course and productivity of a project. However, despite its popularity, R
has been severely criticized for its many shortcomings by its own creator, Ross Ihaka, who has
openly proposed to scrap the language altogether and start afresh by using a Lisp-based engine
as the foundation for a statistical computing system [ 34 , 53 ].
As a community repository of bioinformatics packages, BioLisp does not yet exist as such
(albeit its name currently denotes the native language of BioBike [ 4 , 54 ], a large-scale bioinformatics Lisp application),
which means that there is certainly wide scope and potential for its rise and development in
the bioinformatics community.
Macros and domain-specific languages
Lisp is a so-called homoiconic language, which means that Lisp code is represented as a data
structure of the language itself in such a way that its syntactical structure is preserved. In
more technical terms, while the Lisp compiler has to parse the textual representation of the
program (the 'source code') into a so-called abstract syntax tree (like any other compiler of
any programming language has to), a Lisp program has direct access to (and can modify) this
abstract syntax tree, which is presented to the program in a convenient, structured way.
This property enables Lisp to have a macro system that remains undisputed in the programming
language world [ 55 ].
Although 'macros' in languages like C have the same name, they are essentially just text
substitutions performed on the source code before it is compiled and they cannot always
reliably preserve the lexical structure of the code. Lisp macros, on the other hand, operate at
the syntactic level. They transform the program structure itself and, as opposed to C macros,
are written in the same language they work on and have the full language available all the
time. Lisp macros are thus not only used for moderately simple 'find and replace' chores but
can apply extensive structural changes to a program. This includes tasks that are impossible in
other languages. Examples would be the introduction of new control structures (while Python
users had to wait for the language designers to introduce the 'with' statement in version 2.5,
Lisp programmers could always add something like that to the language themselves), pattern
matching capabilities (while Lisp does not have pattern matching like ML or Haskell out of the
box, it is easy to add [ 56 ]) or the integration of code with markup languages (if you want you can,
e.g., write code that mimics the structure of an HTML document it is supposed to emit [
57 , 58 ]).
In addition to that, Common Lisp even offers access to its 'reader', which means that code
can be manipulated (in Lisp) before it is parsed [ 59 ]. This enables Lisp programs to completely change
their surface syntax if necessary. Examples would be code that adds Perl-like interpolation
capabilities to Lisp strings [ 60 ] or a library [ 61 ] that enables Lisp to read arithmetic in 'infix' notation, i.e. to
understand '20 + 2 * 21' in addition to the usual '(+ 20 (* 2 21))'.
These features make Lisp an ideal tool for the creation of domain-specific languages:
languages that are custom-tailored to a specific problem domain but can still have access to
all of Lisp. A striking example is Common Prolog [ 62 ], a professional Prolog system implemented and
embedded in Common Lisp. In bioinformatics, the Biolingua [ 5 ] project (now called BioBike) built a cloud-based
general symbolic biocomputing domain-specific language (DSL) entirely in Common Lisp. The
system, which could be programmed entirely through the browser, was its own complete
biocomputing language, which included a built-in deductive reasoner, called BioDeducta [
54 ]. Biolingua
programs, guided by the reasoner, would invisibly call tools such as BLAST [ 63 ] and Bioconductor [
44 ] on the
server-side, as needed. Symbolic biocomputing has also previously been used to create
user-friendly visual tools for interactive data analysis and exploration [ 64 ].
Other unique
strengths
In addition to homoiconicity, Lisp has several other features that set it apart from
mainstream languages:
In Lisp, programmers usually work in a special incremental interactive programming
environment called the read-eval-print loop (REPL) [ 65 , 66 ]. This means that the Lisp system continuously reads
expressions typed by the user, evaluates them and prints the results. The REPL enables a
paradigm that allows the programmer to continually interact with their program as it is
developed. This is similar to the way Smalltalk 'images' evolve [ 59 ] and different from the usual
edit-compile-link-execute cycle of C-like languages. This approach lends itself well to
explorative programming and rapid prototyping. As such, the REPL enables the programmer to
write a function, test it, change it, try a different approach, etc., while never having to
stop for any lengthy compilation cycles [ 24 ].
Common Lisp was designed from the ground up to create large, complex and long-running
applications and thus supports software 'hot swapping': the code of a running program can
be changed without the need to interrupt it. This includes features like the ability of the
Common Lisp object system (CLOS) to change the classes of existing objects. Although Erlang
and Smalltalk also support hot swapping, no mainstream compiled language does this to our
knowledge. Hot swapping can be performed in Java to a certain extent, but only with the
help of third-party frameworks, as it is not an intrinsic feature of the language
itself.
Lisp invented exception handling, and Common Lisp, in particular, has an error-handling
facility (the 'condition system' [ 24 ]) that goes far beyond most other languages: it does not necessarily
unwind the stack if an exception occurs and instead offers so-called restarts to
programmatically continue 'where the error happened'. This system makes it easy to write
robust software, which is an essential ingredient to building industry-strength
fault-tolerant systems capable of handling a variety of conditions, a trait especially
useful for artificial intelligence and machine learning applications. In the Bioconductor
community, error-handling facilities are ubiquitously present in practically all
R/Bioconductor packages via tryCatch(), a base R function whose roots originate directly
from Lisp's condition system.
Common Lisp implementations usually come with a sophisticated 'foreign function
interface' (FFI) [ 24 ], which allows direct access from Lisp to code written in C or
C ++ and sometimes also to Java code. This enables Lisp programmers to make use of
libraries written in other languages, making those libraries a direct strength of Lisp. For
instance, it is simple to call Bioconductor from Lisp, just as Python and other programming
languages can [ 67
, 68 ]. Likewise,
Clojure runs on the JVM and, thus, has immediate access to all of Java's libraries.
It has been shown that these features, together with other amenities like powerful debugging
tools that Lisp programmers take for granted, offer a significant productivity boost to
programmers [ 3 ]. Lisp
also gives programmers the ability to implement complex data operations and mathematical
constructs in an expressive and natural idiom [ 69 ].
Speed considerations
The interactivity and flexibility of Lisp languages are something that can usually only be
found (if at all) in interpreted languages. This might be the origin of the old myth that Lisp
is interpreted and must thus be slow -- however, this is not true. Compilers for Lisp have
existed since 1959, and all major Common Lisp implementations nowadays can compile directly to
machine code, which is often on par with C code [ 70 , 71 , 72 ] or only slightly slower. Some also offer an interpreter in addition to
the compiler, but examples like Clozure Common Lisp demonstrate that a programmer can have a
compiler-only Common Lisp. For example, CL-PPCRE, a regular expression library written in
Common Lisp, runs faster than Perl's regular expression engine on some benchmarks, even though
Perl's engine is written in highly tuned C [ 24 ].
Although programmers who use interpreted languages like Python or Perl for their convenience
and flexibility will have to resort to writing in C/C ++ for time-critical portions of
their code, Lisp programmers can usually have their cake and eat it too. This was perhaps best
shown with direct benchmarking by the creator of the R programming language, Ross Ihaka, who
provided benchmarks demonstrating that Lisp's optional type declaration and machine-code
compiler allow for code that is 380 times faster than R and 150 times faster than Python [
34 ]. And not only
will the code created by Lisp compilers be efficient by default, Common Lisp, in particular,
offers unique features to optimize those parts of the code (usually only a tiny fraction) that
really need to be as fast as possible [ 59 ]. This includes so-called compiler macros, which can transform function
calls into more efficient code at runtime, and a mandatory disassembler, which enables
programmers to fine-tune time-critical functions until the compiled code matches their
expectations. It should also be emphasized that while the C or Java compiler is 'history' once
the compiled program is started, the Lisp compiler is always present and can thus generate new,
fast code while the program is already running. This is rarely used in finished applications
(except for some areas of AI), but it is an important feature during development and helpful
for explorative programming.
To further debunk the popular misconception that Lisp languages are slow, Clojure was
recently used to process and analyze SAM/BAM files [ 39 ] with significantly less lines of code and almost
identical speeds as SAMTools [ 73 ], which is written in the C programming language. In addition, Common
Lisp was recently used to build a high-performance tool for preparing sequence alignment/map
files for variant calling in sequencing pipelines [ 6 ]. This HPC tool was shown to significantly outperform
SAMTools and Picard on a variety of benchmarks [ 6 ].
A case study: Pathway Tools
Pathway Tools [ 74
, 75 ] is an example
of a large bioinformatics software system written in Common Lisp (Allegro Common Lisp from
Franz Inc.). Pathway Tools has among the largest functionality of any bioinformatics software
system, including genome informatics, regulatory network informatics, metabolic pathway
informatics and omics data analysis. For example, the software includes a genome browser that
zooms from the nucleotide level to the chromosome level; it infers metabolic reconstructions
from annotated genomes; it computes organism-specific layouts of metabolic map diagrams; it
computes optimal routes within metabolic networks; and it can execute quantitative metabolic
flux models.
The same Pathway Tools binary executable can execute as both a desktop window application
and as a Web server. In Web server mode, Pathway Tools powers the BioCyc.org Web site, which
contains 7600 organism-specific Pathway/Genome Databases, and services ∼500 000 unique
visitors per year and up to 100 000 page views per day. Pathway Tools uses the 'hot-swapping'
capabilities of Common Lisp to download and install software patches at user sites and within
the running BioCyc Web server. Pathway Tools has been licensed by 7200 groups, and was found to
have the best performance and documentation among multiple genome database warehousing systems
[ 76 ].
Pathway Tools consists of 680 000 lines of Common Lisp code (roughly the equivalent of 1 400
000 lines of C or Java code), organized into 20 subsystems. In addition, 30 000 lines of
JavaScript code are present within the Pathway Tools Web interface. We chose Common Lisp for
development of Pathway Tools because of its excellent properties as a high-level, highly
productive, easy-to-debug programming language; we strongly believe that the choice of Common
Lisp has been a key factor behind our ability to develop and maintain this large and complex
software system.
A case study: BioBike
BioBike provides an example of a large-scale application of the power of homoiconicity. In
personal communication, the inventor of BioBike, Jeff Shrager, explained why Lisp (in this
case, Common Lisp) was chosen as the implementation language, an unusual choice even for the
early 2000's. According to Shrager, Lisp-style DSL creation is uniquely suited to 'living'
domains, such as biology, where new concepts are being introduced on an ongoing basis (as
opposed to, for example, electronics, where the domain is better understood, and so the
conceptual space is more at rest). Shrager pointed out that as Lisp-based DSLs are usually
implemented through macros, this provides the unique capability of creating new language
constructs that are embedded in the home programming language (here, in Lisp). This is a
critical distinction: in most programming languages, DSLs are whole new programming languages
built on top of the base language, whereas in Lisp, DSLs are built directly into the
language.
Lisp-based DSLs commonly show up in two sorts of domain-specific control structures:
WITH- clauses and MAP- clauses. By virtue of Lisp's homoiconicity, such
constructs can take code as arguments, and can thereby create code-local bindings, and do
various specialized manipulation directly on the code itself, in accord with the semantics of
the new construct. In non-homoiconic languages, users must do this either by creating new
classes/objects, or through function calls or via an ugly hack commonly referred to as
'Greenspun's 10th rule' [ 77 ], wherein users must first implement a quasi-LFL on top of the base
language, and then implement the DSL in that quasi-LFL. Both the object-creation and
function-call means of creating new constructs lead to encapsulation problems, often requiring
ugly manipulations such as representing code as strings, passing code-conditionalizing
arguments, and then having to either globalize them, or re-pass them throughout a large part of
the codebase. The Lisp-like methods of embedding DSLs into the base language via macros, one
can simply use, for example, a WITH-GENES or a MAP-GENES macro wrapper, and within these, all
one need do is to write normal everyday Lisp code, and the wrapper, because it has access to
and can modify the code that gets run, has no such firewalls, enabling a much more powerful
sort of computation. This greatly simplifies the incremental creation and maintenance of the
DSL, and it is for this reason, argues Shrager, that Lisp (and LFLs more generally) is well
suited to biology. Being a science that is creating new concepts constantly, it is especially
important to be able to flexibly add concepts to the DSL.
BioBike was created by a team led by Jeff Shrager and JP Massar, and later Jeff Elhai. Its
core Web listener is almost 15 000 lines of Common Lisp code in 25 modules, and the entire
BioBike system is nearly 400 000 lines of code in about 850 modules, including the Web
listener, many specialized bioinformatics modules, a scratch-like visual programming language
(built using a specialized LFL that compiles to JavaScript, because of Peter Siebel), a
specialized bioinformatics-oriented frame system (because of Mike Travers) and many other
smaller modules.
Perspectives and outlook
Historically speaking, Lisp is the second oldest (second only to Fortran) programming
language still in use and has influenced nearly every major programming language to date with
its constructs [ 78 ].
For example, it may be surprising to learn that R is written atop of Scheme [ 79 ]. In fact, R borrows directly
from its Lisp roots for creating embedded domain-specific languages within R's core language
set [ 80 ]. For
instance, ggplot2 [ 81
], dplyr [ 82 ] and
plyr [ 83 ] are all
examples of DSLs in R. This highlights the importance and relevance of Lisp as a programmable
programming language, namely the ability to be user-extensible beyond the core language set.
Given the wide spectrum of domains and subdomains in bioinformatics and computational biology
research, it follows that similar applications tailored to genomics, proteomics, metabolomics
or other research fields may also be developed as extensible macros in Common Lisp. By way of
analogy, perhaps a genomics equivalent of ggplot2 or dplyr is in store in the not-so-distant
future. Advice for when such pursuits are useful is readily available [ 84 ]. Perhaps even more
importantly, it is imperative to take into the consideration the future of statistical
computing [ 34 ],
which will form the big data backbone of artificial intelligence and machine learning
applications in bioinformatics.
Conclusions
New programming language adoption in a scientific community is both a challenging and
rewarding process. Here, we advocate for and propose a greater inclusion of the LFLs into
large-scale bioinformatics research, outlining the benefits and opportunities of the adoption
process. We provide historical perspective on the influence of language choice on research
trends and community standards, and emphasize Lisp's unparalleled support for homoiconicity,
domain-specific languages, extensible macros and error handling, as well as their significance
to future bioinformatics research. We forecast that the current state of Lisp research in
bioinformatics and computational biology is highly conducive to a timely establishment of
robust community standards and support centered around not only the development of
bioinformatic domain-specific libraries but also the rise of highly customizable and efficient
machine learning and AI applications written in languages like Common Lisp, Clojure and
Scheme.
Key Points
Lisp empowers programmers to write faster programs faster. An empirical study shows that
when programmers tackle the same problems in Lisp, C/C ++ and Java, that the Lisp
programs are smaller (and therefore easier to maintain), take less time to develop and run
faster.
The Lisp family of programming languages (Common Lisp, Scheme and Clojure) makes it easy
to create extensible macros, which facilitate the creation of modularized extensions to
help bioinformaticians easily create plug-ins for their software. This, in turn, paves the
way for creating enterprise-level, fault-tolerant domain-specific languages in any research
area or specialization.
The current state of Lisp research in bioinformatics and computational biology is at a
point where an official BioLisp community is likely to be established soon, especially
considering the documented shortcomings of mainstream programming languages like R and
Python when compared side by side with identical implementations in Lisp.
Bohdan B. Khomtchouk is an NDSEG Fellow and PhD candidate in the Human Genetics and Genomics
Graduate Program at the University of Miami Miller School of Medicine. His research interests
include bioinformatics and computational biology applications in HPC, integrative multi-omics,
artificial intelligence, machine learning, mathematical genetics, biostatistics, epigenetics,
visualization, search engines and databases.
Edmund Weitz is full professor at the University of Applied Sciences in Hamburg, Germany. He
is a mathematician and his research interests include set theory, logic and combinatorics.
Peter D. Karp is the director of the Bioinformatics Research Group within the Artificial
Intelligence Center at SRI International. Dr Karp has authored >130 publications in
bioinformatics and computer science in areas including metabolic pathway bioinformatics,
computational genomics, scientific visualization and scientific databases.
Claes Wahlestedt is Leonard M. Miller Professor at the University of Miami Miller School of
Medicine and is working on a range of basic science and translational efforts in his roles as
Associate Dean and Center Director for Therapeutic Innovation. The author of some 250
peer-reviewed scientific publications, his ongoing research projects concern bioinformatics,
epigenetics, genomics and drug/biomarker discovery across several therapeutic areas. He has
experience not only from academia but also from leadership positions in the pharmaceutical and
biotechnology industry.
Acknowledgements
B.B.K. dedicates this work to the memory of his uncle, Taras Khomchuk. B.B.K. wishes to
acknowledge the financial support of the United States Department of Defense (DoD) through the
National Defense Science and Engineering Graduate Fellowship (NDSEG) Program: this research was
conducted with Government support under and awarded by DoD, Army Research Office (ARO),
National Defense Science and Engineering Graduate (NDSEG) Fellowship, 32 CFR 168a. C.W. thanks
Jeff Shrager for critical review and helpful comments on the manuscript.
[Edited] [Highly desirable] Make a semicolon optional at the end of the line,
if there is a balance of brackets on the line and the statement looks syntactically correct
(optional pragma "soft semicolon", similar to the solution used in famous IBM PL/1 debugging
compiler). That can help sysadmins who use bash and Perl in parallel and work from
command line with vi or similar editors, and are not using such editors as Komodo Edit which
flag syntax errors. If might make sense to enable this pragma only via option -d of the
interpreter. In this case it will suit as a pure debugging aid, cutting the number of
iterations of editing the source before actual run. It does not make much sense to leave
statements without semicolons in the final, production version of the program. See, for
example, the discussion in Stack Overflow
Do you recommend using semicolons after every statement in JavaScript
if we assume that somebody uses this formatting to suffix conditionals
I do, pretty much all the time! The ability to span a statement over multiple lines
without jumping through backslash hoops is one of the things that makes Perl so attractive.
I also think it makes code much easier to read rather than having excessively long lines
that involve either horizontal scrolling or line wrapping. As to your comment regarding excessive length
identifiers, I come from a Fortran IV background where we had a maximum of 8 characters for
identifiers (ICL 1900 Fortran compiler) so I'm all for long, descriptive and unambiguous
identifiers that aid those who come after in understanding my code.
It might make sense to enable it only with -d options as a help for debugging, which
cuts the number of debugging runs for those who do not have editor with built-in syntax
checking (like ActiveState Komodo Editor; which really helps is such cases ).
That list includes most Linux/Unix system administrators, who use just command line and
vi or similar. And they also use bash of daily basis along with Perl, which increases the
probability of making such an error. And this is probably one of the most important
category of uses for the future of Perl: Perl started with this group (Larry himself,
Randal L. Schwartz, Tom Christiansen, etc) and after a short affair with the Web
programming (yahoo, etc) and bioinformatics (bioperl) retreated back to the status of the
scripting language of choice for the elite Unix sysadmins.
That does not exclude other users and applications, but I think the core of Perl users
are now Unix sysadmins. And their interests should be reflected in Perl 7 with some
priority.
BTW, I do not see benefits of omitted semicolons in the final program (as well as, in
certain cases, omitted round brackets).
In the following, the first line has a balance of brackets and looks syntactically
correct. Would you expect the lexer to add a semicolon?
$a = $b + $c
+ $d + $e;
Yes, and the user will get an error. This is similar to previous example with
trailing on a new line
if (1);
The first question is why he/she wants to format the code this way if he/she suffers
from "missing semicolons" problem, wants to avoid missing semicolon error and, supposedly
deliberately enabled pragma "softsemicolons" for that?
This is the case where the user need to use #\ to inform the scanner about his choice.
But you are right in a sense that it creates a new type of errors -- "missing
continuation." And that there is no free lunch. This approach requires specific discipline
to formatting your code.
The reason I gave that code as an example is that it's a perfectly normal way of
spreading complex expressions over multiple lines: e.g. where you need to add several
variables together and the variables have non-trivial (i.e. long) names,
e.g.
$pressure = $partial_pressure_nitrogen + $partial_pressure_oxygen +
$partial_pressure_water_vapour + $partial_pressure_argon +
$partial_pressure_carbon_dioxide;[download]
In this case, the automatic semicolons are unhelpful and will give rise to confusing error
messages. So you've just switched one problem for another, and raised the cognitive load -
people now need to know about your pragma and also know when its in scope.
Yes it discourages certain formatting style. So what ? If you can't live without such
formatting (many can) do not use this pragma. BTW you can always use extra parentheses,
which will be eliminated by the parser as in
* How exactly does the lexer/parser know when it should insert a soft semicolon?
* How exactly does it give a meaningful error message when it inserts one where the user
didn't intend for there to be one?
My problem with your proposal is that it seems to require the parser to apply some
complex heuristics to determine when to insert and when to complain meaningfully. It is not
obvious to me what these heuristics should be. My suspicion is that such an implementation
will just add to perl's already colourful collection of edge cases, and just confuse both
beginner and expert alike.
Bear in mind that I am one of just a handful of people who actively work on perl's lexer
and parser, so I have a good understanding of how it works, and am painfully aware of its
many complexities. (And its quite likely that I would end up being the one implementing
this.)
The lexical analyser is Perl is quite sophisticated due to lexical complexity of the
language. So I think it already counts past lexems and thus can determine the balance of
"()", '[]' and "{}"
So you probably can initially experiment with the following scheme
If all the following conditions are true
You reached the EOL
Pragma "softsemicolon" is on
The balance is zero
[Edited] The last processed token in not ',', '.' '=' *and all derivatives
like ++, -++),"=='( and other conditionals like <,>,!=, =<, <=.<=,
eq,etc), ':','&','&&','!',"||",'+','-','*' or similar tokens which imply the
continuation of the statement.
[Edited] The next token (not symbol but token) via look-ahead buffer is not
one of the set "{", "}", ';', and ".", "!!", "+"(but not "++") '-','*' and several others
(see above).
the lexical analyser needs to insert lexem "semicolon" in the stream of lexem passed to
syntax analyser.
The warning issued should be something like:
"Attempt to correct missing semicolon was attempted. If this is incorrect please use
extra parenthesis or disable pragma "softsemicolon" for this fragment."
From what I read, Perl syntax analyser relies on lexical analyser in some
unorthodox way, so it might be possible to use "clues" from syntax analyser for improving
this scheme. See, for example, the scheme proposed for recursive descent parsers in:
Follow set error recovery
C Stirling - Software: Practice and Experience, 1985 - Wiley Online Library
Some accounts of the recovery scheme mention and make use of non-systematic changes to
their recursive descent parsers in order to improve In the former he anticipates the possibility of
a missing semicolon whereas in the latter he does not anticipate a missing comma
So I think it already counts past lexems and thus can determine the balance of "()",
'[]' and "{}"
It can't currently.
If all the following conditions are true
All of the following satisfy your criteria, are valid and normal perl code,
and would get a semicolon incorrectly inserted based on your criteria: use
softsemicolon; $x = $a + $b; $x = 1 if $condition; $x = 1 unless $condition1 &&
$condition2;[download]
The warning issued should be something like
I didn't ask what the text of the warning should be, I asked how the parser
can determine when the warning should be issued.
the scheme proposed for recursive descent parsers
But perl uses an LR(1) parser, not a recursive descent parser.
All of the following satisfy your criteria, are valid and normal Perl code, and would get
a semicolon incorrectly inserted based on your criteria:
use softsemicolon;
$x = $a
+ $b;
$x = 1
if $condition;
$x = 1 unless $condition1
&& $condition2;
Yes in cases 1 and 2; it depends on depth of look-ahead in case 3. Yes if it
is one symbol. No it it is two(no Perl statement can start with && )
As for "valid and normal" your millage may vary. For people who would want to use this
pragma it is definitely not "valid and normal". Both 1 and 2 looks to me like frivolities
without any useful meaning or justification. Moreover, case 1 can be rewritten
as:
$x =($a + $b);[download]
The case 3 actually happens in Perl most often with regular if and here opening bracket is
obligatory: if ( ( $tokenstr=~/a\[s\]/ || $tokenstr =~/h\[s\]/ ) && (
$tokenstr... ) ){ .... }[download]
Also Python-inspired fascination with eliminating all brackets does not do here any good
1 2 $a=$b=1; 3 $x=1 if $a==1 4 && $b=2;[download]
should generally be written 2 $a=$b=1; 3 $x=1 if( $a==1 4 && $b=2);[download]
I was surprised that the case without brackets was accepted by the syntax analyser. Because
how would you interpret $x=1 if $a{$b}; without brackets is unclear to me. It has
dual meaning: should be a syntax error in one case $x=1 if $a{ $b };[download]
and the test for an element of hash $a in another.
Both 1 and 2 looks to me like frivolities without any useful meaning or
justification
You and I have vastly differing perceptions of what constitutes normal perl
code. For example there are over 700 examples of the 'postfix if on next line' pattern in
the .pm files distributed with the perl core.
There doesn't really seem any point in discussing this further. You have failed to
convince me, and I am very unlikely to work on this myself or accept such a patch into
core.
You and I have vastly differing perceptions of what constitutes normal perl code. For
example there are over 700 examples of the 'postfix if on next line' pattern in the .pm
files distributed with the perl core.
Probably yes. I am an adherent of "defensive programming" who is against
over-complexity as well as arbitrary formatting (pretty printer is preferable to me to
manual formatting of code). Which in this audience unfortunately means that I am a
minority.
BTW your idea that this pragma (which should be optional) matters for Perl standard
library has no connection to reality.
A very large proportion of the replies you have received in this thread are from people
who put a high value on writing maintainable code. "maintainable" is short hand for code
that is written to be understood and maintained with minimum effort over long periods of
time and by different programmers of mixed ability. There is a strong correlation with your
stance of "defensive programming" ... against over-complexity as well as arbitrary
formatting . None of us are arguing with that stance. We are arguing with the
JavaScript semicolon that you would like introduced based on a personal whim in a context
of limited understanding of Perl syntax and idiomatic use.
Personally I use an editor that has an on demand pretty printer which I use frequently.
The pretty printer does very little work because I manually format my code as I go and
almost always that is how the pretty printer will format it. I do this precisely to ensure
my code is not overly complex and is maintainable. I do this in all the languages that I
use and the hardest languages to do that in are Python, VBScript and JavaScript because of
the way they deal with semi-colons.
Oh, and in case it is of interest, dave_the_m is one of the current maintainers
of Perl. He is in a great position to know how the nuts and bolts of an optional semi-colon
change might be made and has a great understanding of how Perl is commonly used. Both give
him something of a position of authority in determining the utility of such a
change.
Optimising for fewest key strokes only makes sense transmitting to Pluto or
beyond
Parser lookaheads are implemented in terms of tokens, not characters. The first token of
yada is a triple-dot, not a dot. While you may think it starts with a dot, that's not how
the parser sees it, so the existence of yada is not relevant here.
You also completely ruin maintainability and extensibility. Consider a filter module
...
my $fixed = $bad =~ y/\x{00d0}/\x{0110}/r # Eth != D-stroke =~
y/\x{0189}/\x{0110}/r # LETTER AFRICAN D != + D-stroke =~ s{\bpra[ck]ti[sc]e\b}{practice}gr
# All 4 seen in docume + nt AB12.38C =~ s{\bX13\.GtrA\.14\b}{X13_GA12}gr # Product got
renamed =~ s{\b1234\s*zip\b}{1234ZIP}gir # Reciever will crash + on badly formed ZIP code
=~ s{\bpays\s*-?\s*bas\b} {The Netherlands}gir # French forms :( =~ ....;[download]
The more examples I see posted by my esteemed co-monks, the less I like the idea, and I
hated it already when I read it in the OP.
As for soft-semicolon you completly misunderstood the situation:
First, nobody force you to use this pragma. And if you do not use it you are not
affected. I am thinking now that it should be enabled only with option -d.
It does not make sense to conduct something like "performance review" in a large
corporation for my proposals concentrating on "soft-semicolon" idea and ignoring all
others. As if it is the only one worth any discussion. It might be the easiest one to piss
off, but it is far from being the most important or far reaching among those proposals.
There is no free lunch, and for some coding styles (including but not limited to coding
styles used in many modules in Perl standard library) it is definitely inappropriate.
Nobody claim that it is suitable for all users. It is an optional facility for those who
want and need it. In a way, it is a debugging aid that allows to cut the number of
debugging runs. And IMHO there is not a zero subset of Perl users who would be interested
in this capability. Especially system administrators who systematically use bash along with
Perl.
Detractors can happily stay with the old formatting styles forever. Why is this so
difficult to understand before producing such an example?
Moreover, how can you reconcile the amount of efforts (and resulting bugs) for the
elimination of extra round brackets in Perl with this proposal? Is not this the same idea
-- to lessen the possible number of user errors?
For me, it looks like a pure hypocrisy - in one case we are spending some efforts
following other scripting languages at some cost; but the other, similar in its essence,
proposal is rejected blindly as just a bad fashion. If this is a fashion, then eliminating
round brackets is also a bad fashion, IMHO.
And why only I see some improvements possible at low cost in the current Perl
implementation and nobody else proposed anything similar or better, or attempted to
modify/enhance my proposals? After all Perl 5.10 was a definite step forward for Perl. Perl
7 should be the same.
I think the effort spend here in criticizing my proposal would be adequate to introduce
the additional parameter into index function ("to" limit). Which is needed and absence of
which dictates using substr to limit the search zone in long strings. Which is sub-optimal
solution unless the interpreter has advanced optimization capabilities and can recognize
such a use as the attempt to impose the limit on the search.
Constructive discussion does not mean pissing off each and every my posts ( one has -17
votes now; looks a little bit like schoolyard bulling ) -- you need to try to find rational
grain in them, and if such exists, try to revise and enhance the proposal.
The stance "I am happy with Perl 'as is' and go to hell with your suggestions" has its
value and attraction, but it is unclear how it will affect the future of the language.
As for soft-semicolon you completly misunderstood the situation: First, nobody force
you to use this pragma. And if you do not use it you are not affected. I am thinking now
that it should be enabled only with option -d.
In the OP you make no mention of a pragma in proposal 1, you just say that it would be
"highly desirable" to have soft semicolons. This implies that you would like it to be the
default behaviour in Perl 7, which, judging by the responses, would hack a lot of people
off, me included. If you are proposing that soft semicolons are only enabled via a pragma
perhaps you should add a note to that effect in the OP, being sure to make it clear that it
is an update rather than silently changing the text.
And IMHO there is not a zero subset of Perl users who would be interested in this
capability. Especially system administrators who systematically use bash along with
Perl.
I spent the last 26 years of my career as a systems administrator (I had no ambition to
leave technical work and become a manager) on Unix/Linux systems and started using Perl in
that role in 1994 with perl 4.036, quickly moving to 5. The lack of semicolon statement
terminators in the various shell programming languages I had to use was a pain in the arse
and moving to Perl was a huge relief as well as a boost to effectiveness. I would not be
the slightest bit interested in soft semicolons and they would, to my mind, be either a
debugging nightmare or would force me into a coding style alien to my usual practice.
to which I say, nonsense! Why add unnecessary round brackets to perfectly valid code?
Use round brackets where they are needed to disambiguate precedence but not where they just
add superfluous noise. Nothing to do with fascination, I've never touched Python!
You should be commended on the amount of thought that you have put into your proposals
and such efforts should not be discouraged. It is unfortunate that your first proposal has
been the most contentious and the one that most responses have latched onto. Sticking to
one's guns is also a praiseworthy trait but doing so in the face of several powerful and
cogent arguments to the contrary from experienced Perl users is perhaps taking it too far.
Making it clear that soft semicolons would not be the default behaviour might apply some
soothing balm to this thread.
It does not make sense to conduct something like "performance review" in a large
corporation for my proposals concentrating on "soft-semicolon" idea and ignoring all
others. As if it is the only one worth any discussion.
Others have already contributed their thoughts on the rest of your proposals,
which I generally agree with and (more significantly) you haven't disputed. IMO, the
primary reason that all the discussion is focusing on soft semicolons is because it's the
only point you're attempting to defend against our criticisms. There was also a brief
subthread about your ideas on substring manipulation, and a slightly longer one about
alternate braces which close multiple levels of blocks, but those only lasted as long as
you continued the debate.
In a way, it is a debugging aid that allows to cut the number of debugging runs.
Seems like just the opposite to me. It may allow you to get your code to run
sooner, but, when it does, any semicolon errors will still be there and need to be fixed in
additional debugging runs. Maybe a marginal decrease in overall debugging time if there's a
line where you never have to fix the semicolon error because that line ends up getting
deleted before you finish, but it seems unlikely to provide any great savings if (as you
assert) such errors are likely to be present on a significant proportion of lines.
Also, even if it does cut out some debugging runs, they're runs with a very fast
turnaround and little-to-no cognitive effort involved. According to your "BlueJ" paper,
even rank beginners need only 8 seconds to fix a missing semicolon error and initiate a new
compile.
That's neither a natural tendency nor an interesting psychological phenomenon. You just
made that up.
Semicolons at the end of a statement are as natural as a full stop "." at the end of a
sentence, regardless of whether the sentence is the last in a paragraph. The verification
process whether a line "looks syntactically correct" takes longer than just hitting the ";"
key, and the chances of a wrong assessment of "correct" may lead to wrong behavior of the
software.
Language-aware editors inform you about a missing semicolon by indenting the following
line as a continuation of the statement in the previous line, so it is hard to miss.
If, on the other hand, you want to omit semicolons, then the discussion should
have informed you that you aren't going to find followers.
Semicolons at the end of a statement are as natural as a full stop "." at the end of a
sentence, regardless of whether the sentence is the last in a paragraph.
I respectfully disagree, but your comment can probably explain fierce
rejection of this proposal in this forum. IMHO this is a wrong analogy as the level of
precision requred is different. If you analyse books in print you will find paragraphs in
which full stop is missing at the end. Most people do not experience difficulties learning
to put a full stop at the end of the sentence most of the time. Unfortunately this does
work this way in programming languages with semicolon at the end of statement. Because what
is needed is not "most of the time" but "all the time"
My view, supported by some circumstantial evidence and my own practice, is that this is
a persistent error that arise independently of the level of qualification for most or all
people, and semicolon at the end of the statement contradicts some psychological mechanism
programmers have.
Because people have a natural tendency to omit them at the end of the line.
Fascinating. I've never heard of, nor observed, such a tendency. Might you
provide references to a few peer-reviewed studies on the topic? I don't necessarily need
URLs or DOIs (although those would be most convenient) - bibliographic citations, or even
just the titles, should be sufficient, since I have access to a good academic publication
search system.
Offhand, the only potentially-related publication I can locate is "The Case of the
Disappearing Semicolon: Expressive-Assertivism and the Embedding Problem" (Philosophia.
Dec2018, Vol. 46 Issue 4), but that's a paper on meta-ethics, not programming.
Literature is available for free only to academic researchers, so some money might be
involved in getting access.
You can start with
A statistical analysis of syntax errors - ScienceDirect
For example, approximately one-fourth of all original syntax errors in the Pascal sample were
missing semicolons or use of comma in place of semicolon 4) indicates that this type of error
is quite infrequent (80o) and hence needn't be of as great a concern to recovery pro
PDF Error log analysis in C programming language courses
BOOK Programming languages
JJ Horning - 1979 - books.google.com
to note that over 14% of the faults occurring in topps programs during the second half of the
experiment were still semicolon faults (compared to 1% for toppsii), and that missing semicolons
were about Every decision takes time, and provides an opportunity for error
n assessment of locally least-cost error recovery
SO Anderson, RC Backhouse, EH Bugge - The Computer , 1983 - academic.oup.com
sym = semicolon in the former, one is anticipating the possibility of a missing semicolon; in contrast,
a missing comma is 13, p. 229) if sy = semicolon then insymbol else begin error(14); if sy = comma
then insymbol end Both conditional statements accept semicolons but the
The role of systematic errors in developmental studies of programming language learners
J Segal, K Ahmad, M Rogers - Journal of Educational , 1992 - journals.sagepub.com
Errors were classified by their surface characteristics into single token (missing gathered from
the students, was that they would experience considerable difficulties with using semicolons,
and that the specific rule of ALGOL 68 syntax concerning the role of the semicolon as a
Cited by 9 Related articles
Follow set error recovery
C Stirling - Software: Practice and Experience, 1985 - Wiley Online Library
Some accounts of the recovery scheme mention and make use of non-systematic changes to
their recursive descent parsers in order to improve In the former he anticipates the possibility of
a missing semicolon whereas in the latter he does not anticipate a missing comma
A first look at novice compilation behaviour using BlueJ
MC Jadud - Computer Science Education, 2005 - Taylor & Francis
or mark themselves present from weeks previous they may have missed -- either way change
programmer behaviour -- perhaps encouraging them to make fewer "missing semicolon" errors,
or be or perhaps highlight places where semicolons should be when they are missing
Making programming more conversational
A Repenning - 2011 IEEE Symposium on Visual Languages , 2011 - ieeexplore.ieee.org
Miss one semicolon in a C program and the program may no longer work at all Similar to code
auto-completion approaches, these kinds of visual programming environments prevent syntactic
programming mistakes such as missing semicolons or typos
Literature is available for free only to academic researchers, so some money might be
involved in getting access.
No problem here. Not only do I work at an academic library, I'm the primary
responsible for the proxy we use to provide journal access for off-campus researchers. All
the benefits of being an academic researcher, with none of the grant proposals!
A statistical analysis of syntax errors - ScienceDirect
The first thing to catch my eye was that the abstract states it found that
syntax errors as a whole (not just semicolon errors) "occur relatively infrequently", which
seems to contradict your presentation of semicolon problems as something which constantly
afflicts all programmers.
Going over the content of the paper itself, I couldn't help noticing that a substantial
fraction of the semicolon errors discussed were in contexts idiosyncratic to Pascal which
have no Perl equivalent, such as the use of semicolons to separate groups of formal
parameters (vs. commas within each group); using semicolon after END most of the time, but
a period at the end of the program; or incorrectly using a semicolon before ELSE. Aside
from being idiosyncratic, these situations also have the common feature of being cases
where sometimes a semicolon is correct and sometimes a semicolon is
incorrect, depending on the context of the surrounding code - which is precisely the major
criticism of your "make semicolons sometimes optional, and escaping line breaks
sometimes required, depending on the context of the surrounding code". The primary
issue in these cases is that the rules change based on context, and you've proposed
propagating the larger problem in an attempt to resolve a smaller problem which, it seems,
only you perceive.
I also note that the data used in this research consisted of code errors collected from
two university programming classes, one of which was an introductory course and the other a
relatively advanced one. It is to be expected that semicolon errors (particularly given the
Pascal idiosyncrasies I mentioned above) would be common in code written for the
introductory course. It would be interesting to see how the frequency compared between the
two courses; I expect that it would be much, much lower in the advanced course - and lower
still in code written by practicing professionals in the field, which was omitted entirely
from the study.
Oh, and a number of other comments in this discussion have mentioned using syntax-aware
editors. Did those even exist in 1978, when this paper was published? Sorry, I'm just being
silly with that question - the paper mentions card decks and keypunch errors, and says that
the students were asked to "access [the compiler] using a 'cataloged procedure' of job
control statements". These programs weren't entered using anything like a modern text
editor, much less one with syntax awareness. (I wasn't able to find a clear indication of
whether the CDC 6000 Series, which is the computer these programs were compiled on, would
have used a card reader or a keyboard for them to enter their code, but I did find that CDC
didn't make a full-screen editor available to time-sharing users on the 6000 series until
1982, which is well after the paper's publication date.)
A first look at novice compilation behaviour using BlueJ
Yep, this one indeed found that missing semicolons were the most common type
of compilation error at 18%, with unknown variable name and missing brackets in a dead heat
for second place at 12%. Of course, it also found that the median time to correct and run
another compile was only 8 seconds after getting a missing semicolon error, so hardly a
major problem to resolve.
Also, once again, as even stated in the title of the paper, this was limited to code
written by novice programmers, taking a one-hour-a-week introductory course, so it seems
misguided to make assertions about the semicolon habits of experienced programmers based on
its findings.
Making programming more conversational
The only mentions of semicolons in this document are " Miss one semicolon
in a C program and the program may no longer work at all. " and " Instead of typing
in text-based instructions, many visual programming languages use mechanisms such as drag
and drop to compose programs. Similar to code auto-completion approaches, these kinds of
visual programming environments prevent syntactic programming mistakes such as missing
semicolons or typos. " While these statements confirm that semicolons are important and
that programmers can sometimes get them wrong (neither of which has been in dispute here),
they make no attempt to examine how commonly semicolon-related errors occur. Given that the
purpose of this paper was to introduce a new form of computer-assisted programming rather
than to examine existing coding practices, I doubt that the authors even considered looking
into the frequency of semicolon errors.
I was not able to locate the remaining papers you mentioned by doing title or author
searches using Ebsco's metasearch tools.
Highly desirable Make a semicolon optional at the end of the line
Highly un desirable. If things to be made optional for increased readability, not
this, but making braces optional for singles statement blocks. But that won't happen
either.
Highly Questionable Introduce pragma that specify max allowed length of single and
double quoted string
Probably already possible with a CPAN module, but who would use it? This is more something
for a linter or perltidy.
Highly desirable Compensate for some deficiencies of using curvy brackets as the
block delimiters
Unlikely to happen and very un undesirable. The first option is easy } #
LABEL (why introduce new syntax when comments will suffice). The second is just plain
illogical and uncommon in most other languages. It will confuse the hell out of every
programmer.
Make function slightly more flexible
a) no b) Await the new signatures c) Macro's are unlikely to happen. See the
problems they faced in Raku. Would be fun though
Long function names
Feel free to introduce a CPAN module that does all you propose. A new function for trimming
has recently been introduced and spun off a lot of debate. I think none of your proposed
changes in this point is likely to gain momentum.
Allow to specify and use "hyperstrings"
I have no idea what is to be gained. Eager to learn though. Can you give better
examples?
Put more attention of managing namespaces
I think a) is part of the proposed OO reworks for perl7 based on Cor , b) is just plain silly, c) could be useful, but
not based on letters but on sigils or interpunction, like in Raku</lI.
Analyze structure of text processing functions in competing scripting
languages
Sounds like a great idea for a CPAN module, so all that require this functionality can use
it
Improve control statements
Oooooh, enter the snake pit! There be dragons here, lots of nasty dragons. We have has
given/when and several switch implementations and suggestions, and so far there has been no
single solution to this. We all want it, but we all have different expectations for its
feature sets and behavior. Wise people are still working on it so expect *something* at
some time.
by you !!! on Sep 10,
2020 at 16:57 UTC Reputation: -4
Because }:LABEL actually forcefully closes all blocks in between, but the comment just
informs you which opening bracket this closing bracket corresponds to. and, as such, can
placed on the wrong closing bracket, especially if the indentation is wrong too. Worsening
already bad situation.
Your "one brace to close them all" idea is not needed if you have a decent editor - and,
incidentally, would most likely break this feature in many/most/all editors which provide
it.
by you !!! on Sep 11,
2020 at 16:45 UTC Reputation: -5
Highly desirable Make a semicolon optional at the end of the line
Highly undesirable. If things to be made optional for increased readability,
not this, but making braces optional for singles statement blocks. But that won't happen
either.
Making single statement blocks is a programming language design blunder made in PHP. It
creates the so called "dangling else" problem.
BTW, if this is "highly undesirable", can you please explain why Perl designers took
some efforts to allow omitting semicolon before closing brace?
Which works evenly fine when semi-colons are added.
Following the complete discussion, I wonder why you persist. To me it is obvious that
Perl is not (or should not be) your language of choice.
If you really think trailing semi-colons should be omitted, do find a language that
allows it. You have come up with exactly ZERO arguments that will convince the other users
of perl and perl language designers and language maintainers.
To me however, all the counter-arguments were very insightful, so thank you for starting
it anyway.
/me wonders how many users would stop using perl completely if your rules would be
implemented (wild guess 90%) and how many new users the language would gain (wild guess
1%)
Making Perl more like modern Python or JS is not improvement to language, you need another
word for that, something like "trends" or "fashion", or something like that. I see this list
as a simplification of language (and in a bad way), not improvement. As if some newby
programmer would not want to improve himself, to get himself up to match the complexity of
language, but blaim language complexity and demand the language complexity to go down to his
(low) level. "I don't want to count closing brackets, make something that will close them
all", "I don't want to watch for semicolons, let interpreter watch for end of sentence for
me", "This complex function is hard to understand and remember how to use it in a right way,
give me bunch of simple functions that will do the same as this one function, but they will
be easy to remember".
Making tool more simple will not make it more powerful, or more efficient, but instead
could make it less efficient, because the tool will have to waste some of its power to
compensate user's ineptitude. Interpreter would waste CPU and memory to comprehend sentence
ending, this "new" closing brackets and extra function calls, and what's gain here? I see
only one - that newby programmer could write code with less mind efforts. So it's not
improvement of language to do more with less, but instead a change that will cause tool do
same with more. Is it improvement? I don't think so.
by you !!! on Sep 10,
2020 at 16:52 UTC Reputation: -7
As if some newby programmer would not want to improve himself, to get himself up to match
the complexity of language, but blaim language complexity and demand the language
complexity to go down to his (low) level.
The programming language should be adapted to actual use by programmers, not to some
illusions of actual use under the disguise of "experts do not commit those errors." If the
errors committed by programmers in the particular language are chronic like is the case for
semicolons and missing closing brace something needs to be done about them, IMHO.
The same is true with the problem of "overexposure" of global variables. Most
programmers at some point suffer from this type of bugs. That's why "my" was pushed into
the language. But IMHO it does not go far enough as it does not distinguish between reading
and modifying a variable. And "sunglasses" approach to visibility of global variable might
be beneficial.
BTW the problem of missing parentheses affects all languages which use this "{" and "}"
as block delimiters and the only implementation which solved this complex problem
satisfactory were closing labels on closing block delimiter in PL/1 ("}" in Perl;
"begin/end" pair in PL/1). Like with "missing semicolon" this is the problem from which
programmer suffer independently of the level of experience with the language.
So IMHO any measures that compensate for "dangling '}' " problem and provide better
coordination between opening and closing delimiters in the nested blocks would be
beneficial.
Again the problem of missing closing brace is a chronic one. As somebody mentioned here
the editor that has "match brace" can be used to track it but that does not solve the
problem itself, rather it provides a rather inefficient (for complex script) way to
troubleshoot one. Which arise especially often if you modify a long and not written by you
(or written by you long go) script. I experienced even a case when syntactically { } braces
structure were correct but semantically wrong and that was detected only after the program
was moved to production. Closing label on bracket would prevent it.
If you write short subroutines, as you should, you don't suffer from misplaced closing
curly braces. I had problems with them, especially when doing large edits on code not
written by me, but the editor always saved me.
More or less agree WRT mismatched closing curlies. I see it pretty much entirely as an
editor issue.
(I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping? At
least I recall that ("Your editor will keep it straight") being seriously offered as a
valid dismissal of the criticism against S-W-A-G . . .)
The cake is a lie.
The cake is a lie.
The cake is a lie.
I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping?
No the argument is different, but using indentation to determine block nesting
does allow multiple closure of blocks, as a side effect. Python invented strange mixed
solution when there is an opening bracket (usually ":") and there is no closing bracket --
instead indent is used as the closing bracket.
The problem is that it breaks too many other things, so here the question "whether it
worth it" would be more appropriate, then in the case of soft semicolons.
As somebody mentioned here the editor that has "match brace" can be used to track it
but that does not solve the problem itself, rather it provides a rather inefficient (for
complex script) way to troubleshoot one. Which arise especially often if you modify the
script.
I would submit that, if you have enough levels of nested blocks that "match
brace" becomes a cumbersome and "inefficient" tool, then your problem is that your code is
overly-complex and poorly-structured, not any issue with the language or the editor. Good
code does not have 47-level-deep nested blocks.
by likbez on Sep 15,
2020 at 04:12 UTC Reputation: -1
Implement head and tail functions as synonyms to substr ($line,0,$len) and
substr($line,-$len)
Nothing's stopping you from doing that right now.
Yes, you can do it with certain limitations and the loss of flexibility as a
user function. The key question here is not whether "you can do it" -- but how convenient
it will be in comparison with the "status quo", are key categories of users benefit
directly from this addition (for Perl first of all whether sysadmins will benefit), and
what is the cost -- how much trouble is to add it into the already huge interpreter, which
inevitably increase already large number of built-in functions. As well as whether "in the
long run" new functions can retire same "inferior" functions like chomp and
chop
NOTE: it is better to call them ltrim and rtrim.
With chomp, which is far more frequently used out of two, replacing it by rtrim is just
a renaming operation, with chop you need some "inline" function capability
(macrosubstitution). So rtrim($line) should be equivalent of chomp($line) --assuming that
"\n" is the default second argument for rtrim)
Also any user function by definition has more limited flexibility in comparison to the
built-in function and is less efficient unless implemented in C.
Without introduction of additional argument for a user-defined function it is impossible
to determine if the function ltrim has target or not (if not, it should modify the
first parameter.
So on user function level you need to have two functions: ltrim and
myltrim ), as it this case the second argument has a more natural meaning.
On use defined function level you have quite limited capabilities to determine the
lexical type of the second argument (at run time in Perl you can only distinguish between
the numeric type and the string -- not that regex is passed, or translation table is
passed. Actually some languages allow to specify different entry points to the function
depending on the number and type of arguments (string, integer, float, pointer, etc)
passed. In Perl terms this looks something like extended signatures:
sub name {
entry ($$){ } entry (\$\$){ } }[download]
A couple of examples:
The call ltrim($line,7) should be interpreted as
$line=substr($line,7)
but the call $header=ltrim($line,'<h1>'); obviously should be interpreted
as
$header=substr($line,index($line,'<h1>');
Also if you want to pass regex or translation table you need somehow to distinguish type
of the last argument passed. So instead of the function call
$body=ltrim($line,/\s*/); you need to use
$body=ltrim($line,'\s*','r'); which should be interpreted as
the same problem arise if you want to pass a set of characters to be eliminated like in
tr/set1//d;
$body=ltrim($line," \t",'t'); # equivalent to ($body)=split(' ',$line,1);
One argument in favor of such functions is that in many languages the elimination of
free space at the beginning and end of strings is recognized as an important special case
and built-in function provided for this purpose. Perl is one of the few in which there is
no such special operation.
Allow default read access for global variables, but write mode only with own
declaration via special pragma, for example use sunglasses.
You can do this already. But it doesn't make sense to do this instead of creating
accessors.
Allow to specify set of characters, for which variable acquires my attribute
automatically, as well as the default minimum length of non my variables via pragma
my
There's a lot of problems with this. But hey, if you want this, there's nothing's stopping
from writing a module that provide this "feature".
...BTW the problem of missing parentheses affects all languages which use this "{" and "}"
as block delimiters and the only implementation which solved this complex problem
satisfactory were closing labels on closing block delimiter in PL/1 ("}" in Perl; "begin/end"
pair in PL/1). Like with "missing semicolon" this is the problem from which programmer suffer
independently of the level of experience with the language.
So IMHO any measures that compensate for "dangling '}' " problem and provide better
coordination between opening and closing delimiters in the nested blocks would be
beneficial.
Again the problem of missing closing brace is a chronic one. As somebody mentioned here
the editor that has "match brace" can be used to track it but that does not solve the problem
itself, rather it provides a rather inefficient (for complex script) way to troubleshoot one.
Which arise especially often if you modify a long and not written by you (or written by you
long go) script. I experienced even a case when syntactically { } braces structure were
correct but semantically wrong and that was detected only after the program was moved to
production. Closing label on bracket would prevent it.
If you write short subroutines, as you should, you don't suffer from misplaced closing
curly braces. I had problems with them, especially when doing large edits on code not
written by me, but the editor always saved me.
More or less agree WRT mismatched closing curlies. I see it pretty much entirely as an
editor issue.
(I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping? At
least I recall that ("Your editor will keep it straight") being seriously offered as a
valid dismissal of the criticism against S-W-A-G . . .)
The cake is a lie.
The cake is a lie.
The cake is a lie.
I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping?
No the argument is different, but using indentation to determine block nesting
does allow multiple closure of blocks, as a side effect. Python invented mixed solution
when there is an opening bracket (usually ":") and there is no closing bracket -- instead
the change in indent is used as the proxy for the presence the closing bracket.
The problem is that it breaks too many other things, so here the question "whether it
worth it" would be more appropriate, then in the case of soft semicolons or "reverse labels
on "}" like "}LABEL" .
I think these data are flawed since although writing vanilla programs is encouraged
(simple but good code), some of the entries have done an extraordinary effort to make their
program fast. For instance look at the Haskell entry for k-nucleotide. It rolls it's own
hash table. It claims that there is no library for hash table, but there is one, and using
it would cut the code size to about a quarter in size.
Same is somewhat true for C/C++ implementation. Using specialized SIMD instructions to
get better performance, or using the GMP library which reduces all languages to: who can
call a library faster.
If you have measurements, why not improve them with a visualization?
"Improve them" is good by definition - unfortunately a visualization can also be a
meaningless mush of bogus relationships and misunderstanding :-)
To better visualize which languages' implementations took advantage of parallelism
... Some stay in the same spot, probably indicating that the Computer Language Benchmarks
Game doesn't have the best implementations.
That seems to be a plucked-out-of-thin-air guess.
Shouldn't you have figured out what (if anything) it indicates?
For the single-core case, 27% of the languages are on the list above; for quad-core,
48% made the cut.
Does it make any difference to your statistics that the single core data simply includes
more language implementations than the quad core data?
Guillaume Marceau produced informative plots ... showing the tradeoffs between
metrics which the CLBG has now included on their site
No, Guillaume Marceau's plots are not included on the website.
Yes, because Guillaume Marceau showed people were interested in seeing code-used
time-used scatterplots - I designed a new chart.
I guess I'm happy there are quad-core numbers on here, but are they really useful? I
looked through the benchmarks and support for parallelism is spotty, and I'm not really
sure they represent things people even want to do in parallel. Does it make sense to have
parallel benchmarks for everything?
For example, binary-trees benchmark "allocates MANY, MANY binary trees". Yeah, ok,
that's embarrassingly parallel. Yay! What are you going to do with the trees once you have
them allocated, and how much memory bandwidth do you need to do it all on your quad-core
machine?
Also disappointing: n-body is not parallelized despite being one of the more interesting
parallelizable problems in there. And the various ports of it (e.g. to OCaml) look like
they're really just line-for-line ports of the C version. Wouldn't you write this
differently if you were really an OCaml person?
Another complaint: the OpenMP benchmarks in there don't seem to use any inter-thread
communication more complicated than a reduction, and they're GNU OpenMP. Nobody uses GNU
OpenMP because it sucks compared to all the other implementations. Granted, they're
commercial, but the GNU guys only test their stuff for correctness, not performance.
Finally, is parallelism really rightly expressed as a function of the programming
language? You've got a few different parallel programming models represented here: threads,
OpenMP, Erlang's actor model (if you can call that different from threads), and essentially
one of those is used in a few different languages. Why not compare the programming model
instead? You can do threads in pretty much any of these languages, and it'd be interesting
to see how that does against models (like OpenMP and, I assume, Erlang) where the compiler
helps out with the parallelization to some degree.
Also, Ruby moves up and to the right and uses *less* memory with more cores wtf?
Ok, I think I've fallen for this sufficiently now :-).
There are a lot of interesting comments about how flawed these benchmarks are. Let me
just point out that the Benchmarks Game folks are quick to acknowledge that. If you don't
like the benchmarks, then perhaps you at least will find that this visualization can reveal
some new questionable properties of the data!
Elvind: Yes, this visualization uses the fastest implementation of each language;
as you've pointed out, even with in a language there can be a significant tradeoff between
the metrics. I wouldn't say that means the data is flawed. It's just showing one point in
the tradeoff space -- an incomplete picture of each language.
Isaac wrote, regarding the fraction of languages that are Pareto-optimal: "Does
it make any difference to your statistics that the single core data simply includes more
language implementations than the quad core data?"
My main point was that a reasonably large fraction of languages are Pareto-optimal.
Beyond that I'm not making any claims, and I wouldn't read too much into the particular
numbers 27% and 48%. (But yes, I suspect that the size of the Pareto-optimal set does in
general depend in nontrivial ways on the number of points in the set. I would guess that
larger sets imply more Pareto-optimal points but a smaller fraction of points being
Pareto-optimal. Maybe theorists have analyzed this... In this particular case, the larger
set has fewer Pareto-optimal points and a smaller fraction of points being
Pareto-optimal.)
@tgamblin > Does it make sense to have parallel benchmarks for everything?
Those aren't "parallel benchmarks" - the task set was established and measured on single
core Intel Pentium 4 five years ago.
@tgamblin > n-body is not parallelized despite being one of the more interesting
parallelizable problems in there
Please design a program that uses multi core for that task and then contribute your
program to the benchmarks game.
(So far people have tried to come up with a multi core program that's faster than the
sequential implementations but have not succeeded - so they don't bother contributing
them.)
@tgamblin > Another complaint: the OpenMP benchmarks
What OpenMP benchmarks? Which benchmarks have OpenMP as a requirement?
@Brighten Godfrey > If you press the movie button in the bottom left, it will
transition to results on a quad-core box. Still normalized by the best single-core
score.
I think I got this wrong earlier, so let's be clear -
You took the summary data for x86 single core and x86 quad core ,
and used the best scores from the single core data to normalize both the single core
and quad core data?
So now let's look at tgamblin's question - Also, Ruby moves up and to the right and
uses *less* memory with more cores wtf?
JRuby memory measurements for some tasks are a lot less on quad core than
single core.
@Isaac Gouy: Those aren't "parallel benchmarks" - the task set was established and
measured on single core Intel Pentium 4 five years ago.
If they're not parallel benchmarks, then why test them on four cores? What do you learn?
This is exactly my point. The parallel benchmarks aren't even things people want to do in
parallel.
@Isaac Gouy: Please design a program that uses multi core for that task and then
contribute your program to the benchmarks game.
I might, someday when I have a little free time. But for anyone who tries this before
me: I would start by setting the number of bodies higher than 5. If that constant is a
requirement, then I imagine no one has succeeded in parallelizing the benchmark because it
doesn't actually do much work.
Also, it's not too hard to find implementations that get speedup .
Caveat: you could argue that parallelizing the 5-body problem is interesting, and that
you could perhaps parallelize over time. Maybe. People have looked into it. But that's a
research problem, and I would counter that no language is going to help you do that.
@Isaac Gouy: What OpenMP benchmarks? Which benchmarks have OpenMP as a
requirement?
The ones that use it -- you need to look at the code to see this. I didn't say
any of them required it.
My point is that maybe the benchmarks, instead of comparing languages for
parallelism, should look at the programming model instead (OpenMP, MPI, threads,
Erlang actors, PGAS, etc.). Otherwise you're falsely attributing any speedup you see to the
language, when maybe it only sped up because a particular parallel paradigm was available
there.
Maybe you've answered my question, though. If they're not really intended to be parallel
benchmarks, none of these points matter anyway.
Isaac wrote: "Just exclude language implementations from the single core data that
are not in the quad-core data - and re-run your analysis, and see what happens."
Since the question you asked above doesn't seem central to my main point I'll forgo
doing that calculation now but you can figure it out the number you're interested in by
inspecting the figure above. (Also, when I said "I suspect that the size of the
Pareto-optimal set does in general depend..." I was referring to Pareto-optimal sets in
general (e.g., a random data set), not this particular data set.)
You took the summary data for x86 single core and x86 quad core, and used the best
scores from the single core data to normalize both the single core and quad core
data?
That's right. If they had been normalized by different values, they wouldn't be directly
comparable.
So now let's look at tgamblin's question - "Also, Ruby moves up and to the right and
uses *less* memory with more cores wtf?" JRuby memory measurements for some tasks are a lot
less on quad core than single core. Look at the quad-core measurements. Look at the
one-core measurements.
I'm not sure what the Benchmarks Game has done, but I wonder if there are very different
implementations or algorithms for the two cases. For example, on chameneos-redux with N=6M,
moving from 1 to 4 cores JRuby gets substantially slower (57 sec -> 167 sec) but uses
substantially less memory (161,480 KB -> 49,580 KB).
@Brighten Godfrey > I'm not sure what the Benchmarks Game has done, but I wonder
if there are very different implementations or algorithms for the two cases.
If you don't know that the programs for the two cases are the same then you don't know
that they are directly comparable.
@Brighten Godfrey > I'm not sure what the Benchmarks Game has done, but I wonder
if there are very different implementations or algorithms for the two cases.
Select Python 3 and be amazed when the movie shows running on quad core increases source
code length!
(Incidentally, you may think that gzipped source code size has something to do with
language "expressiveness" but if you're going to claim that's what it was intended to
measure then I think you need to be able to show where the benchmarks game website says
that.)
Hacker circles, huh? Pretty nice term used. I fairly believe that since internet was
invented, the programming language wars has been evolving and has become more and more
serious. Expressing thoughts and arguments are somehow the main ingredients in the
programming language wars. Let us just sit back and observe what and where these
programming language wars would last and take us.
OK. You are right. So it
will now be interpreted as syntax error, but was valid previously, if we assume that somebody
uses this formatting for suffix conditionals.
That supports another critique of the same proposal -- it might break old Perl 5 scripts and
should be implemented only as optional pragma. Useful only for programmers who experience this
problem.
Because even the fact that this error is universal and occurs to all programmers is disputed
here.
if we assume that somebody uses this formatting to suffix conditionals
I do, pretty much all the time! The ability to span a statement over multiple lines
without jumping through backslash hoops is one of the things that makes Perl so attractive. I
also think it makes code much easier to read rather than having excessively long lines that
involve either horizontal scrolling or line wrapping. As to your comment regarding excessive length identifiers,
I come from a Fortran IV background where we had a maximum of 8 characters for identifiers
(ICL 1900 Fortran compiler) so I'm all for long, descriptive and unambiguous identifiers that
aid those who come after in understanding my code.
We need not "assume that somebody uses this formatting". I do it frequently, and I have
often seen it in other people's code. It is not a purely-hypothetical case.
It might make sense to enable it only with -d options as a help for debugging, which
cuts the number of debugging runs for those who do not have editor with built-in syntax
checking (like ActiveState Komodo Editor; which really helps is such cases ).
That list includes most Linux/Unix system administrators, who use just command line and
vi or similar. And they also use bash of daily basis along with Perl, which increases the
probability of making such an error. And this is probably one of the most important
category of uses for the future of Perl: Perl started with this group (Larry himself,
Randal L. Schwartz, Tom Christiansen, etc) and after a short affair with the Web
programming (yahoo, etc) and bioinformatics (bioperl) retreated back to the status of the
scripting language of choice for the elite Unix sysadmins.
That does not exclude other users and applications, but I think the core of Perl users
are now Unix sysadmins. And their interests should be reflected in Perl 7 with some
priority.
BTW, I do not see benefits of omitted semicolons in the final program (as well as, in
certain cases, omitted round brackets).
As for soft-semicolon you completly misunderstood the situation: First, nobody force you
to use this pragma. And if you do not use it you are not affected. I am thinking now that
it should be enabled only with option -d.
In the OP you make no mention of a pragma in proposal 1, you just say that it would be
"highly desirable" to have soft semicolons. This implies that you would like it to be the
default behaviour in Perl 7, which, judging by the responses, would hack a lot of people off,
me included. If you are proposing that soft semicolons are only enabled via a pragma perhaps
you should add a note to that effect in the OP, being sure to make it clear that it is an
update rather than silently changing the text.
And IMHO there is not a zero subset of Perl users who would be interested in this
capability. Especially system administrators who systematically use bash along with
Perl.
I spent the last 26 years of my career as a systems administrator (I had no ambition to
leave technical work and become a manager) on Unix/Linux systems and started using Perl in
that role in 1994 with perl 4.036, quickly moving to 5. The lack of semicolon statement
terminators in the various shell programming languages I had to use was a pain in the arse
and moving to Perl was a huge relief as well as a boost to effectiveness. I would not be the
slightest bit interested in soft semicolons and they would, to my mind, be either a debugging
nightmare or would force me into a coding style alien to my usual practice.
to which I say, nonsense! Why add unnecessary round brackets to perfectly valid code? Use
round brackets where they are needed to disambiguate precedence but not where they just add
superfluous noise. Nothing to do with fascination, I've never touched Python!
You should be commended on the amount of thought that you have put into your proposals and
such efforts should not be discouraged. It is unfortunate that your first proposal has been
the most contentious and the one that most responses have latched onto. Sticking to one's
guns is also a praiseworthy trait but doing so in the face of several powerful and cogent
arguments to the contrary from experienced Perl users is perhaps taking it too far. Making it
clear that soft semicolons would not be the default behaviour might apply some soothing balm
to this thread.
I do not understand your train of thought. In the first example end of the
line occurred when all brackets are balanced, so it will will be interpretered as
print( "Hello World" ); if( 1 );[download]
So this is a syntactically incorrect example, as it should be. The second example will
be interpreted as
That supports another critique of the same proposal -- it might break old Perl 5 scripts
and should be implemented only as optional pragma. Useful only for programmers who
experience this problem.
Because even the fact that this error is universal and occurs to all programmers is
disputed here.
if we assume that somebody uses this formatting to suffix conditionals
I do, pretty much all the time! The ability to span a statement over multiple lines
without jumping through backslash hoops is one of the things that makes Perl so attractive.
I also think it makes code much easier to read rather than having excessively long lines
that involve either horizontal scrolling or line wrapping. As to your comment regarding excessive length
identifiers, I come from a Fortran IV background where we had a maximum of 8 characters for
identifiers (ICL 1900 Fortran compiler) so I'm all for long, descriptive and unambiguous
identifiers that aid those who come after in understanding my code.
In the following, the first line has a balance of brackets and looks syntactically
correct. Would you expect the lexer to add a semicolon?
$a = $b + $c
+ $d + $e;
Yes, and the user will get an error. This is similar to previous example with
trailing on a new line "if (1);" suffix. The first question is why he/she wants to format
the code this way if he/she suffers from this problem, wants to avoid missing semicolon
error and, supposedly enabled pragma "softsemicolons" for that?
This is the case where the user need to use #\ to inform the scanner about his choice.
But you are right in a sense that it creates a new type of errors -- "missing
continuation." And that there is no free lunch. This approach requires specific discipline
to formatting your code.
The reason I gave that code as an example is that it's a perfectly normal way of
spreading complex expressions over multiple lines: e.g. where you need to add several
variables together and the variables have non-trivial (i.e. long) names, e.g.
[download]
In this case, the automatic semicolons are unhelpful and will give rise to confusing error
messages. So you've just switched one problem for another, and raised the cognitive load - people
now need to know about your pragma and also know when its in scope.
Yes it discourages certain formatting style. So what ? If you can't live without such
formatting (many can) do not use this pragma. BTW you can always use extra parentheses,
which will be eliminated by the parser as in
* How exactly does the lexer/parser know when it should insert a soft semicolon?
* How exactly does it give a meaningful error message when it inserts one where the user
didn't intend for there to be one?
My problem with your proposal is that it seems to require the parser to apply some
complex heuristics to determine when to insert and when to complain meaningfully. It is not
obvious to me what these heuristics should be. My suspicion is that such an implementation
will just add to perl's already colourful collection of edge cases, and just confuse both
beginner and expert alike.
Bear in mind that I am one of just a handful of people who actively work on perl's lexer
and parser, so I have a good understanding of how it works, and am painfully aware of its
many complexities. (And its quite likely that I would end up being the one implementing
this.)
The lexical analyzer is Perl is quite sophisticated due to lexical complexity of the
language. So I think it already counts past lexems and thus can determine the balance of
"()", '[]' and "{}"
So you probably can initially experiment with the following scheme
If all the following conditions are true
You reached the EOL
Pragma "softsemicolon" is on
The balance is zero
The next symbol via look-ahead buffer is not one of the set "{", "}", ';', and ".",
-- no Perl statement can start with the dot. Probably this set can be extended with
"&&", '||', and "!". Also the last ',' on the current line, and some other
symbols clearly pointing toward extension of the statement on the next line should block
this insertion.
the lexical analyzer needs to insert lexem "semicolon" in the stream of lexem passed to
syntax analyzer.
The warning issued should be something like:
"Attempt to correct missing semicolon was attempted. If this is incorrect please use
extra parenthesis or disable pragma "softsemicolon" for this fragment."
From what I read, Perl syntax analyser relies on lexical analyser in some
unorthodox way, so it might be possible to use "clues" from syntax analyser for improving
this scheme. See, for example, the scheme proposed for recursive descent parsers in:
Follow set error recovery
C Stirling - Software: Practice and Experience, 1985 - Wiley Online Library
Some accounts of the recovery scheme mention and make use of non-systematic changes to
their recursive descent parsers in order to improve In the former he anticipates the possibility of
a missing semicolon whereas in the latter he does not anticipate a missing comma
All of the following satisfy your criteria, are valid and normal Perl code, and would get
a semicolon incorrectly inserted based on your criteria:
use softsemicolon;
$x = $a
+ $b;
$x = 1
if $condition;
$x = 1 unless $condition1
&& $condition2;
Yes in cases 1 and 2; it depends on depth of look-ahead in case 3. Yes if it
is one symbol. No it it is two(no Perl statement can start with && )
As for "valid and normal" your millage may vary. For people who would want to use this
pragma it is definitely not "valid and normal". Both 1 and 2 looks to me like frivolities
without any useful meaning or justification. Moreover, case 1 can be rewritten as:
$x =($a
+ $b);
[download]
The case 3 actually happens in Perl most often with regular if and here opening bracket is
obligatory:
if ( ( $tokenstr=~/a\[s\]/ || $tokenstr =~/h\[s\]/ )
&& ( $tokenstr... ) ){ .... }
[download]
Also Python-inspired fascination with eliminating all brackets does not do here any good
I was surprised that the case without brackets was accepted by the syntax analyser.
Because how would you interpret $x=1 if $a{$b}; without brackets is unclear to me.
It has dual meaning: should be a syntax error in one case
$x=1 if $a{
$b
};
[download]
and the test for an element of hash $a in another.
Both 1 and 2 looks to me like frivolities without any useful meaning or
justification
You and I have vastly differing perceptions of what constitutes normal perl
code. For example there are over 700 examples of the 'postfix if on next line' pattern in
the .pm files distributed with the perl core.
There doesn't really seem any point in discussing this further. You have failed to
convince me, and I am very unlikely to work on this myself or accept such a patch into
core.
You and I have vastly differing perceptions of what constitutes normal perl code. For
example there are over 700 examples of the 'postfix if on next line' pattern in the .pm
files distributed with the perl core.
Probably yes. I am an adherent of "defensive programming" who is against
over-complexity as well as arbitrary formatting (pretty printer is preferable to me to
manual formatting of code). Which in this audience unfortunately means that I am a
minority.
BTW your idea that this pragma (which should be optional) matters for Perl standard
library has no connection to reality.
Modern society is built on software platforms that encompass a great deal of our lives.
While this is well known, software is invented by people and this comes at considerable cost.
Notably, approximately $331.7 billion are paid, in the U.S. alone, in wages every year for this
purpose. Generally, developers in industry use programming languages to create their software,
but there exists significant dispersion in the designs of competing language products. In some
cases, this dispersion leads to trivial design inconsistencies (e.g., the meaning of the symbol
+), while in other cases the approaches are radically different. Studies in the literature show
that some of the broader debates, like the classic ones on static vs. dynamic typing or
competing syntactic designs, provide consistent and replicable results in regard to their human
factors impacts.
For example, programmers can generally write correct programs more quickly using static
typing than dynamic for reasons that are now known. In this talk, we will discuss three facets
of language design dispersion, sometimes colloquially referred to as the "programming language
wars."
First, we will flesh out the broader impacts inventing software has on society, including
its cost to industry, education, and government. Second, recent evidence has shown that even
research scholars are not gathering replicable and reliable data on the problem. Finally, we
will give an overview of the facts now known about competing alternatives (e.g., types, syntax,
compiler error design, lambdas).
"... Most people do not experience difficulties learning to put a full stop at the end of the sentence most of the time. Unfortunately this does work this way in programming languages with semicolon at the end of statement. Because what is needed is not "most of the time" but "all the time" ..."
"... My view supported by some circumstantial evidence and my own practice is the this is a persistent error that arise independently of the level of qualification for most or all people, and semicolon at the end of the statement contradicts some psychological mechanism programmers have. ..."
What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff. I compiled some my suggestions and will
appreciate the feedback:
[Highly desirable] Make a semicolon optional at the end of the line, if there is a balance of brackets on the line and
the statement looks syntactically correct ("soft semicolon", the solution used in famous IBM PL/1 debugging compiler).
[Highly Questionable] Introduce pragma that specify max allowed length of single and double quoted string (not not any other
type of literals). That might simplify catching missing quote (which is not a big problem with any decent Perl aware editor anyway)
[Highly desirable] Compensate for some deficiencies of using curvy brackets as the block delimiters:
Treat "}:LABEL" as the bracket closing "LABEL:{" and all intermediate blocks (This idea was also first
implemented in PL/1)
Treat " }.. " symbol as closing all opened brackets up to the subroutine/BEGIN block level and }... including
this level (closing up to the nesting level zero. ). Along with conserving vertical space, this allows search for missing closing
bracket to be more efficient.
Make function slightly more flexible:
Introduce pragma that allows to define synonyms to built-in functions, for example ss for for substr and ix for index
Allow default read access for global variables with subroutines, but write mode only with own declaration via
special pragma, for example use sunglasses;
Introduce inline functions which will be expanded like macros at compile time: sub subindex inline{ $_[0]=substr($_[0],index($_[0],$_[1],$_2]))
}[download]
As extracting of substring is a very frequent operation the use of such long name as substr is counterproductive; it also
contradicts the Perl goal of being concise and expressive .
allow to extract substring via : or '..' notations like $line [$from:$to] (label can't be put inside square brackets
in any case)
Explicitly distinguish between translation table and regular expressions by introducing tt-strings
Implement tail and head functions as synonyms to substr ($line,0,$len) and substr($line,-$len)
With the ability to specify string, regex of translation table(tr style) instead of number as the third argument tail($line,'#')
tail($line,/\s+#\w+$/) tail($line,tt/a-zA-z]/[download]
Implement similar to head and tail function called, for example, trim: trim(string,tt/leftcharacter_set/, tt/right_character_set/);[download]
which deleted all characters from the first character set at the left and all characters from the second character set from
the right, trim(string,,/right_character_set)
strips trailing characters only.
Allow to specify and use "hyperstrings" -- strings with characters occupying any power of 2 bytes (2,4,8, ...). Unicode
is just a special case of hyperstring
$hyper_example1= h4/aaaa/bbbb/cccc/;
$hyper_example2= h2[aa][bb][cc];
$pos=index($hyper_example,h4/bbbb/cccc/)
Put more attention of managing namespaces.
Allow default read access for global variables, but write mode only with own declaration via special pragma, for example
use sunglasses.
Allow to specify set of characters, for which variable acquires my attribute automatically, as well as the default minimum
length of non my variables via pragma my (for example, variables with the length of less then three character should always
be my)
Allow to specify set of character starting from which variable is considered to be own, for example [A-Z] via
pragma own.
Analyze structure of text processing functions in competing scripting languages and implement several enhancements for
existing functions. For example:
Allow "TO" argument in index function, specifying upper range of the search.
Implement delete function for strings and arrays. For example adel(@array,$from,$to) and asubstr and aindex functions.
Improve control statements
Eliminate keyword 'given' and treat for(scalar) as a switch statement. Allow when operator in all regular
loops too. for($var){<br> when('b'){ ...;} # means if ($var eq 'b') { ... ; las + t} when(>'c'){...;} } # for[download]
[Questionable] Extend last to accept labels and implement "post loop switch" (See Donald Knuth
Structured Programming with go to Statements programming
with goto statements) my rc==0; for(...){ if (condition1) { $rc=1; last;} elsif(...){$rc=2; last} } if ($rc==0){...} elif($rc==1){...}
elif($rc==3){...}[download]
May be (not that elegant, but more compact the emulation above)
for ...{ when (...); when (...); }with switch{ default: 1: ... 2: ... }[download]
Highly desirable Make a semicolon optional at the end of the line, if there is a balance of brackets on the line and the statement
looks syntactically correct ("soft semicolon", the solution used in famous IBM PL/1 debugging compiler).
Even aside from that, some of us don't like really long lines of code. Having to scroll horizontally in GUI editors sucks, and
I do most of my coding in good-old 80-column terminal windows. So it's not uncommon for me to split up a long statement into multiple
shorter lines, since whitespace has no syntactic significance.
If CRLF becomes a potential statement terminator, then breaking a single statement across multiple lines not only becomes
a minefield of "will this be treated as one or multiple statements?", but the answer to that question may change depending on
where in the statement the line breaks are inserted!
If implemented, this change would make a mockery of any claims that Perl 7 will just be "Perl 5 with different defaults", as
well as any expectations that it could be used to run "clean" (by some definition) Perl 5 code without modification.
If implemented, this change would make a mockery of any claims that Perl 7 will just be "Perl 5 with different defaults", as
well as any expectations that it could be used to run "clean" (by some definition) Perl 5 code without modification.
Looks like a valid objection. I agree. With certain formatting style it is possible. But do you understand the strict as the default
will break a lot of old scripts too.
Per your critique, it probably should not be made as the default and implemented as pragma
similar to warnings and strict. You can call this pragma "softsemicolon"
What most people here do not understand is it can be implemented completely on lexical scanner level, not affecting syntax
analyzer.
If CRLF becomes a potential statement terminator, then breaking a single statement across multiple lines not only becomes a
minefield of "will this be treated as one or multiple statements?", but the answer to that question may change depending on
where in the statement the line breaks are inserted!
No. The classic solution of this problem was invented in FORTRAN in early 50 -- it is a backslash at the end of the line. Perl
can use #\ as this is pragma to lexical scanner, not the element of the language.
Usually long line in Perl is the initialization of array or hash and after the split they do not have balanced brackets and,
as such, are not affected and do not require #\ at the end.
Question to you: how many times you corrected missing semicolon in your Perl scripts the last week ? If you do not know, please
count this during the next week and tell us.
The classic solution of this problem was invented in FORTRAN in early 50 -- it is a backslash at the end of the line.
Fortran didn't have a release until 1957 so not early 50s. Fortran prior to F90 used a continuation character at the start
(column 6) of the subsequent line not the end of the previous line. The continuation character in Fortran has never been specified
as a backslash. Perhaps you meant some other language?
Yes, the first FORTRAN compiler delivered in April 1957. I was wrong, sorry about it. Still the idea of continuation symbol
belongs to FORTRAN, although the solution was different then I mentioned.
how many times you corrected missing semicolon in your Perl scripts the last week
After running the code - never. All the IDEs I use for all the languages I use flag missing semi-colons and other similar foibles
(like mis-matched brackets.
There are nasty languages that I use occasionally, and even some respectable ones, that need to quote new lines to extend a
statement across multiple lines. That is just nasty on so many levels. I very much agree with
dsheroh that long lines are anathema. Code becomes much harder
to read and understand when lines are long and statements are not chunked nicely.
Don't break what's not broken!
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
I do not understand your train of thought. In the first example end of the line occurred when all brackets are balanced, so it
will will be interpretered as print( "Hello World" ); if( 1 );[download]
So this is a syntactically incorrect example, as it should be. The second example will be interpreted as
OK. You are right. So it will now be interpreted as syntax error, but was valid previously, if we assume that somebody uses
this formatting for suffix conditionals.
That supports another critique of the same proposal -- it might break old Perl 5 scripts and should be implemented only as
optional pragma. Useful only for programmers who experience this problem.
Because even the fact that this error is universal and occurs to all programmers is disputed here.
Because people have a natural tendency to omit them at the end of the line. That's why. This is an interesting psychological phenomenon that does not depend on your level of mastery of the language and is not limited
to novices.
So instead, beginners would encounter the interesting psychological phenomenon where a physical end of line is sometimes interpreted
by the compiler as an end of statement, and other times not. One set of errors would be replaced by another.
The problem is real and the solution is real. Objections so far were pretty superficial and stems from insufficient level of
understanding of how the proposal works on the level of lexical scanner -- it essentially replaces the end of line with semicolon
if there a balance in brackets and syntax analyzer is not affected at all.
Can you please tell us how many times you corrected the missing semicolon error in your scripts during the lst week?
As I said, I don't forget to include semicolons. See for example
this video , it's 7 years old, but my habits haven't
changed much since then. map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
That's neither a natural tendency nor an interesting psychological phenomenon. You just made that up.
Semicolons at the end of a statement are as natural as a full stop "." at the end of a sentence, regardless of whether the
sentence is the last in a paragraph. The verification process whether a line "looks syntactically correct" takes longer than just
hitting the ";" key, and the chances of a wrong assessment of "correct" may lead to wrong behavior of the software.
Language-aware editors inform you about a missing semicolon by indenting the following line as a continuation of the statement
in the previous line, so it is hard to miss.
If, on the other hand, you want to omit semicolons, then the discussion should have informed you that you aren't going
to find followers.
Semicolons at the end of a statement are as natural as a full stop "." at the end of a sentence, regardless of whether the
sentence is the last in a paragraph.
I respectfully disagree, but your comment can probably explain fierce rejection of this proposal in this forum. IMHO this is a
wrong analogy as the level of precision required is different. If you analyze books in print you will find paragraphs in which
full stop is missing at the end. Most people do not experience difficulties learning to put a full stop at the end of the sentence
most of the time. Unfortunately this does work this way in programming languages with semicolon at the end of statement. Because
what is needed is not "most of the time" but "all the time"
My view supported by some circumstantial evidence and my own practice is the this is a persistent error that arise independently
of the level of qualification for most or all people, and semicolon at the end of the statement contradicts some psychological
mechanism programmers have.
Highly desirable Make a semicolon optional at the end of the line
Highly un desirable. If things to be made optional for increased readability, not this, but making braces optional for
singles statement blocks. But that won't happen either.
Highly Questionable Introduce pragma that specify max allowed length of single and double quoted string
Probably already possible with a CPAN module, but who would use it? This is more something for a linter or perltidy.
Highly desirable Compensate for some deficiencies of using curvy brackets as the block delimiters
Unlikely to happen and very un undesirable. The first option is easy } # LABEL (why introduce new syntax when
comments will suffice). The second is just plain illogical and uncommon in most other languages. It will confuse the hell out
of every programmer.
Make function slightly more flexible
a) no b) Await the new signatures c) Macro's are unlikely to happen. See the problems they faced in Raku. Would be fun
though
Long function names
Feel free to introduce a CPAN module that does all you propose. A new function for trimming has recently been introduced and
spun off a lot of debate. I think none of your proposed changes in this point is likely to gain momentum.
Allow to specify and use "hyperstrings"
I have no idea what is to be gained. Eager to learn though. Can you give better examples?
Put more attention of managing namespaces
I think a) is part of the proposed OO reworks for perl7 based on Cor
, b) is just plain silly, c) could be useful, but not based on letters but on sigils or interpunction, like in Raku</lI.
Analyze structure of text processing functions in competing scripting languages
Sounds like a great idea for a CPAN module, so all that require this functionality can use it
Improve control statements
Oooooh, enter the snake pit! There be dragons here, lots of nasty dragons. We have has given/when and several switch implementations
and suggestions, and so far there has been no single solution to this. We all want it, but we all have different expectations
for its feature sets and behavior. Wise people are still working on it so expect *something* at some time.
by likbez on Sep 10, 2020 at 16:57 UTC Reputation:
0
>The first option is easy } # LABEL (why introduce new syntax when comments will suffice).
Because }:LABEL actually forcefully closes all blocks in between, but the comment just informs you which opening bracket this
closing bracket corresponds to. and, as such, can placed on the wrong closing bracket, especially if the indentation is wrong
too. Worsening already bad situation.
That I can agree with. The rest of your proposals seem either unnecessary (because the facilities already exist in the language)
or potentially problematic or almost without utility to me. Sorry. That's not to say you shouldn't suggest them all to p5p for
further review of course - it's only the opinion of a humble monk after all.
by likbez on Sep 10, 2020 at 15:16 UTC Reputation:
2
> I have good news: it already does
What I mean is a numeric "local" (in Pascal style; can be redefined later in other blocks ) label in the context of the Knuth idea
of "continuations" outside the loop
That's quite some work you've invested here. I've looked at them from two perspectives:
How does it help when I'm writing code?
How does it help when I'm reading code (mostly written by someone else)?
In summary, your suggestions don't perform that great. These are rather nerdy ideas where I don't see which problem
they solve. There isn't much to be added to the comments of other monks, so I'll keep attention to two items:
I challenge the claim that closing more than one block with one brace allows search for missing closing bracket to be more
efficient . It just hides problems when you lost control over your block structure. Source code editors easily allow to jump
from opening to closing brace, or to highlight matching braces, but they are extremely unlikely to support such constructs.
I challenge the claim that extracting of substring is a very frequent operation . It is not in the Perl repositories
I've cloned. Many of them don't have a single occurrence of substring . Please support that claim with actual data.
by likbez on Sep 10, 2020 at 21:49 UTC Reputation:
-1
The frequency per line of code is rather low -- slightly above 4% (156/3678)
But in my text processing scripts this is the most
often used function. In comparison the function "index" is used only 53 times. Or three times less. It also exceeds the use of
regular expressions -- 108 in 3678.
Strokes for folks. I use regexen vastly more often than substr and I almost never use index. Maybe you grew up with some other
language (Visual Basic maybe?) and haven't actually learned to use Perl in an idiomatic way? Perl encourages a plethora of paradigms
for solving problems. The flip side is Perl doesn't do much to discourage hauling less appropriate "comfort coding practices"
from other languages. That is no reason to assume that all Perl users abuse Perl in the same way you do, or have as much trouble
typing statement terminators
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
Making Perl more like modern Python or JS is not improvement to language, you need another word for that, something like "trends"
or "fashion", or something like that. I see this list as a simplification of language (and in a bad way), not improvement. As
if some newby programmer would not want to improve himself, to get himself up to match the complexity of language, but blaim language
complexity and demand the language complexity to go down to his (low) level. "I don't want to count closing brackets, make something
that will close them all", "I don't want to watch for semicolons, let interpreter watch for end of sentence for me", "This complex
function is hard to understand and remember how to use it in a right way, give me bunch of simple functions that will do the same
as this one function, but they will be easy to remember".
Making tool more simple will not make it more powerful, or more efficient, but instead could make it less efficient, because
the tool will have to waste some of its power to compensate user's ineptitude. Interpreter would waste CPU and memory to comprehend
sentence ending, this "new" closing brackets and extra function calls, and what's gain here? I see only one - that newby programmer
could write code with less mind efforts. So it's not improvement of language to do more with less, but instead a change that will
cause tool do same with more. Is it improvement? I don't think so.
As if some newby programmer would not want to improve himself, to get himself up to match the complexity of language, but blaim
language complexity and demand the language complexity to go down to his (low) level.
The programming language should be adapted to actual use by programmers, not to some illusions of actual use under the disguise
of "experts do not commit those errors." If the errors committed by programmers in the particular language are chronic like is
the case for semicolons and missing closing brace something needs to be done about them, IMHO.
The same is true with the problem of "overexposure" of global variables. Most programmers at some point suffer from this type
of bugs. That's why "my" was pushed into the language. But IMHO it does not go far enough as it does not distinguish between reading
and modifying a variable. And "sunglasses" approach to visibility of global variable might be beneficial.
BTW the problem of missing parentheses affects all languages which use this "{" and "}" as block delimiters and the only implementation
which solved this complex problem satisfactory were closing labels on closing block delimiter in PL/1 ("}" in Perl; "begin/end"
pair in PL/1). Like with "missing semicolon" this is the problem from which programmer suffer independently of the level of experience
with the language.
So IMHO any measures that compensate for "dangling '}' " problem and provide better coordination between opening and closing
delimiters in the nested blocks would be beneficial.
Again the problem of missing closing brace is a chronic one. As somebody mentioned here the editor that has "match brace" can
be used to track it but that does not solve the problem itself, rather it provides a rather inefficient (for complex script) way
to troubleshoot one. Which arise especially often if you modify the script. I experienced even a case when syntactically { } braces
structure were correct but semantically wrong and that was detected only after the program was moved to production. Closing label
on bracket would prevent it.
I never had problems with omitting semicolons; maybe it's because of the extensive Pascal training.
If you write short subroutines, as you should, you don't suffer from misplaced closing curly braces. I had problems with them,
especially when doing large edits on code not written by me, but the editor always saved me.
More or less agree WRT mismatched closing curlies. I see it pretty much entirely as an editor issue.
(I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping? At least I recall that ("Your editor will
keep it straight") being seriously offered as a valid dismissal of the criticism against S-W-A-G . . .)
I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping?
No the argument is different, but using indentation to determine block nesting does allow multiple close of blocks, as a side
effect. Python invented strange mixed solution when there is an opening bracket (usually ":") and there is no closing bracket
-- instead indent is used as the closing bracket.
The problem is that it breaks too many other things, so here the question "whether it worth it" would be more appropriate,
then in case of soft semicolons.
[Highly desirable] Make a semicolon optional at the end of the line, if there is a balance of brackets on the line and the
statement looks syntactically correct ("soft semicolon", the solution used in famous IBM PL/1 debugging compiler).
I feel a bit ashamed to admit that I had programmed in PL/I for several years. The reason why PL/I was so relaxed w.r.t. syntax
is simple: You put your box full of punched cards to the operators' desk and you get the compiler's result the next day. If the
job had failed just because of a missing semicolon, you'd loose one full day. Nowadays there is absolutely no need for such stuff.
BTW, the really fatal errors in a PL/I program resulted in a compiler warning of the kind "conversion done by subroutine
call". This happend e.g. when assigning a pointer to a character array.
I wouldn't like to see any of the fancy features of PL/I in Perl. Consult your fortune database:
Speaking as someone who has delved into the intricacies of PL/I, I am sure that only Real Men could have written such a
machine-hogging, cycle-grabbing, all-encompassing monster. Allocate an array and free the middle third? Sure! Why not? Multiply
a character string times a bit string and assign the result to a float decimal? Go ahead! Free a controlled variable procedure
parameter and reallocate it before passing it back? Overlay three different types of variable on the same memory location?
Anything you say! Write a recursive macro? Well, no, but Real Men use rescan. How could a language so obviously designed and
written by Real Men not be intended for Real Man use?
PL/1 still exists, although as a niche language practically limited to mainframes. Along with being a base for C it also was probably
the first programming language that introduced exceptions as mainstream language feature. Also IMHO it is the origin of functions
substr, index and translate as we know them. Compilers from PL/1 were real masterpieces of software engineering and probably in
many aspects remain unsurpassed.
What is common between PL/1 and Perl is the amount of unjustified hate from CS departments and users of other languages toward
them.
What I think is common about both is that, while being very unorthodox, they are expressive and useful. Fun to program with.
As Larry Wall said: "Perl is, in intent, a cleaned up and summarized version of that wonderful semi-natural language known as
'Unix'."
Unorthodox nature and solutions in Perl which stems from Unix shell is probably what makes people coming from Python/Java/JavaScript
background hate it.
Currently, the big push is to turn on warnings and strict by default; I like the initially slow approach. I don't have a strong
opinion about any of your suggestions (good or bad) because I see none of them as particularly disruptive. Heck, I'd be happy
to to have say and state available without turning them on explicitly. Ultimately, I just look forward to moving
towards a more aggressive model of having new features on by default.
Thomas Claburn, writing for The Register: Developers really dislike Perl, and projects
associated with Microsoft, at least among those who volunteer their views through Stack
Overflow. The community coding site offers programmers a way to document their technical
affinities on their developer story profile pages. Included therein is an input box for tech
they'd prefer to avoid. For developers who have chosen to provide testaments of loathing,
Perl tops the list of
disliked programming languages, followed by Delphi and VBA . The yardstick here consists of
the ratio of "likes" and "dislikes" listed in developer story profiles; to merit chart
position, the topic or tag in question had to show up in at least 2,000 stories. Further down
the down the list of unloved programming language comes PHP, Objective-C, CoffeeScript, and
Ruby. In a blog post seen by The Register ahead of its publication today, Stack Overflow data
scientist David Robinson said usually there's a relationship between how fast a particular tag
is growing and how often it's disliked. "Almost everything disliked by more than 3 per cent of
Stories mentioning it is shrinking in Stack Overflow traffic (except for the quite polarizing
VBA, which is steady or slightly growing)," said Robinson. "And the least-disliked tags -- R,
Rust, TypeScript and Kotlin -- are all among the fast-growing tags (TypeScript and Kotlin
growing so quickly they had to be truncated in the plot).
And once you want to move beyond some simple automation scripts, you find that Python
doesn't have the performance to handle anything more taxing. Re:Perl Is Hated
Because It's Difficult (
Score: 4 , Interesting) by Anonymous Coward on Wednesday November 01, 2017 @11:05AM (
#55469365 )
Perl doesn't encourage or discourage you to write good or bad code. What it does very well
is work with the philosophy of DWIM (Do What I Mean). Importantly, it doesn't throw a giant
pile of (effectively) RFCs with an accompanying Nazi yelling, "YOU VILL VRITE CODE DIS VAY." at
you the way Python does. I've seen great Perl code and poor Perl code. I've seen great Python
code and poor Python code. A shitty developer writes shitty code and doesn't read
documentation. A great developer can take a language like Perl and create a great, readable
code. Real source (
Score: 4 , Informative) by Shompol ( 1690084 ) on Wednesday November 01, 2017 @10:12AM
( #55469013 ) The
original study is
here [stackoverflow.blog] I found the "polarization of technology" diagram at the bottom
even more interesting. Experience-based
opinions (
Score: 5 , Insightful) by Sarten-X ( 1102295 ) on Wednesday November 01, 2017
@10:16AM ( #55469047 )
Homepage
Having worked in Perl (and many other languages) for about 15 years now, I'm curious how
many of those polled actually use Perl regularly.
Whenever I have to introduce someone to my Perl scripts, their first reaction is usually the
typical horror, which fades in a few days after they start using it. Yes, there are comments.
Yes, there is decent design. No, the regular expressions are not worse than any other
implementation. No, the "clever" one-liner you copied off of a PerlMonks golf challenge will
not pass review.
Sure, there are a few weird warts on the language ("bless" being the most obvious example),
but it's no worse than any other, and significantly better than some of today's much more
popular languages. Mostly, I find that Perl just has a bad reputation because it allows you to
write ugly code, just like C allows you to corrupt data and Java allows you to consume obscene
amounts of memory. The language choice does not excuse being a bad programmer. At
least Perl stable. (
Score: 5 , Insightful) by Qbertino ( 265505 ) < [email protected] > on Wednesday November 01,
2017 @10:38AM ( #55469163 )
Perl is a wacky language and only bareable if you can handle old school unix stunts, no
doubt. It gave birth to PHP, which speaks volumes. I remember reading an OReilly introduction
to Perl and laughing at the wackyness. I've done the same with PHP, but I've always respected
both. Sort of.
Unlike newfangled fads and desasters like Ruby, Perl is a language that remains usable. Books
on Perl from 18 years ago are still valid today, just like with awk, TCL and Emacs Lisp.
Complain all you want about the awkwardness of old-school languages - they still work and
many of them run on just about anything that can be powered by electricity. These days I'm
still a little reluctant to say which side Javascript will come up on now that Node has it's
very own version hodgepodge gumming up the works. Two types of
languages . . . (
Score: 5 , Insightful) by walterbyrd ( 182728 ) on Wednesday November 01, 2017
@10:42AM ( #55469203 )
Personally I prefer Perl over similar scripting languages.
I write in KSH, CSH, Python and Perl regularly... Of the three, Perl is my hands down
favorite for a scripting language.
If you are writing applications in Perl though, it sucks. The implementation of objects is
obtuse, it isn't geared for User Interfaces (Perl/TK anyone?) and performance is really
horrid.
But... I cut my programming teeth on C (K&R, not ANSI) so I'm one of those old grey
headed guys who go "tisk tisk" at all those new fangled, it's better because it's new things
you young ones think are great.
Funny, I quite enjoyed writing in Perl 5 and the feeling was empowerment, and the community
was excellent. At the time Python was quite immature. Python has grown but Perl 5 is still
quite useful.
There is also quite a difference between legacy code and code written today using modern
extensions, though it seems people enjoy trashing things, instead of admitting they did not
actually learn it. Perl is just
fine (
Score: 2 , Insightful) by Anonymous Coward on Wednesday November 01, 2017 @11:43AM (
#55469621 )
I love perl. What I don't love is the deliberately obfuscated perl written by someone trying
to be clever and/or indispensible by writing code only they can (quickly) understand. A quick
down-and-dirty perl script is one thing, using it in reusable scripts is just immature and
pointless. Especially those who refuse to document their code.
My biggest problem I find with Perl is that there were SO many ways to express a similar
operations, conditionals, etc. While this may be nice for single developer projects, it is
utter hell if someone has to read that code. This has happened because of Perl's long life and
its iterations to add more and more contemporary programming concepts. This has made it
possible (and thus it will happen) to make Perl code a spaghetti mess of syntaxes. This makes
perl code difficult to read much less grok.
I'm not saying Perl is the only offender of this. PHP has the same issue with its older
functional programming syntax style and its OOP syntax. But PHP has kept it mainly to two
styles. Perl has way too many styles so people get lots in syntax and find it hard fallow the
code.
ShareRe:
It is surprising to me that enough developers have used Perl for it to be the most hated
language. I would have guessed JavaScript, or maybe VB (#4 & #2 most hated). Re: My
usual experience with Perl goes like this: We can't process data this year can you help us? Oh,
this is a 20-year-old Perl script. Let the biopsy begin. Re:Is that
surprising? (
Score: 5 , Informative) by Austerity Empowers ( 669817 ) on Wednesday
November 01, 2017 @11:05AM ( #55469361 )
My experience with the Perl hate is it's usually from younger people (by which I mean anyone
under about 40). It violates everything some may have been taught as part of their software
engineering program: it's difficult to read, maintain, and support.
But, it exists for a reason and it's ridiculously good at that purpose. If I want to process
lots of text, I do not use Python, I whip out perl. And usually it's fine, the little bits of
perl here and there that glue the world together aren't usually that egregious to maintain
(particularly in context of the overall mechanism it's being used to glue together,
usually).
If I'm going to write serious code, code that may formulate the basis for my corporations
revenue model or may seriously improve our cost structure, I use a serious language (C/C++,
usually) and spend significant amounts of time architecting it properly. The problem is that
more and more people are using scripting languages for this purpose, and it's becoming socially
acceptable to do so. The slippery slope being loved by children and idiots alike, one might say
"I know Perl, let's use that!" and countless innocents are harmed. Re:Is that
surprising? (
Score: 5 , Informative) by networkBoy ( 774728 ) on Wednesday November 01, 2017
@11:57AM ( #55469737 )
Journal
I *love* perl.
It is C for lazy programmers.
I tend to use it for four distinct problem domains:
* one-offs for data processing (file to file, file to stream, stream to file, stream to
stream). When I'm done I don't need it any more
* glue code for complex build processes (think a preprocessor and puppetmaster for
G/CMAKE)
* cgi scripts on websites. Taint is an amazing tool for dealing with untrusted user input.
The heavy lifting may be done by a back end binary, but the perl script is what lives in the
/cgi-bin dir.
* test applications. I do QA and Perl is a godsend for writing fuzzers and mutators.
Since it's loosely typed and dynamically allocates/frees memory in a quite sane manner it is
able to deal with the wacky data you want fuzzers to be working with.
Parent ShareRe:Is that
surprising? (
Score: 5 , Insightful) by al0ha (
1262684 ) on Wednesday November 01, 2017 @01:28PM ( #55470385 )
Journal Yep -
Perl is C for lazy programmers - well maybe not lazy, but programmers that don't want to have
to deal with allocating and freeing memory, which is the bane of C and where many of the
security problems arise. The other beautiful thing about Perl is no matter how you write your
code, the interpreter compiles it into the most efficient form, just like C.
I think hate for Perl stems from the scripters who try to show off their Perl skills,
writing the most concise code which is exasperatingly confusing and serves absolutely no
purpose. Whether you write verbose code which takes many lines to do the same thing as concise
and hard to understand code, at run time they perform exactly the same.
Perl coders have only themselves to blame for the hate; thousands of lines of stupid
hard to read code is a nightmare for the person that comes along months or years later and has
to work on your code. Stop it damn it, stop it!!!!! Re:Is that
surprising? (
Score: 5 , Insightful) by fahrbot-bot ( 874524 ) on Wednesday November 01, 2017
@12:28PM ( #55469959
)
My experience with the Perl hate is it's usually from younger people (by which I mean
anyone under about 40). It violates everything some may have been taught as part of their
software engineering program: it's difficult to read, maintain, and support.
The quality of the program structure and the ability to read, maintain and support it
are due to the programmer, not Perl. People can write programs well/poorly in any language.
Like some others here, I *love* Perl and always endeavor to write clear, well-organized code -
like I do in any other programming language - so others can make sense of it -- you know, in
case I get hit by a bus tomorrow... It's call being professional.
Hate the programmer, not the programming language. Re:Is that
surprising? (
Score: 5 , Funny) by Anonymous Coward on Wednesday November 01, 2017 @10:16AM (
#55469039
)
Many of us who know perl (and think you're a hypersensitive snowflake of a developer)
learned C before we learned Perl.
We're immune to coding horrors. Re:Ruby... (
Score: 4 , Interesting) by Anonymous Coward on Wednesday November 01, 2017 @11:28AM (
#55469503
)
The problem is because people use the wrong tools for things. This is not a definitive
list:
Perl is ONLY useful today as a server-sided processing script. If you are using Perl
on your front end, you will get dependency hell as your server updates things arbitrarily. Perl
breaks super-frequently due to the move from manual updates to automatic updates of third party
libraries/ports. Thus if you don't update Perl and everything that uses Perl at the same time,
mass-breakage. Thus "Don't update Perl you moron"
To that end PHP is on the other side of that coin. PHP is only useful for websites and
nothing else. If you run PHP as a backend script it will typically time out, or run out of
memory, because it's literately not designed to live very long. Unfortunately the monkeys that
make Wordpress themes, plugins, and "frameworks" for PHP don't understand this. Symfony is
popular, Symfony also is a huge fucking pain in the ass. Doctrine, gobbles up memory and gets
exponentially slower the longer the process runs.
Thus "Don't update Wordpress" mantra, because good lord there are a lot of shitty
plugins and themes. PHP's only saving grace is that they don't break shit to cause dependency
hell, they just break API's arbitrarily, thus rendering old PHP code broken until you update
it, or abandon it.
Ruby is a poor all-purpose tool. In order to use it with the web, you basically need
to have the equivalent of php-fpm for Ruby running, and if your server is exhausted, just like
php, it just rolls over and dies. Ruby developers are just like Python developers (next) in
that they don't fundamentally understand what they are doing , and leave (crashed) processes
running perpetually. At least PHP gets a force-kill after a while. Ruby Gems create another
dependency hell. In fact good luck getting Ruby on a CentOS installation, it will be obsolete
and broken.
Python, has all the worst of Perl's dependency hell with Ruby's clueless developers.
Python simply doesn't exist on the web, but good lord so many "build tools" love to use it, and
when it gets depreciated, whole projects that aren't even developed in Python, stop
working.
Which leads me to NodeJS/NodeWebkit. Hey it's Javascript, everyone loves javascript.
If you're not competent enough to write Javascript, turn in your developers license. Despite
that, just like Perl, Ruby and Python, setting up a build environment is an annoying pain in
the ass. Stick to the web browser and don't bother with it.
So that covers all the interpreted languages that you will typically run into on the
web.
Java is another language that sometimes pops up on servers, but it's more common in
finance and math projects, which are usually secretive. Java, just like everything mentioned,
breaks shit with every update.
C is the only languages that haven't adopted the "break shit with every update"
because C can not be "improved" on any level. Most of what has been added to the C API deals
with threading and string handling. At the very basics, anything written in C can compile on
everything as long as the platform has the same functions built into the runtime. Which isn't
true when cross-compiling between Linux and Windows. Windows doesn't "main()" while Linux has a
bunch of posix functions that don't exist on Windows.
Ultimately the reasons all these languages suck comes right back to dependency hell. A
language that has a complete API, requiring no libraries, simply doesn't exist, and isn't
future proof anyways.
People hate a lot of these languages because they don't adhere to certain programming
habits they have, like object oriented "overide-bullshit", abuse of global variables, or
strongly typed languages. Thus what should work in X language, doesn't work in Y language,
because that language simply does it differently.
Like weakly typed languages are probably supreme, at the expense of runtime
performance, because it results in less errors. That said, =, == and === are different. In a
strong type language, you can't fuck that up. In a weak type language, you can make mistakes
like if(moose=squirrel){blowshitup();} and the script will assume you want to make moose the
value of squirrel, AND run blowshitup() regardless of the result. Now if you meant ===, no type
conversion. Re:Ruby... (
Score: 5 , Interesting) by Darinbob ( 1142669 ) on Wednesday November 01, 2017
@02:20PM ( #55470827
)
You can write Forth code that is readable. Once you've got the reverse notation
figured out it is very simple to deal with. The real problem with Perl is that the same
variable name can mean many different things depending upon the prefix character and the
context in which it is used. This can lead to a lot of subtle bugs, leads to a steep learning
curve, and even a few months of vacation from the language can result in being unable to read
one's own code.
On the other hand, Perl was never designed to be a typical computer language. I was
berated by Larry Wall over this, he told me "you computer scientists are all alike". His goal
was to get a flexible and powerful scripting language that can be used to get the job done. And
it does just that - people use Perl because it can get stuff done. When it was new on Unix it
was the only thing that could really replace that nasty mix of sh+awk+ed scripting that was
common, instead being able to do all of that in a single script, and that led to its extremely
fast rise in popularity in the early 90s. Yes, it's an ugly syntax but it's strong underneath,
like the Lou Ferrigno of programming languages. Re:Ruby... (
Score: 2 ) by Shompol ( 1690084
) on Wednesday November 01, 2017 @10:27AM ( #55469105 )
Ruby is ahead of Perl, in the "medium-disliked"
[stackoverflow.blog] category. I find it amusing that Ruby was conceived as a Python
replacement, yet fell hopelessly behind in the popularity contest.
Perl bashing is popular sport among a particularly vocal crowd.
Perl is extremely flexible. Perl holds up TIMTOWTDI ( There Is More Than One Way To
Do It ) as a virtue. Larry Wall's Twitter handle is @TimToady, for goodness sake!
That flexibility makes it extremely powerful. It also makes it extremely easy to write code
that nobody else can understand. (Hence, Tim Toady
Bicarbonate.)
You can pack a lot of punch in a one-liner in Perl:
That one-liner takes a block of raw data (in $data ), expands it to an array of
values, and then f
Continue Reading Steve J
, Software Engineer
Answered November 4, 2017 · Author has 486 answers and 133.6K answer views Originally
Answered: Why does Perl so hated and not commanly used? And why should I learn it?
You should learn things that make your life easier or better. I am not an excellent Perl
user, but it is usually my go-to scripting language for important projects. The syntax is
difficult, and it's very easy to forget how to use it when you take significant time away from
it.
That being said, I love how regular expressions work in Perl. I can use sed like commands
$myvar =~ s/old/new/g for string replacement when processing or filtering strings. It's much
nicer than other languages imo.
I also like Perls foreach loops and its data structures.
I tried writing a program of moderate length in Pytho
It is still used, but its usage is declining. People use Python today in situations when
they would have used Perl ten years ago.
The problem is that Perl is extremely pragmatic. It is designed to be "a language to get
your job done", and it does that well; however, that led to rejection by language formalists.
However, Perl is very well designed, only it is well designed for professionals who grab in the
dark expecting that at this place there should be a button to do the desired functionality, and
indeed, there will be the button. It is much safer to use than for example C (the sharp knife
th
Continue Reading Michael
Yousrie , A programmer, A Problem Solver
Answered November 4, 2017 · Author has 82 answers and 169.1K answer views Originally
Answered: Why does Perl so hated and not commanly used? And why should I learn it?
Allow me to state my opinion though; You can't have people agreeing on everything because
that's just people. You can't expect every single person to agree on a certain thing, it's
impossible. People argue over everything and anything, that's just people.
You will find people out there that are Perl fanatics, people that praise the language! You
will also find people that don't like Perl at all and always give negative feedback about
it.
To be honest, I never gave a damn about people's opinions, I a
The truth is, that by any metric, more Perl is being done today than during the dot com
boom. It's just a somewhat smaller piece of a much bigger pie. In fact, I've heard from some
hiring managers that there's actually a shortage of Perl programmers, and not just for
maintaining projects, but for new greenfield deploys.
1.2K views View 25 Upvoters Richard
Conto , Programmer in multiple languages. Debugger in even more
Answered December 18, 2017 · Author has 7K answers and 5.4M answer views
Perl bashing is largely hear-say. People hear something and they say it. It doesn't require
a great deal of thought.
As for Perl not commonly being used - that's BS. It may not be as common as the usual gang
of languages, but there's an enormous amount of work done in Perl.
As for you you should learn Perl, it's for the same reason you would learn any other
language - it helps you solve a particular problem better than another language available. And
yes, that can be a very subjective decision to make.
Because even the best features of perl produce easily write only language. I have written
one liner XML parser using perl regex. The program has worked perfectly more than 10 years but
I have been afraid of change or new feature requiment which I cann't fullfil without writing
totally new program bacause I cann't understand my old one.
649 views View 4 Upvoters
Reed
White , former Engineer at Hewlett-Packard (1978-2000)
Answered November 7, 2017 · Author has 3K answers and 695.9K answer views
Yes, Perl takes verbal abuse; but in truth, it is an extremely powerful, reliable language.
In my opinion, one of its outstanding characteristics is that you don't need much knowledge
before you can write useful programs. As time goes by, you gradually learn the real power of
the language.
However, because Perl-bashing is popular, you might better put your efforts into learning
Python, which is also quite capable.
What esteemed monks
think about changes necessary/desirable in Perl 7 outside of OO staff. I compiled some my
suggestions and will appreciate the feedback:
[Highly desirable] Make a semicolon optional at the end of the line, if there is a
balance of brackets on the line and the statement looks syntactically correct ("soft
semicolon", the solution used in famous IBM PL/1 debugging compiler).
[Highly Questionable] Introduce pragma that specify max allowed length of single and
double quoted string (not not any other type of literals). That might simplify catching
missing quote (which is not a big problem with any decent Perl aware editor anyway)
[Highly desirable] Compensate for some deficiencies of using curvy brackets as the
block delimiters:
Treat "}:LABEL" as the bracket closing "LABEL:{" and all
intermediate blocks (This idea was also first implemented in PL/1)
Treat " }.. " symbol as closing all opened brackets up to the
subroutine/BEGIN block level and }... including this level (closing up to the
nesting level zero. ). Along with conserving vertical space, this allows search for
missing closing bracket to be more efficient.
Make function slightly more flexible:
Introduce pragma that allows to define synonyms to built-in functions, for example ss
for for substr and ix for index
Allow default read access for global variables with subroutines, but write mode only
with own declaration via special pragma, for example use
sunglasses;
Introduce inline functions which will be expanded like macros at compile time:
sub subindex inline{ $_[0]=substr($_[0],index($_[0],$_[1],$_2])) }[download]
As extracting of substring is a very frequent operation and use of such long name is
counterproductive; it also contradicts the Perl goal of being concise and expressive .
allow to extract substring via : or '..' notations like $line [$from:$to]
(label can't be put inside square brackets in any case)
Explicitly distinguish between translation table and regular expressions by
introducing tt-strings
Implement tail and head functions as synonyms to substr
($line,0,$len) and substr($line,-$len)
With the ability to specify string, regex of translation table(tr style) instead of
number as the third argument tail($line,'#') tail($line,/\s+#\w+$/)
tail($line,tt/a-zA-z]/[download]
Implement similar to head and tail function called, for example, trim: trim(string,tt/leftcharacter_set/, tt/right_character_set/);[download]
which deleted all characters from the first character set at the left and all characters
from the second character set from the right,
trim(string,,/right_character_set)
strips trailing characters only.
Allow to specify and use "hyperstrings" -- strings with characters occupying any power
of 2 bytes (2,4,8, ...). Unicode is just a special case of hyperstring
$hyper_example1= h4/aaaa/bbbb/cccc/;
$hyper_example2= h2[aa][bb][cc];
$pos=index($hyper_example,h4/bbbb/cccc/)
Put more attention of managing namespaces.
Allow default read access for global variables, but write mode only with own
declaration via special pragma, for example use sunglasses.
Allow to specify set of characters, for which variable acquires my attribute
automatically, as well as the default minimum length of non my variables via pragma my
(for example, variables with the length of less then three character should always be
my)
Allow to specify set of character starting from which variable is considered to be
own, for example [A-Z] via pragma own.
Analyze structure of text processing functions in competing scripting languages and
implement several enhancements for existing functions. For example:
Allow "TO" argument in index function, specifying upper range of the search.
Implement delete function for strings and arrays. For example
adel(@array,$from,$to) and asubstr and aindex functions.[download]
Improve control statements
Eliminate keyword 'given' and treat for(scalar) as a switch statement. Allow
when operator in all regular loops too. for($var){<br> when('b'){
...;} # means if ($var eq 'b') { ... ; las + t} when(>'c'){...;} } # for[download]
[Questionable] Extend last to accept labels and implement "post loop switch" (See
Donald Knuth Structured
Programming with go to Statements programming with goto statements) my rc==0;
for(...){ if (condition1) { $rc=1; last;} elsif(...){$rc=2; last} } if ($rc==0){...}
elif($rc==1){...} elif($rc==3){...}[download]
May be (not that elegant, but more compact the emulation above)
for ...{ when
(...); when (...); }with switch{ default: 1: ... 2: ... }[download]
Highly desirable Make a semicolon optional at the end of the line, if there is a balance of
brackets on the line and the statement looks syntactically correct ("soft semicolon", the
solution used in famous IBM PL/1 debugging compiler).
If CRLF becomes a potential statement terminator, then breaking a single
statement across multiple lines not only becomes a minefield of "will this be treated as
one or multiple statements?", but the answer to that question may change depending on where
in the statement the line breaks are inserted!
If implemented, this change would make a mockery of any claims that Perl 7 will just be
"Perl 5 with different defaults", as well as any expectations that it could be used to run
"clean" (by some definition) Perl 5 code without modification.
If implemented, this change would make a mockery of any claims that Perl 7 will just be
"Perl 5 with different defaults", as well as any expectations that it could be used to
run "clean" (by some definition) Perl 5 code without modification.
Looks like a valid objection. I agree. With certain formatting style it is
possible. But do you understand the strict as the default will break a lot of old scripts
too. Per your critique, it probably should not be made as the default and implemented as
pragma similar to warnings and strict. You can call this pragma "softsemicolon"
What most people here do not understand is it can be implemented completely on lexical
scanner level, not affecting syntax analyser.
If CRLF becomes a potential statement terminator, then breaking a single statement across
multiple lines not only becomes a minefield of "will this be treated as one or multiple
statements?", but the answer to that question may change depending on where in the
statement the line breaks are inserted!
No. The classic solution of this problem was invented in FORTRAN in early 50
-- it is a backslash at the end of the line. Perl can use #\ as this is pragma to lexical
scanner, not the element of the language.
Usually long line in Perl is the initialization of array or hash and after the split
they do not have balanced brackets and, as such, are not affected and do not require #\ at
the end.
Question to you: how many times you corrected missing semicolon in your Perl scripts the
last week ? If you do not know, please count this during the next week and tell us.
how many times you corrected missing semicolon in your Perl scripts the last week
After running the code - never. All the IDEs I use for all the languages I use flag
missing semi-colons and other similar foibles (like mis-matched brackets.
There are nasty languages that I use occasionally, and even some respectable ones, that
need to quote new lines to extend a statement across multiple lines. That is just nasty on
so many levels. I very much agree with dsheroh that long lines are anathema. Code
becomes much harder to read and understand when lines are long and statements are not
chunked nicely.
Don't break what's not broken!
Optimising for fewest key strokes only makes sense
transmitting to Pluto or beyond
The classic solution of this problem was invented in FORTRAN in early 50 -- it is a
backslash at the end of the line.
Fortran didn't have a release until 1957 so not early 50s. Fortran prior to F90 used a
continuation character at the start (column 6) of the subsequent line not the end of the
previous line. The continuation character in Fortran has never been specified as a
backslash. Perhaps you meant some other language?
I do not understand your train of thought. In the first example end of the
line occurred when all brackets are balanced, so it will will be interpretered as
print( "Hello World" ); if( 1 );[download]
So this is a syntactically incorrect example, as it should be. The second example will
be interpreted as
That support another critique of the same proposal -- it might break old Perl 5 scripts
and should be implemented only as optional pragma. Usuful only for programmers who
experience this problem.
Because even the fact that this error is universal and occurs to all programmers is
disputed here.
That's neither a natural tendency nor an interesting psychological phenomenon. You just
made that up.
Semicolons at the end of a statement are as natural as a full stop "." at the end of a
sentence, regardless of whether the sentence is the last in a paragraph. The verification
process whether a line "looks syntactically correct" takes longer than just hitting the ";"
key, and the chances of a wrong assessment of "correct" may lead to wrong behavior of the
software.
Language-aware editors inform you about a missing semicolon by indenting the following
line as a continuation of the statement in the previous line, so it is hard to miss.
If, on the other hand, you want to omit semicolons, then the discussion should
have informed you that you aren't going to find followers.
Semicolons at the end of a statement are as natural as a full stop "." at the end of a
sentence, regardless of whether the sentence is the last in a paragraph.
I respectfully disagree, but your comment can probably explain fierce
rejection of this proposal in this forum. IMHO this is a wrong analogy as the level of
precision requred is different. If you analyse books in print you will find paragraphs in
which full stop is missing at the end. Most people do not experience difficulties learning
to put a full stop at the end of the sentence most of the time. Unfortunately this does
work this way in programming languages with semicolon at the end of statement. Because what
is needed is not "most of the time" but "all the time"
My view supported by some circumstantial evidence and my own practice is the this is a
persistent error that arise independently of the level of qualification for most or all
people, and semicolon at the end of the statement contradicts some psychological mechanism
programmers have.
Highly desirable Make a semicolon optional at the end of the line
Highly un desirable. If things to be made optional for increased readability, not
this, but making braces optional for singles statement blocks. But that won't happen
either.
Highly Questionable Introduce pragma that specify max allowed length of single and
double quoted string
Probably already possible with a CPAN module, but who would use it? This is more something
for a linter or perltidy.
Highly desirable Compensate for some deficiencies of using curvy brackets as the
block delimiters
Unlikely to happen and very un undesirable. The first option is easy } #
LABEL (why introduce new syntax when comments will suffice). The second is just plain
illogical and uncommon in most other languages. It will confuse the hell out of every
programmer.
Make function slightly more flexible
a) no b) Await the new signatures c) Macro's are unlikely to happen. See the
problems they faced in Raku. Would be fun though
Long function names
Feel free to introduce a CPAN module that does all you propose. A new function for trimming
has recently been introduced and spun off a lot of debate. I think none of your proposed
changes in this point is likely to gain momentum.
Allow to specify and use "hyperstrings"
I have no idea what is to be gained. Eager to learn though. Can you give better
examples?
Put more attention of managing namespaces
I think a) is part of the proposed OO reworks for perl7 based on Cor , b) is just plain silly, c) could be useful, but
not based on letters but on sigils or interpunction, like in Raku</lI.
Analyze structure of text processing functions in competing scripting
languages
Sounds like a great idea for a CPAN module, so all that require this functionality can use
it
Improve control statements
Oooooh, enter the snake pit! There be dragons here, lots of nasty dragons. We have has
given/when and several switch implementations and suggestions, and so far there has been no
single solution to this. We all want it, but we all have different expectations for its
feature sets and behavior. Wise people are still working on it so expect *something* at
some time.
by you !!! on Sep 10,
2020 at 16:57 UTC Reputation: -2
Because }:LABEL actually forcefully closes all blocks in between, but the comment just
informs you which opening bracket this closing bracket corresponds to. and, as such, can
placed on the wrong closing bracket, especially if the indentation is wrong too. Worsening
already bad situation.
That I can agree with. The rest of your proposals seem either unnecessary (because the
facilities already exist in the language) or potentially problematic or almost without
utility to me. Sorry. That's not to say you shouldn't suggest them all to p5p for further
review of course - it's only the opinion of a humble monk after all.
by you !!! on Sep 10,
2020 at 15:16 UTC Reputation: 1
What I mean is a numeric "local" (in Pascal style; can be redefined later in other
blocks ) label in context of the Knuth idea of "continuations" outside the loop
That's quite some work you've invested here. I've looked at them from two
perspectives:
How does it help when I'm writing code?
How does it help when I'm reading code (mostly written by someone else)?
In summary, your suggestions don't perform that great. These are rather nerdy ideas
where I don't see which problem they solve. There isn't much to be added to the comments of
other monks, so I'll keep attention to two items:
I challenge the claim that closing more than one block with one brace allows search for
missing closing bracket to be more efficient . It just hides problems when you lost
control over your block structure. Source code editors easily allow to jump from opening to
closing brace, or to highlight matching braces, but they are extremely unlikely to support
such constructs.
I challenge the claim that extracting of substring is a very frequent operation .
It is not in the Perl repositories I've cloned. Many of them don't have a single occurrence
of substring . Please support that claim with actual data.
Making Perl more like modern Python or JS is not improvement to language, you need another
word for that, something like "trends" or "fashion", or something like that. I see this list
as a simplification of language (and in a bad way), not improvement. As if some newby
programmer would not want to improve himself, to get himself up to match the complexity of
language, but blaim language complexity and demand the language complexity to go down to his
(low) level. "I don't want to count closing brackets, make something that will close them
all", "I don't want to watch for semicolons, let interpreter watch for end of sentence for
me", "This complex function is hard to understand and remember how to use it in a right way,
give me bunch of simple functions that will do the same as this one function, but they will
be easy to remember".
Making tool more simple will not make it more powerful, or more efficient, but instead
could make it less efficient, because the tool will have to waste some of its power to
compensate user's ineptitude. Interpreter would waste CPU and memory to comprehend sentence
ending, this "new" closing brackets and extra function calls, and what's gain here? I see
only one - that newby programmer could write code with less mind efforts. So it's not
improvement of language to do more with less, but instead a change that will cause tool do
same with more. Is it improvement? I don't think so.
by you !!! on Sep 10,
2020 at 16:52 UTC Reputation: -4
As if some newby programmer would not want to improve himself, to get himself up to match
the complexity of language, but blaim language complexity and demand the language
complexity to go down to his (low) level.
The programming language should be adapted to actual use by programmers, not to some
illusions of actual use under the disguise of "experts do not commit those errors." If the
errors committed by programmers in the particular language are chronic like is the case for
semicolons and missing closing brace something needs to be done about them, IMHO.
The same is true with the problem of "overexposure" of global variables. Most
programmers at some point suffer from this type of bugs. That's why "my" was pushed into
the language.
BTW the problem of missing parentheses affects all languages which use this "{" and "}"
as block delimiters and the only implementation which solved this complex problem
satisfactory were closing labels on closing block delimiter in PL/1 ("}' in Perl;
"begin/end pair in PL/1). Like with "missing semicolon" this is the problem from which
programmer suffer independently of the their level of experience with the language.
So IMHO any measures that compensate for "dangling '}' " problem and provide better
coordination between opening and closing delimiters in the nested blocks would be
beneficial.
Again the problem of missing closing brace is a chronic one. As somebody mentioned here
the editor that has "match brace" can be used to track it but that does not solve the
problem itself, dues provide a rather inefficient (for complex script) way to troubleshoot
one. Which arise especially often if you modify the script. I experienced even a case when
syntactically { } braces structure were correct but semantically wrong and that was
detected only after the program was moved to production. Closing label on bracket would
prevent it.
But IMHO it does not go far enough as it does not distinguish between reading and
modifying a variable. And "sunglasses" approach to visibility of global variable might be
beneficial.
If you write short subroutines, as you should, you don't suffer from misplaced closing
curly braces. I had problems with them, especially when doing large edits on code not
written by me, but the editor always saved me.
More or less agree WRT mismatched closing curlies. I see it pretty much entirely as an
editor issue.
(I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping? At
least I recall that ("Your editor will keep it straight") being seriously offered as a
valid dismissal of the criticism against S-W-A-G . . .)
The cake is a lie.
The cake is a lie.
The cake is a lie.
I mean isn't that the whole python argument for Semantic-Whitespace-As-Grouping?
No the argument is different, but using indentation to determine block nesting
does allow multiple close of blocks, as a side effect. Python invented strange mixed
solution when there is an opening bracket (usually ":") and there is no closing bracket --
instead indent is used as the closing bracket.
The problem is that it breaks too many other things, so here the question "whether it
worth it" would be more appropriated that in case of soft semicolons.
[Highly desirable] Make a semicolon optional at the end of the line, if there is a
balance of brackets on the line and the statement looks syntactically correct ("soft
semicolon", the solution used in famous IBM PL/1 debugging compiler).
I feel a bit ashamed to admit that I had programmed in PL/I for several years. The reason
why PL/I was so relaxed w.r.t. syntax is simple: You put your box full of punched cards to
the operators' desk and you get the compiler's result the next day. If the job had failed
just because of a missing semicolon, you'd loose one full day. Nowadays there is absolutely
no need for such stuff.
BTW, the really fatal errors in a PL/I program resulted in a compiler warning of
the kind "conversion done by subroutine call". This happend e.g. when assigning a pointer to
a character array.
I wouldn't like to see any of the fancy features of PL/I in Perl. Consult your
fortune database:
Speaking as someone who has delved into the intricacies of PL/I, I am sure that only
Real Men could have written such a machine-hogging, cycle-grabbing, all-encompassing
monster. Allocate an array and free the middle third? Sure! Why not? Multiply a character
string times a bit string and assign the result to a float decimal? Go ahead! Free a
controlled variable procedure parameter and reallocate it before passing it back? Overlay
three different types of variable on the same memory location? Anything you say! Write a
recursive macro? Well, no, but Real Men use rescan. How could a language so obviously
designed and written by Real Men not be intended for Real Man use?
Currently, the big push is to turn on warnings and strict by default; I like the initially
slow approach. I don't have a strong opinion about any of your suggestions (good or bad)
because I see none of them as particularly disruptive. Heck, I'd be happy to to have
say and state available without turning them on explicitly. Ultimately, I
just look forward to moving towards a more aggressive model of having new features on by
default.
Disambiguation: If the actual element is blessed and can('method1') , it is
invoked. Otherwise it is treated as a function call ( :: might be used for further
disambiguation).
I.e. similar to Data::Diver , just
more efficient together with a pragma or other method to control auto-vivification. Yes, I am
aware, that I could build something similar as a module, but it would be pure Perl.
Comment on What
esteemed monks think about changes necessary/desirable in Perl 7 outside of OO
staff
"... A lot of resources have been pushed into Python and The Cloud in the past decade. It seems to me that this has come at the opportunity cost of traditional Linux/Unix sysadmin skills. ..."
"... And in a lot of cases, there's no documentation, because after all, the guy was just trying to solve a problem, so why document it? It's "just for now," right? If you find yourself in this situation enough times, then it's easy to start resenting the thing that all of these pieces of code have in common: Perl. ..."
"... I'm glad you're finding Perl to be clever and useful. Because it is. And these days, there are lots of cool modules and frameworks that make it easier to write maintainable code. ..."
"... Perl was the tool of choice at the dawn of the web and as a result a lot of low to average skill coders produced a large amount of troublesome code much of which ended up being critical to business operations. ..."
"... As a Bioinformatician I also see a bunch of hostility for Perl, many people claim it is unreadable and inefficient, but as other pointed, it has a lot of flexibility and if the code is bad is because of the programmer, not the language. ..."
"... I don't hate Python but I prefer Perl because I feel more productive on it, so I don't understand people who said that Perl is far worse than Python. Both have their own advantages and disadvantages as any other computer language. ..."
"... When you look at a language like Go, it was designed to make writing good go easy and bad go hard. it's still possible to architect your program in a bad way, but at least your implementation details will generally make sense to the next person who uses it. ..."
"... I also commonly see bad code in Python or Java ..."
"... Much of the hostility comes from new programmers who have not had to work in more than one language, Part of this is the normal Kubler Ross grief cycle whenever programmers take on a legacy code base. Part of it has to do with some poorly written free code that became popular on early Web 1.0 websites from the 90's. Part of this come from the organizations where "scripting" languages are popular and their "Engineering In Place" approach to infrastructure. ..."
"... Perl might be better than Python3 for custom ETL work on large databases. ..."
"... Perl might be better than Python at just about everything. ..."
"... I use f-strings in Python for SQL and... I have no particular feelings about them. They're not the worst thing ever. Delimiters aren't awful. I'm not sure they do much more for me than scalar interpolation in Perl. ..."
"... I think Perl is objectively better, performance and toolset wise. My sense is the overhead of "objectifying" every piece of data is too much of a performance hit for high-volume database processing ..."
"... the Python paradigm of "everything is an object" introduces overhead to a process that doesn't need it and is repeated millions or billions of times, so even small latencies add up quickly. ..."
"... I think what the Perl haters are missing about the language is that Perl is FUN and USEFUL. It's a joy to code in. It accomplishes what I think was Larry Wall's primary goal in creating it: that it is linguistically expressive. There's a certain feeling of freedom when coding in it. I do get though that it's that linguistic expressiveness characteristic that makes people coming from Python/Java/JavaScript background dislike about it. ..."
"... Like you said, the way to appreciate Perl is to be aware that it is part of the Unix package. I think Larry Wall said it best: "Perl is, in intent, a cleaned up and summarized version of that wonderful semi-natural language known as 'Unix'." ..."
"... I don't know why, but people hating on Perl doesn't bother me as much as those who are adverse to Perl but fond of other languages that heavily borrow from Perl -- without acknowledging the aspects of their language that were born, and created first in Perl. Most notably regular expressions; especially Perl compatible expressions. ..."
"... My feelings is that Perl is an easy language to learn, but difficult to master. By master I don't just mean writing concise, reusable code, but I mean readable, clean, well-documented code. ..."
"... Larry Wall designed perl using a radically different approach from the conventional wisdom among the Computer Science intelligentsia, and it turned out to be wildly successful. They find this tremendously insulting: it was an attack on their turf by an outsider (a guy who kept talking about linguistics when all the cool people know that mathematical elegance is the only thing that matters). ..."
"... The CS-gang responded to this situation with what amounts to a sustained smear campaign, attacking perl at every opportunity, and pumping up Python as much as possible. ..."
"... The questionable objections to perl was not that it was useless-- the human genome project, web 1.0, why would anyone need to defend perl? The questionable objections were stuff like "that's an ugly language". ..."
"... I generally agree that weak *nix skills is part of it. People don't appreciate the fact that Perl has very tight integration with unix (fork is a top-level built in keyword) and think something like `let p :Process = new Process('ls', new CommandLineArguments(new Array<string>('-l'))` is clean and elegant. ..."
"... But also there's a lot of dumb prejudice that all techies are guilty of. Think Bing -- it's a decent search engine now ..."
"... On a completely different note, there's a lot of parallels between the fates of programming languages (and, dare I say, ideas in general ) and the gods of Terry Pratchett's Discworld. I mean, how they are born, how they compete for believers, how they dwindle, how they are reborn sometimes. ..."
"... You merely tell your conclusions and give your audience no chance to independently arrive at the same, they just have to believe you. Most of the presented facts are vague allusions, not hard and verifiable. If you cannot present your evidence and train of thought, then hardly anyone takes you serious even if the expressed opinions happen to reflect the truth. ..."
I like Perl, even though I struggle with it sometimes. I've slowly been pecking away at
getting better at it. I'm a "the right tool for the job" kind of person and Perl really is the
lowest common denominator across many OSes and Bash really has its limits. Perl still trips me
up on occasion, but I find it a very clever and efficient language, so I like it.
I don't understand the hostility towards it given present reality. With the help of Perl
Critic and Perl Tidy it's no longer a "write only language." I find it strange that people call
it a "dead language" when it's still widely used in production.
A lot of resources have been pushed into Python and The Cloud in the past decade. It seems
to me that this has come at the opportunity cost of traditional Linux/Unix sysadmin skills. Perl
is part of that package, along with awk, sed, and friends along with a decent understanding of
how the init system actually works, what kernel tunables do, etc.
I could be wrong, not nearly all seeming correlations are causal relationships. Am I alone
in thinking a decent portion of the hostility towards Perl is a warning sign of weak sysadmin
skills a decent chunk of the time?
Perl was the tool of choice at the dawn of the web and as a result a lot of low to average
skill coders produced a large amount of troublesome code much of which ended up being
critical to business operations. This was complicated by the fact that much early web
interaction was dominated by CGI based forms which had many limitations as well as early Perl
CGI modules having many quirks.
The long term oriented dreaming about the future that started with Perl 6 and matured into
Rakudo also made a lot of people with issues to resolve with the deployed base of mostly Perl
5 code also alienated a lot of people.
Yeah, this is where the hostility comes from. The only reason to be angry at Perl is that
Perl allows you to do almost anything. And this large user base of people who weren't
necessarily efficient programmers -- or even programmers at all -- people like me, that is...
took up Perl on that challenge.
"OK, we'll do it HOWEVER we want."
Perl's flexibility makes it very powerful, and can also make it fairly dangerous. And
whether that code continues to work or not (it generally does), somebody is inevitably going
to have to come along and maintain it, and since anything goes, it can be an amazingly
frustrating experience to try to piece together what the programmer was thinking.
And in a lot of cases, there's no documentation, because after all, the guy was just
trying to solve a problem, so why document it? It's "just for now," right? If you find yourself in this situation enough times, then it's easy to start resenting the
thing that all of these pieces of code have in common: Perl.
I'm glad you're finding Perl to be clever and useful. Because it is. And these days, there
are lots of cool modules and frameworks that make it easier to write maintainable code.
It was also where I began to learn my craft. My coding practices improved as a learned
more, but I appreciate that Matt was there at the time, offering solutions to those who
needed them, when they needed them.
I also appreciate that Matt himself has spoken out about this, saying "The code you find
at Matt's Script Archive is not representative of how even I would code these days."
It's easy to throw stones 25 years later, but I think he did more good than harm. That
might be a minority opinion. In any case, I'm grateful for the start it gave me.
Speaking of his script archive, I believe his early scripts used cgi-lib.pl, which had a
subroutine in it called ReadParse() . That is where my username comes form. It's
a tribute to the subroutine that my career relied on in the early days, before I graduated to
CGI.pm, before I graduated to mod_perl, before I graduated to Dancer and Nginx.
Perl was the tool of choice at the dawn of the web and as a result a lot of low to
average skill coders produced a large amount of troublesome code much of which ended up
being critical to business operations.
So in the context of webdev, it was JavaScript before JavaScript was a thing. No wonder
people still have a bad taste in their mouth lol
As a Bioinformatician I also see a bunch of hostility for Perl, many people claim it is
unreadable and inefficient, but as other pointed, it has a lot of flexibility and if the code
is bad is because of the programmer, not the language.
I don't hate Python but I prefer Perl because I feel more productive on it, so I don't
understand people who said that Perl is far worse than Python. Both have their own advantages
and disadvantages as any other computer language.
'if the code is bad is because of the programmer, not the language'
That's not going to make you feel any better about joining a project and having to work on
a lot of badly written code, nor does it help when you need to trace through your
dependencies and find it too is badly written.
in the end it's entirely possible to write good Perl, but you have to go out of your way
to do so. Bad Perl is just as valid and still works, so it gets used more often than good
Perl.
When you look at a language like Go, it was designed to make writing good go easy and bad
go hard. it's still possible to architect your program in a bad way, but at least your
implementation details will generally make sense to the next person who uses it.
Personally I still really like Perl for one-off tasks that are primarily string
manipulation. it's really good at that, and maintainability doesn't matter nor does anyone
else code. For anything else, there's usually a better tool to reach for.
agree, I also commonly see bad code in Python or Java. I am tented to learn Go too, I was
looking into the syntax but I don't have any project or requirement that needs it.
Also, Bioinformatics has a large part for string manipulation (genes and genomes are
represented as long strings), so Perl fits naturally. Hard tasks are commonly using specific
programs (C/Java/etc) so you need to glue them, for that Bash, Perl or even Python are
perfectly fine.
Much of the hostility comes from new programmers who have not had to work in more than one
language, Part of this is the normal Kubler Ross grief cycle whenever programmers take on a
legacy code base. Part of it has to do with some poorly written free code that became popular
on early Web 1.0 websites from the 90's. Part of this come from the organizations where
"scripting" languages are popular and their "Engineering In Place" approach to
infrastructure.
And then there is the self inflicted major version freeze for 20 years. Any normal project
would have had three or more major version bumps for the amount of change between perl 5.0
and perl 5.30. Instead perl had a schism. Now perl5 teams are struggling to create the
infrastructure needed to release a major version bump. Even seeding the field ahead with
mines just to make the bump from 5 to 7 harder.
What do you think about Javascript's template strings (which can be tagged for custom
behaviors!) and Python's recent f-strings? Well, there's also Ruby's
#{interpolation} which allows arbitrary expressions to be right there, and which
existed for quite a while (maybe even inspiring similar additions elsewhere, directly or
indirectly).
Having to either fall back on sprintf for readability or turn the strings
into a concatenation-fest somewhat tarnishes Perl's reputation as the ideal language for text
processing in this day and age.
My other pet peeve with Perl is how fuzzy its boundaries between bytes and unicode are,
and how you always need to go an extra mile to ensure the string has the exact state you
expect it to be in, at all callsites which care. Basically, string handling in Perl is
something that could be vastly improved for software where bytes/character differences are
important.
What do you think about Javascript's template strings (which can be tagged for custom
behaviors!) and Python's recent f-strings?
I use f-strings in Python for SQL and... I have no particular feelings about them. They're
not the worst thing ever. Delimiters aren't awful. I'm not sure they do much more for me than scalar interpolation in Perl. Maybe because
it's Python I'm always trying to write the most boring code ever because it feels like the
language fights me when I'm not doing it Python's way.
My other pet peeve with Perl is how fuzzy its boundaries between bytes and unicode are,
and how you always need to go an extra mile to ensure the string has the exact state you
expect it to be in, at all callsites which care.
I'd have to know more details about what's bitten you here to have a coherent opinion. I
think people should know the details of the encoding of their strings everywhere it matters,
but I'm not sure that's what you mean.
In Python's f-strings (and JS template strings) you can interpolate arbitrary expressions,
thus no need to pollute the local scope with ad hoc scalars.
Ad hoc scalar pollution hasn't been a problem in code I've worked on, mostly because I try
to write the most boring Python code possible. I've seen Rust, Go, and plpgsql code get really ugly with lots of interpolation in
formatted strings though, so I believe you.
I think Perl is objectively better, performance and toolset wise. My sense is the overhead
of "objectifying" every piece of data is too much of a performance hit for high-volume
database processing. Just one datapoint, but as far as I know, Python doesn't support
prepared statements in Postgres. psycopg2 is serviceable but a far cry from the
nearly-perfect DBI. Sqlalchemy is a wonderful alternative to the also wonderful DBIx::Class,
but performance-wise neither are suitable for ETL.
I think Perl is objectively better, performance and toolset wise. My sense is the
overhead of "objectifying" every piece of data is too much of a performance hit for
high-volume database processing.
It's because objects are not first-class in Perl. Python's objects run circles around
plain Perl blessed hashes, and we aren't even talking about Moose at this point.
The point is, for ETL in particular, the Python paradigm of "everything is an object"
introduces overhead to a process that doesn't need it and is repeated millions or billions of
times, so even small latencies add up quickly. And, if you are using psycopg2, the lack of
prepared statements adds yet more latency. This is a very specific use case where Perl is
unequivocally better.
Do you have any measurements to back this overhead assertion, or are you just imagining it
would be slower, because objects? int, str, float "objects" in Python are objects indeed, but
they also are optimized highly enough to be on par, if not, dare I say, faster than Perl
counterparts.
Also, you can run "PREPARE x AS SELECT" in psycopg2. It's not trying to actively
prevent it from doing it. I also bet the author would add this functionality if someone paid
him, but even big corporations tend to be on the "all take and no give" side, which shouldn't
come as news anyway.
Before you say "but it's inconvenient!", I'd really like my exceptions, context managers
and generator functions in Perl, in a readable and caveat-less style, thank you very much,
before we can continue our discussion about readability.
I think what the Perl haters are missing about the language is that Perl is FUN and
USEFUL. It's a joy to code in. It accomplishes what I think was Larry Wall's primary goal in
creating it: that it is linguistically expressive. There's a certain feeling of freedom when
coding in it. I do get though that it's that linguistic expressiveness characteristic that
makes people coming from Python/Java/JavaScript background dislike about it.
Like you said, the way to appreciate Perl is to be aware that it is part of the Unix
package. I think Larry Wall said it best: "Perl is, in intent, a cleaned up and summarized
version of that wonderful semi-natural language known as 'Unix'."
I don't know why, but people hating on Perl doesn't bother me as much as those who are
adverse to Perl but fond of other languages that heavily borrow from Perl -- without
acknowledging the aspects of their language that were born, and created first in Perl. Most
notably regular expressions; especially Perl compatible expressions.
What else, except for regular expressions, which wasn't borrowed by Perl itself from awk,
C, Algol?
Ruby, for example, does state quite plainly that it aims to absorb the good parts of Perl
without its warts, and add good things of its own. So you have, for example, the "unless"
keyword in it, as well as postfix conditionals. Which are exceptionally good for guard
clauses, IMO.
PHP started specifically as "Perl-lite", thus it borrowed a lot from Perl, variables
having the $ sigil in front of them are taken specifically from Perl, nobody is
denying that.
This doesn't mean this cross-pollination should ever stop, or all other languages suddenly
need to start paying tribute for things they might have got inspired by Perl. Making every
little user on the internets acknowledge that this or that appeared in Perl first does
little, alas, to make Perl better and catch up to what the world is doing today.
It's very much like modern Greeks are so enamored with their glorious past, Alexander the
Great, putting a lot of effort into preserving their ancient history, and to remind the world
about how glorious the ancient Greeks were while the barbarians of Europe were all unwashed
and uncivilized, that they forget to build a glorious present and future.
Also an interesting quote from the Man Himself in 1995:
I certainly "borrowed" some OO ideas from Python, but it would be inaccurate to claim
either that Perl borrowed all of Python's OO stuff, or that all of Perl's OO stuff is
borrowed from Python.
Looking at Perl's OO system, I find myself mildly surprised, because it's nothing
like Python's. But here you have, cross-pollination at work.
My feelings is that Perl is an easy language to learn, but difficult to master. By master
I don't just mean writing concise, reusable code, but I mean readable, clean, well-documented
code.
I can count on one hand the Perl developers I've known that really write such clean Perl
code. I feel the freehand style of perl has been a double-edged sword. With freedom comes to
many developers a relaxed sense of responsibility.
I feel that the vast amount of poorly written code that has been used in the wild, which
has earned (as we've all heard at one time or another) the dubious honor of being the "duct
tape and bailing wire" language that glues the IT world together has caused a lot of people
to be biased poorly against the language as a whole.
Larry Wall designed perl using a radically different approach from the conventional wisdom
among the Computer Science intelligentsia, and it turned out to be wildly successful. They
find this tremendously insulting: it was an attack on their turf by an outsider (a guy who
kept talking about linguistics when all the cool people know that mathematical elegance is
the only thing that matters).
You would have to say that Larry Wall has conceded he initally over-did some things, and
the perl5 developers later set about fixing them as well as they could, but perl's detractors
always seem to be unaware of these fixes: they've never heard of "use strict", and they
certainly haven't ever heard of //x extended regex syntax.
The CS-gang responded to this situation with what amounts to a sustained smear campaign,
attacking perl at every opportunity, and pumping up Python as much as possible.
Any attempt at understanding this situation is going to fail if you try to understand it
on anything like rational grounds-- e.g. might their be some virtue in Python's rigid syntax?
Maybe, but it can't possibly have been a big enough advantage to justify re-writing all of
CPAN.
You described it as if there had been a religious war, or a conspiracy, and not simple
honest-to-god pragmatism at work. People have work to do, that's all there is to it.
Because I really don't think it was. I was there, and I've been around for quite some
time, and I've watched many technical fads take off before there was any there there which
then had people scrambling to back-fill the Latest Thing with enough of a foundation to keep
working with it. Because once one gets going, it can't be stopped without an admission we
were wrong again.
The questionable objections to perl was not that it was useless-- the human genome project, web 1.0,
why would anyone need to defend perl? The questionable objections were stuff like "that's an ugly
language".
I generally agree that weak *nix skills is part of it. People don't appreciate the fact
that Perl has very tight integration with unix (fork is a top-level built in keyword) and
think something like `let p :Process = new Process('ls', new CommandLineArguments(new
Array<string>('-l'))` is clean and elegant.
But also there's a lot of dumb prejudice that all techies are guilty of. Think Bing --
it's a decent search engine now, but everyone who has ever opened a terminal window thinks it
because it had a shaky first few years. Perl 4 and early Perl 5 which looked like Perl 4 was
basically our "Bing".
On a completely different note, there's a lot of parallels between the fates of
programming languages (and, dare I say, ideas in general ) and the gods of Terry
Pratchett's Discworld. I mean, how they are born, how they compete for believers, how they
dwindle, how they are reborn sometimes.
(Take it with a grain of salt, of course. But I generally like the idea of ideas being a
kind of lifeforms unto themselves, of which we the minds are mere medium.)
I follow the analogy. Ideas are in some sense "alive" (and tend to follow a viral model in
my view) to a great extent. I have not read Discworld, so the rest I do not follow.
Can you spell it out for me, especially any ideas you have about a Perl renaissance? I
have a gut sense Perl is at the very start of one, but feel free to burst my bubble if you
think I'm too far wrong.
In Perl, length(@list) still wasn't doing what any reasonable person would
expect it to do.
CPAN was full of zombie modules. There is a maintainer who is apparently unaware what
"deprecated" means, so you have a lot of useful and widely-used modules DEPRECATED without
any alternative.
So far, there only exists one Perl implementation. Can you compile it down to Javascript
so there is a way to run honest-to-god Perl in a browser? Many languages can do it without
resorting to emscripten or WebAssembly.
I'm not aware of any new Perl 5 books which would promote good programming style, instead
of trying to enamore the newbies with cutesy of "this string of sigils you can't make heads
or tails of prints 'Yet another Perl hacker! How powerful!'". Heck, I'm not aware of any Perl
books published in the last decade at all . So much for teaching good practices to
newbies, eh?
Perl is a packaging nightmare, compared to Python (and Python is a nightmare too in this
regard, but a far far more manageable one), Javascript (somewhat better), or Go. It takes a
lot of mental gymnastics to make Perl CI-friendly and reproducible-process-friendly (not the
same as reproducible-builds-friendly, but still a neat thing to have in this day and
age).
Tell me about new Perl projects that started in 2020, and about teams who can count their
money who would consciously choose Perl for new code.
And the community. There are feuds between that one developer and the world, between that
other developer and the world, and it just so happens that those two wrote things 90% of
functioning CPAN mass depends on one way or the other.
I don't hate Perl (it makes me decent money, why would I?), so much as I have a pity for
it. It's a little engine that could, but not the whole way up.
In Perl, length(@list) still wasn't doing what any reasonable person would expect it to
do.
I'm not aware of any new Perl 5 books which would promote good programming style,
instead of trying to enamore the newbies with cutesy of "this string of sigils you can't
make heads or tails of prints 'Yet another Perl hacker! How powerful!'". Heck, I'm not
aware of any Perl books published in the last decade at all.
Which could use a new edition, granted, as the last one is from 2015
There are a couple of things I'd like to add in a new edition (postfix dereferencing,
signatures), but I might wait to see if there's more clarification around Perl 7 first.
You really need to explain how you arrive at the claim that "Perl is a packaging
nightmare" – I am a packager – and also be less vague about the other things you
mention. It is not possible to tell whether you are calibrated accurately against
reality.
so there is a way to run honest-to-god Perl in a browser?
You merely tell your conclusions and give your audience no chance to independently arrive
at the same, they just have to believe you. Most of the presented facts are vague allusions,
not hard and verifiable. If you cannot present your evidence and train of thought, then
hardly anyone takes you serious even if the expressed opinions happen to reflect the
truth.
The tooling around CPAN, including cpan and cpanm alike, last
that I looked at them, did a depth-first dependency resolution. So, the first thing is a
module A. It depends on module B, get the latest version of that. It depends on C, get the
latest version of that. Finally, install C, B, and A. Next on the dependency list is module
D, which depends on module E, which wants a particular, not the latest, version of B. But B
is already installed and at the wrong version! So cpan and cpanm
alike will just give up at this point, leaving my $INSTALL_BASE in a broken
state.
Note that we're talking about second- and third-order dependencies here, in the ideal
world, I'd prefer I didn't have to know about them. In a particular codebase I'm working on,
there are 130 first-order dependencies already.
Carton, I see, is trying to sidestep the dependency resolution of cpanm .
Good, but not good enough, once your codebase depends on Image::Magick . Which
the one I care about does. You cannot install it from CPAN straight, not if you want a
non-ancient version.
So I had to write another tool that is able to do breadth-first search when resolving
dependencies, so that I either get an installable set of modules, or an error before it
messes up the $INSTALL_BASE . In the process, I've learned a lot about the
ecosystem which is in the category of "how sausages are made": for example, in the late 2017
and early 2018, ExtUtils::Depends , according to MetaCPAN, was provided by
Perl-Gtk . Look it up if you don't believe me, ask the MetaCPAN explorer
this:
/module/_search?q=module.name.lowercase:"extutils::depends" AND maturity:released&sort=version_numified:desc&fields=module.name,distribution,date
The first entry rectifies the problem, but it was released in 2019. In 2018, MetaCPAN
thought that ExtUtils::Depends was best served by Perl-Gtk . Also,
to this day, MetaCPAN thinks that the best distribution to contain
Devel::CheckLib is Sereal-Path .
Oh. And I wanted an ability to apply arbitrary patches to distributions, which fix issues
but the maintainers can't be bothered to apply them, or which remove annoyances. Not
globally, like cpan+distroprefs does, but per-project. (Does Carton even work with
distroprefs or things resembling them?) Yes, I know I can vendor in a dependency, but it's a
third-order dependency, and why should I even bother for a one-liner patch?
Now, the deal is, I needed a tool that installs for me everything the project depends on,
and does it right on the first try, because the primary user of the tool is CI, and there are
few things I hate more than alarms about broken, flaky builds. Neither Carton, nor cpanminus,
nor cpan could deliver on this. Maybe they do today, but I simply don't care anymore, good
for them if they do. I've got under a very strong impression that the available Perl tooling
is still firmly in the land of sysadmin practices from the 1990s, and it's going to take a
long while before workflows that other stacks take for granted today arrive there.
P. S. I don't particularly care how seriously, if at all, I'm taken here. There have been
questions asked, so I'm telling about my experience. Since comments which express a dislike
with particular language warts but don't have a disclaimer "don't get me wrong, I ABSOLUTELY
LOVE Perl" get punished by downvoting here, I feel that the judgment may be mutual.
I am glad that you wrote a post with substance, thank you for taking the time to gather
the information. That makes it possible to comment on it and further the insight and reply
with corrections where appropriate. From my point of view the situation is not as bad as you
made it out to be initially, let me know what you think.
punished by downvoting
I didn't downvote you because I despise downvote abuse; it's a huge problem on Reddit and
this subreddit is no exception. I upvoted the top post to prevent it from becoming
hidden.
dependency resolution
You got into the proverbial weeds by trying to shove the square peg into the round hole,
heaping work-around onto work-around. You should have noticed that when you "had to write
another tool"; that would be the point in time to stop and realise you need to ask experts
for advice. They would have put you on the right track: OS level packaging. That's what I
use, too, and it works pretty good, especially compared with other programming languages and
their respective library archives. Each dep is created in a clean fakeroot, so it is
impossible to run into " $INSTALL_BASE in a broken state". Image::Magick is not
a problem because it's already packaged, and even in the case of a library in a similar
broken state it can be packaged straight-forward because OS level packaging does not care
about CPAN releases per se. Module E depending on a certain version of B is not a problem
because a repo can contain many versions of B and the OS packager tool will resolve it
appropriately at install time. Per-project patches are not a problem because patches are a
built-in feature in the packaging toolchain and one can set up self-contained repos for
packages made from a patched dist if they should not be used in the general case.
MetaCPAN explorer
I hope you reported those two bugs. Using that API to resolve deps is a large blunder.
cpan uses the index files, cpanm uses cpanmetadb.
sysadmin practices from the 1990s
There's nothing wrong with them, these practices do not lose value just by time passing
by, the practices and corresponding software tools are continually updated over the years,
and the fundamentals are applicable with innovative packaging targets (e.g. CI environments
or open containers).
I simply don't care anymore
I omit the details showing how to do packaging properly.
Re: OS packaging versus per-project silos. The latter approach is winning now. There's an
ongoing pressure that OS-packaged scripting runtimes (like Python, Ruby, and Perl) should
only be used by the OS-provided software which happens to depend on it. I think I've read
some about it even here on this sub.
And I'll tell you why. By depending on OS-provided versions of modules, you basically cast
your fate to Canonical, or Red Hat, or whoever else is maintaining the OS, and they don't
really care that what they thought was a minor upgrade broke your code (say,
Crypt::PW44 changed its interface when moving from 0.13 to 0.14, how could
anyone even suspect?). You are too small a fish for them to care. They go with whatever the
upstream supplies. And you have better things to do than adapt whenever your underlying OS
changes things behind your back. Keeping a balance between having to rebuild what's needed in
response to key system libraries moving can be work enough.
There's also this problem when a package you absolutely need becomes orphaned by the
distribution.
So any sane project with bigger codebases will keep their own dependency tree. Not being
married to a particular OS distribution helps, too.
So, keeping your own dependency tree is sort of an established pattern now. Try to suggest
to someone who maintains Node-based software that they use what, for example, CentOS provides
in RPMs instead of directly using NPM. They will die of laughter, I'm afraid.
Re: sysadmin practices from 1990s. They are alive and well, the problem is that they are
not nearly enough in the world of cloud where you can bring a hundred servers to life
with an API call and tear down other 100 with another API call. "Sysadmin practices from
1990s" assume very dedicated humans who work with physical machines and know names of each of
them, think a university lab. Today, you usually need a superset of these skills and
practices. You need to manage machines with other machines. Perl's tooling could be vastly
improved in this regard.
Re: CPAN, MetaCPAN, cpanmetadb and friends . So I'm getting confused. Which metadata
database is authoritative, the most accurate and reliable for package metadata retrieval,
including historical data? MetaCPAN, despite its pain points, looks the most complete so far.
cpanmetadb doesn't have some of the metacpan's bugs, but I'm wary of it as it looks like it's
a one man show (one brilliant man show, but still) and consists of archiving package
metadata files as they change.
Also, I don't think that if one Marc Lehmann provides such metadata in
Gtk-Perl that metacpan starts honestly thinking it provides
ExtUtils::Depends (which is by the same author, so fair enough), there can be
anything done about it. When I pointed out those things, I was lamenting the state of the
ecosystem as such more than any tool. With metacpan, my biggest peeve is that they use
ElasticSearch as the database, which is wrong on many levels (like 404-ing legit packages
because the search index died, WTF? It also appears anyone on the internets can purge the
cache with a curl command, WTF???)
The MetaCPAN API is not the canonical way to resolve module dependencies, and is not used
by CPAN clients normally, only used by cpanm when a specific version or dev
release of a module is requested. See https://cpanmeta.grinnz.com/packages for a way to
search the 02packages index, which is canonical.
I understand you are beyond this experience, but for anyone who runs into similar problems
and wants guidance for the correct solutions, please ask the experts at #toolchain on
irc.perl.org (politely, we are all volunteers) before digging yourself further holes.
In Perl, length(@list) still wasn't doing what any reasonable person would expect it to
do.
I would be quite against overloading length to have a different effect when
passed an array. But I don't disagree that "array in scalar context" being the standard way
to get its size is unintuitive.
He claims that functions cannot be redeclared (they can, but you get a warning).
He recommends calling functions using the ampersand ( that's a bad idea ).
Looking at the table of contents, I see he calls hashes "associative array variables" (a
term that Perl stopped using when Perl 5 was released in 1994).
This is not a book that I would recommend to anyone.
Update: And here's Pro Perl Programming by the same author.
In the preview, he uses bareword filehandles instead of the lexical variables that have been
recommended for about fifteen years.
I have run into developers who active loathe Perl for it's "line noise" quality.
Unfortunately, I think they've mostly every encountered bad Perl, to which they would
respond, "Is there any other kind of Perl?"
"One of the first programming languages." Wow. That kinda dismisses about 30 years of
programming language history before Perl, and at least a couple of dozen major languages,
including LISP, FORTRAN, Algol, BASIC, PL/1, Pascal, Smalltalk, ML, FORTH, Bourne shell and
AWK, just off the top of my head. Most of what exists in today's common (and even
not-so-common) programming languages was invented before Perl.
That said, I know you're arm-waving the history here, and those details are not really
part of the point of your post. But I do have a few comments on the meat of your post.
Perl is a bit punctuation- and magic-variable-heavy, but is far from unique in being so.
One example I just happened to be looking at today is VTL-2
("A Very Tiny Language") which, admittedly, ran under unusually heavy memory constraints (a
768 byte interpreter able to run not utterly trivial programs in a total of 1 KB of
memory). This uses reading from and assignment to special "magic" variables for various
functions. X=? would read a character or number from the terminal and assign
it to X ; ?=X would print that value. # was the
current execution line; #=300 would goto line 300. Comparisons returned 0 or
1, so #=(X=25)\*50 was, "If X is equal to 25, goto line 50."
Nor is Perl at all exotic if you look at its antecedents. Much of its syntax and
semantics are inspired by Bourne shell, AWK and similar languages, and a number of these
ideas were even carried forward into Ruby. Various parts of that style (magic variables,
punctuation prefixes/suffixes determining variable type, automatic variable interpolation
in strings, etc.) have been slowly but steadily going out of style since the 70s, for good
reasons, but those also came into existence for good reasons and were not at all unique to
Perl. Perl may look exotic now, but to someone who had been scripting on Unix in the 80s
and 90s, Perl was very comfortable because it was full of common idioms that they were
already familiar with.
I'm not sure what you mean by Perl "[not supporting] functions with arguments";
functions work the same way that they work in other languages, defined with sub foo {
... } and taking parameters; as with Bourne shell, the parameters need not be
declared in the definition. It's far from the only language where parentheses need not be
used to delimit parameters when calling a function. Further, it's got fairly good
functional and object-oriented programming support.
I'm not a huge fan of Perl (though I was back in the early '90s), nor do I think its
decline is unwarranted (Ruby is probably a better language to use now if you want to
program in that style), but I don't think you give it a fair shake here.
Nor is it its decline, along with COBOL and Delphi, anything to do with age. Consider
LISP, which is much older, arguably weirder, and yet is seeing if anything a resurgence of
popularity (e.g., Clojure) in the last ten years.
There are many languages indeed. Speaking from a career-wise, professional perspective
here. It could be quite difficult to make a career today out of those.
About functions. What I mean is that Perl doesn't do functions with arguments like
current languages do. "func myfunction(arg1, arg2, arg3)."
It's correct to say that Perl has full support for routines and parameters, it does and
even in multiple ways, but it's not comparable to what is in mainstream languages
today.
I can understand, that you don't like Perl as a language, but it doesn't mean you
should write misconceptions about it.
Personally I think Perl won't go anywhere. Nobody wants to rewrite existing scripts
that are used by system tools, ie. dpkg utilities in Debian or Linux kernel profiling
stuff. As a real scripting language for basic system tasks is still good enough and
probably you won't find better replacement.
And nobody uses CGI module from Perl in 2019. Really.
I see by "functions with arguments" you mean specifically call-site checking against
a prototype. By that definition you can just as well argue that Python and Ruby "don't
support functions with arguments" because they also don't do do call-site checking
against prototypes in the way that C and Java do, instead letting you pass a string to
a function expecting an integer and waiting until it gets however much further down the
call stack before generating an exception.
"Dynamic" languages all rely to some degree or other on runtime checks; how and what
you check is something you weigh against other tradeoffs in the language design. If you
were saying that you don't like the syntax of sub myfunction { my ($arg1, $arg2,
$arg3) = @_; ...} as compared to def myfunction(arg1, arg2, arg3):
... that would be fair enough, but going so far as to say "Perl doesn't support
functions with arguments" is at best highly misleading and at worst flat-out wrong.
Particularly when Perl does have prototypes with more call site checking
than Python or Ruby do, albeit as part of a language feature for doing
things that neither those nor any other language you mention support.
In fact, many languages even deliberately provide support to remove parameter count
checks and get Perl's @_ semantics. Python programmers regularly use
def f(*args): ... ; C uses the more awkward varargs .
And again I reiterate (perhaps more clearly this time): Perl was in no way
"genuinely unique and exotic" when it was introduced; it brought together and built on
a bunch of standard language features from various languages that anybody programming
on Unix above the level of C in the 80s and 90s was already very familiar with.
Also, I forgot to mention this in my previous comment, but neither Python nor Perl
have ever been required by POSIX (or even mentioned by it, as far as I know), nor did
Python always come pre-installed on Linux distributions. Also, it seems unlikely to be
a "matter of time" until Python gets removed from the default Ubuntu install since
Snappy and other Canonical tools are written in it.
There are plenty of folks making a career out of Clojure, which is one flavour of
LISP, these days. According to your metric, Google Trends, it overtook
OCaml years ago, and seems to be trending roughly even, which is
better than Haskell is doing .
Perl gets picked on for its syntax. It is able to represent very complex programs with
minimalist tokens. A jumble of punctuation can serve to represent an intricate program. This is
trivial terseness in comparison to programming languages like APL (or its later ASCII-suitable
descendants, such as J), where not a single character is wasted.
The Learning Curb
Something can be said for terseness. Rust, having chosen fn to denote
functions, seems to have hit a balance in that regard. There is very little confusion over what
fn means these days, and a simple explanation can immediately alleviate any
confusion. Don't confuse initial confusion with permanent confusion. Once you get over
that initial "curb" of confusion, we don't have to worry any more.
Foreign !=
Confusing
You'll also find when encountering a new syntax that you will immediately not understand,
and instead wish for something much simpler. Non-C++ programers, for example, will raise an
eyebrow at the following snippet:
I remember my first encounter with C++ lambdas, and I absolutely hated the syntax. It
was foreign and unfamiliar, but other than that, my complaints stopped. I could have said "This
is confusing," but after having written C++ lambda expressions for years the above syntax has
become second nature and very intuitive. Do not confuse familiarity with
simplicity.
Explicit is Better than Implicit
except when it needlessly verbose.
Consider the following code:
template <typename T, typename U, int N>
class some_class {};
Pretty straightforward, right?
Now consider this:
class<T, U, int N> some_class {};
Whoa that's not C++!
Sure, but it could be, if someone were convinced enough that it warranted a proposal,
but I doubt it will happen any time soon.
So, you know it isn't valid C++, but do you know what the code means? I'd
wager that the second example is quite clear to almost all readers. It's semantically identical
to the former example, but significantly terser . It's visually distinct from any
existing C++ construct, yet when shown the two "equivalent" code samples side-by-side you can
immediately cross-correlate them to understand what I'm trying to convey.
There's a lot of bemoaning the verbosity of C++ class templates, especially in comparison to
the syntax of generics in other languages. While they don't map identically, a lot of the
template syntax is visual noise that was inserted to be "explicit" about what was
going on, so as not to confuse a reader that didn't understand how template syntax works.
The template syntax, despite being an expert-friendly feature , uses
a beginner-friendly syntax. As someone who writes a lot of C++ templates, I've often
wished for terseness in this regard.
Looking at the API for data::person , we can see that bar() is a
deprecated alias of name() , and frombulate() is deprecated in favor
of get_people() . And using the name foo to refer to a sequence of
data::person seems silly. We have an English plural people . Okay,
let's fix all those things too:
Perfect! We're now know exactly what we're doing: Sorting a list of people by name.
Crazy idea, though Let's put those auto s back in and see what happens:
auto people = get_people();
std::sort(
people.begin(),
people.end(),
[](auto&& lhs, auto&& rhs) {
return lhs.name() < rhs.name();
}
);
Oh no! Our code has suddenly become unreadable again and oh.
Oh wait.
No, it's just fine. We can see that we're sorting a list of people by their name. No
explicit types needed. We can see perfectly well what's going on here. Using foo
and bar while demonstrating why some syntax/semantics are bad is muddying the
water. No one writes foo and bar in real production-ready code. (If
you do, please don't send me any pull requests.)
Even Terser?
std::sort in the above example takes an iterator pair to represent a "range" of
items to iterate over. Iterators are pretty cool, but the common case of "iterate the whole
thing " is common enough to warrant "we want ranges." Dealing with iterables should be
straightforward and simple. With ranges, the iterator pair is extracted implicitly, and we
might write the above code like this:
auto people = get_people();
std::sort(
people,
[](auto&& lhs, auto&& rhs) {
return lhs.name() < rhs.name();
}
);
That's cool! And we could even make it shorter (even fitting the whole sort()
call on a single line) using an expression lambda:
auto people = get_people();
std::sort(people, [][&1.name() < &2.name()]);
What? You haven't seen this syntax before? Don't worry, you're not alone: I made it up. The
&1 means "the first argument", and &2 means "the second
argument."
Note: I'm going to be using range-based algorithms for the remainder of this post, just to
follow the running theme of terseness.
A Modest Proposal: Expression Lambdas
If my attempt has been successful, you did not recoil in horror and disgust as the sight of
my made-up "expression lambda" syntax:
[][&1.name() < &2.name()]
Here's what I hope:
You are over the "learning curb" as you've seen how the syntax corresponds to an earlier
syntax. (The "expression lambda" is roughly equivalent to the lambda in the prior
example).
You have seen how a prior "foreign" example ("terse" templates) can be understandable,
even if not perfect.
You know exactly what it means because the example does not simply use "dummy"
identifiers ( foo , bar , baz , etc.) and actually
acts in a real-world-use-case capacity.
Yes, the lead-in paragraphs were me buttering you up in preparation for me to unveil the
horror and beauty of "expression lambdas."
I am aware of the abbreviated lambdas proposals, and I am aware that it was shot down as
(paraphrasing) "they did not offer sufficient benefit for their added cost and complexity."
Besides that, "expression lambdas" are not abbreviated lambdas. Rather, the original
proposal document cites this style as "hyper-abbreviated" lambdas. The original authors note
that their abbreviated lambda syntax "is about as abbreviated as you can get, without loss of
clarity or functionality." I take that as a challenge.
For one, I'd note that all their examples use simplistic variables names, like
a , b , x , y , args , and
several others. The motivation for the abbreviated lambda is to gain the ability to wield
terseness where verbosity is unnecessary. Even in my own example, I named my parameters
lhs and rhs to denote their position in the comparison, yet there is
very little confusion as to what was going on. I could as well have named them a
and b . We understood with the context what they were. The naming of parameters
when we have such useful context clues is unnecessary!
I don't want abbreviated lambdas. I'm leap-frogging it and proposing hyper-abbreviated
lambdas, but I'm going to call them "expression lambdas," because I want to be different (and I
think it's a significantly better name).
Use-case: Calling an overload-set
C++ overload sets live in a weird semantic world of their own. They are not objects, and you
cannot easily create an object from one. For additional context, see Simon Brand's talk on the subject . There
are several proposals floating around to fill this gap, but I contend that "expression lambdas"
can solve the problem quite nicely.
Suppose I have a function that takes a sequence of sequences. I want to iterate over each
sequence and find the maximum-valued element within. I can use std::transform and
std::max_element to do this work:
Oops! I can't pass std::max_element because it is an overload set, including
function templates. How might an "expression lambda" help us here? Well, take a look:
Cool. We capture like a regular lambda [&] and pass the comparator as an
argument to max_element . What does the equivalent with regular lambdas look
like?
That's quite a bit more. And yes, that decltype(<expr>) is required for
proper SFINAE when calling the closure object. It may not be used in this exact context, but it
is useful in general.
What about variadics?
Simple:
[][some_function(&...)]
What about perfect forwarding?
Well we're still in the boat of using std::forward<decltype(...)> on that
one. Proposals for a dedicated "forward" operator have been shot down repeatedly. As someone
who does a lot of perfect forwarding, I would love to see a dedicated operator (I'll
throw up the ~> spelling for now).
The story isn't much better for current generic lambdas, though:
I use Python somewhat regularly, and overall I consider it to be a very good language. Nonetheless, no
language is perfect. Here are the drawbacks in order of importance to me personally:
It's slow. I mean really, really slow. A lot of times this doesn't matter, but it definitely means
you'll need another language for those performance-critical bits.
Nested functions kind of suck in that you can't modify variables in the outer scope.
Edit:
I
still use Python 2 due to library support, and this design flaw irritates the heck out of me, but
apparently it's fixed in Python 3 due to the
nonlocal
statement.
Can't wait for the libs I use to be ported so this flaw can be sent to the ash heap of history for
good.
It's missing a few features that can be useful to library/generic code and IMHO are simplicity
taken to unhealthy extremes. The most important ones I can think of are user-defined value types
(I'm guessing these can be created with metaclass magic, but I've never tried), and ref function
parameter.
It's far from the metal. Need to write threading primitives or kernel code or something? Good luck.
While I don't mind the lack of ability to catch
semantic
errors
upfront as a tradeoff for the dynamism that Python offers, I wish there were a way to catch
syntactic errors and silly things like mistyping variable names without having to actually run the
code.
The documentation isn't as good as languages like PHP and Java that have strong corporate backings.
Mark
Canlas
,
@Casey, I have to disagree. The index is horrible - try looking up the
with
statement,
or methods on a
list
.
Anything covered in the tutorial is basically unsearchable. I have much better luck with
Microsoft's documentation for C++.
–
Mark
Ransom
Oct
29 '10 at 6:14
2 revs
, 2011-07-24 13:49:48
I hate that Python can't distinguish between declaration and usage of a variable. You don't need
static typing to make that happen. It would just be nice to have a way to say "this is a variable that
I deliberately declare, and I
intend
to
introduce a new name, this is not a typo".
Furthermore, I usually use Python variables in a write-once style, that is, I treat variables as being
immutable and don't modify them after their first assignment. Thanks to features such as list
comprehension, this is actually incredibly easy and makes the code flow more easy to follow.
However, I can't document that fact. Nothing in Python prevents me form overwriting or reusing
variables.
In summary, I'd like to have two keywords in the language:
var
and
let
.
If I write to a variable not declared by either of those, Python should raise an error. Furthermore,
let
declares
variables as read-only, while
var
variables
are "normal".
Consider this example:
x = 42 # Error: Variable `x` undeclared
var x = 1 # OK: Declares `x` and assigns a value.
x = 42 # OK: `x` is declared and mutable.
var x = 2 # Error: Redeclaration of existing variable `x`
let y # Error: Declaration of read-only variable `y` without value
let y = 5 # OK: Declares `y` as read-only and assigns a value.
y = 23 # Error: Variable `y` is read-only
Notice that the types are still implicit (but
let
variables
are for all intents and purposes statically typed since they cannot be rebound to a new value, while
var
variables
may still be dynamically typed).
Finally, all method arguments should automatically be
let
,
i.e. they should be read-only. There's in general no good reason to modify a parameter, except for the
following idiom:
def foo(bar = None):
if bar == None: bar = [1, 2, 3]
This could be replaced by a slightly different idiom:
def foo(bar = None):
let mybar = bar or [1, 2, 3]
Evan
Plaice
,
I so so wish Python had a "var" statement. Besides the (very good) reason you state, it would
also make it a lot easier to read the code because then you can just scan over the page to
spot all the variable declarations.
–
jhocking
Jul
11 '11 at 23:19
2 revs, 2 users 67%
, 2012-09-08 13:01:49
My main complaint is threading, which is not as performant in many circumstances (compared to Java, C
and others) due to the global interpreter lock (see
"Inside
the Python GIL" (PDF link)
talk)
However there is a
multiprocess
interface
that is very easy to use, however it is going to be heavier on memory usage for the same
number of processes vs. threads, or difficult if you have a lot of shared data. The benefit however,
is that once you have a program working on with multiple processes, it can scale across multiple
machines, something a threaded program can't do.
I really disagree on the critique of the documentation, I think it is excellent and better than most
if not all major languages out there.
Also you can catch many of the runtime bugs running
pylint
.
dbr
,
+1 for pylint. I was unaware of it. Next time I do a project in Python, I'll try it out.
Also, multithreading seems to work fine if you use Jython instead of the reference CPython
implementation. OTOH Jython is somewhat slower than CPython, so this can partially defeat the
purpose.
–
dsimcha
Oct
29 '10 at 0:48
Jacob
, 2010-10-28 22:33:08
Arguably
, the lack of static typing, which can introduce certain classes of
runtime
errors,
is not worth the added flexibility that duck typing provides.
Jacob
,
This is correct, though there are tools like PyChecker which can check for errors a compiler
in languages like C/Java would do.
–
Oliver
Weiler
Oct
28 '10 at 23:42
2 revs
, 2010-10-29 14:14:06
I think the object-oriented parts of Python feel kind of "bolted on". The whole need to explicitly
pass "self" to every method is a symptom that it's OOP component wasn't expressly
planned
,
you could say; it also shows Python's sometimes warty scoping rules that were criticized in another
answer.
Edit:
When I say Python's object-oriented parts feel "bolted on", I mean that at times, the OOP side feels
rather inconsistent. Take Ruby, for example: In Ruby,
everything
is
an object, and you call a method using the familiar
obj.method
syntax
(with the exception of overloaded operators, of course); in Python, everything is an object, too, but
some methods you call as a function; i.e., you overload
__len__
to
return a length, but call it using
len(obj)
instead
of the more familiar (and consistent)
obj.length
common
in other languages. I know there are reasons behind this design decision, but I don't like them.
Plus, Python's OOP model lacks any sort of data protection, i.e., there aren't private, protected, and
public members; you can mimic them using
_
and
__
in
front of methods, but it's kind of ugly. Similarly, Python doesn't
quite
get
the message-passing aspect of OOP right, either.
ncoghlan
,
The self parameter is merely making
explicit
what
other languages leave implicit. Those languages clearly have a "self" parameter.
–
Roger
Pate
Oct
29 '10 at 6:08
MAK
, 2010-11-11 13:38:01
Things I don't like about Python:
Threading (I know its been mentioned already, but worth mentioning in every post).
No support for multi-line anonymous functions (
lambda
can
contain only one expression).
Lack of a simple but powerful input reading function/class (like
cin
or
scanf
in
C++ and C or
Scanner
in
Java).
All strings are not unicode by default (but fixed in Python 3).
def foo(a, L = []):
L.append(a)
print L
>>> foo(1)
[1]
>>> foo(2)
[1, 2]
It's usually the result of some subtle bugs. I think it would be better if it created a new list
object whenever a default argument was required (rather than creating a single object to use for every
function call).
Edit: It's not a huge problem, but when something needs to be referred in the docs, it commonly means
it's a problem. This shouldn't be required.
def foo(a, L = None):
if L is None:
L = []
...
Especially when that should have been the default. It's just a strange behavior that doesn't match
what you would expect and isn't useful for a large number of circumstances.
Patrick
Collins
,
I see lots of complaints about this, but why does people insist having an empty list (that
the function modifies) as a default argument? Is this really such a big problem? I.e., is
this a
real
problem?
–
Martin
Vilcans
Jul
25 '11 at 21:22
3 revs
, 2011-07-15 03:15:50
Some of Python's features that make it so flexible as a development language are also seen as major
drawbacks by those used to the "whole program" static analysis conducted by the compilation and
linking process in languages such as C++ and Java.
Implicit declaration of local variables
Local variables are declared using the ordinary assignment statement. This means that variable
bindings in any other scope require explicit annotation to be picked up by the compiler (global and
nonlocal declarations for outer scopes, attribute access notation for instance scopes). This massively
reduces the amount of boilerplate needed when programming, but means that third party static analysis
tools (such as pyflakes) are needed to perform checks that are handled by the compiler in languages
that require explicit variable declarations.
"Monkey patching" is supported
The contents of modules, class objects and even the builtin namespace can be modified at runtime. This
is hugely powerful, allowing many extremely useful techniques. However, this flexibility means that
Python does not offer some features common to statically typed OO languages. Most notably, the "self"
parameter to instance methods is explicit rather than implicit (since "methods" don't have to be
defined inside a class, they can be added later by modifying the class, meaning that it isn't
particularly practical to pass the instance reference implicitly) and attribute access controls can't
readily be enforced based on whether or not code is "inside" or "outside" the class (as that
distinction only exists while the class definition is being executed).
Far from the metal
This is also true of many other high level languages, but Python tends to abstract away most hardware
details. Systems programming languages like C and C++ are still far better suited to handling direct
hardware access (however, Python will quite happily talk to those either via CPython extension modules
or, more portably, via the
ctypes
library).
Using indentation for code blocks instead of {} / begin-end, whatever.
Every newer modern language has proper lexical scoping, but not Python (see below).
Chaotic docs (compare with Perl5 documentation, which is superb).
Strait-jacket (there's only one way to do it).
Example for broken scoping; transcript from interpreter session:
>>> x=0
>>> def f():
... x+=3
... print x
...
>>> f()
Traceback (most recent call last):
File "", line 1, in ?
File "", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment
global
and
nonlocal
keywords
have been introduced to patch this design stupidity.
This is particularly bad because a large number of the functions (rather than methods) are just dumped
into the
global
namespace
: methods relating to lists, strings, numbers, constructors, metaprogramming, all mixed
up in one big alphabetically-sorted list.
At the very least, functional languages like F# have all the functions properly namespaced in modules:
List.map(x)
List.reversed(x)
List.any(x)
So they aren't all together. Furthermore, this is a standard followed throughout the library, so at
least it's consistent.
I understand the reasons for doing the
function
vs
method
thing,
but i still think it's a bad idea to mix them up like this. I would be much happier if the
method-syntax was followed, at least for the common operations:
Whether the methods are mutating or not, having them as methods on the object has several advantages:
Single place to look up the "common" operations on a data-type: other libraries/etc. may have other
fancy things they can do to the datatypes but the "default" operations are all in the object's
methods.
No need to keep repeating the
Module
when
calling
Module.method(x)
.
Taking the functional List example above, why do i have to keep saying
List
over
and over? It should know that it's a
List
and
I don't want to call the
Navigation.map()
function
on it! Using the
x.map()
syntax
keeps it DRY and still unambiguous.
And of course it has advantages over the
put-everything-in-global-namespace
way
of doing it. It's not that the current way is
incapable
of
getting things done. It's even pretty terse (
len(lst)
),
since nothing is namespaced! I understand the advantages in using functions (default behavior, etc.)
over methods, but I still don't like it.
It's just messy. And in big projects, messiness is your worst enemy.
Wayne
Werner
,
yeah... I really miss LINQ style (I'm sure LINQ isn't the first to implement it, but I'm most
familiar with it) list handling.
–
CookieOfFortune
Sep
8 '12 at 15:38
Python had to wait for 3.x to add a "with" keyword. In any homoiconic language it could have trivially
been added in a library.
Most other issues I've seen in the answers are of one of 3 types:
1) Things that can be fixed with tooling (e.g. pyflakes) 2) Implementation details (GIL, performance)
3) Things that can be fixed with coding standards (i.e. features people wish weren't there)
#2 isn't a problem with the language, IMO #1 and #3 aren't serious problems.
dbr
,
with
was available from Python 2.5 with
from
__future__ import with_statement
, but I agree, I've occasionally found it unfortunate
that statements like
if
/
for
/
print
/etc
are "special" instead of regular functions
–
dbr
Sep
9 '12 at 22:03
Martin Vilcans
, 2011-07-25 22:21:42
Python is my favourite language as it is very expressive, but still keeps you from making too many
mistakes. I still have a few things that annoy me:
No real anonymous functions. Lambda can be used for single-statement functions, and the
with
statement
can be used for many things where you'd use a code block in Ruby. But in some situations it makes
things a bit more clumsy than they would have to be. (Far from as clumsy as it would be in Java,
but still...)
Some confusion in the relation between modules and files. Running "python foo.py" from the command
line is different from "import foo". Relative imports in Python 2.x can also cause problems. Still,
Python's modules is so much better than the corresponding features of C, C++ and Ruby.
Explicit
self
.
Even though I understand some of the reasons for it, and even though I use Python daily, I tend to
make the mistake of forgetting it. Another issue with it is that it becomes a bit tedious to make a
class out of a module. Explicit self is related to the limited scoping that others have complained
about. The smallest scope in Python is the function scope. If you keep your functions small, as you
should, that isn't a problem by itself and IMO often gives cleaner code.
Some global functions, such as
len
,
that you'd expect to be a method (which it actually is behind the scenes).
Significant indentation. Not the idea itself, which I think is great, but since this is the single
thing that keeps so many people from trying Python, perhaps Python would be better off with some
(optional) begin/end symbols. Ignoring those people, I could totally live with an enforced size for
the indentation too.
That it is not the built-in language of web browsers, instead of JavaScript.
Of these complaints, it's only the very first one that I care enough about that I think it should be
added to the language. The other ones are rather minor, except for the last one, which would be great
if it happened!
Zoran
Pavlovic
,
+1 It makes me wonder whether to write
datetime.datetime.now()
when
one project could write
datetime.now
and
then mixing two projects one way of writing it rules out the other and surely this wouldn't
have happened in Java which wouldn't name a module the same as a file(?) if you see how the
common way seems to have the module confusing us with the file when both uses are practiced
and explicit
self
I
still try to understand since the calls don't have the same number of arguments as the
functions. And you might thinkn that the VM python has is slow?
–
Niklas
R.
Sep
1 '11 at 16:19
5 revs
, 2013-05-23 22:03:02
Python is not fully mature: the python 3.2 language at this moment in time has compatibility problems
with most of the packages currently distributed (typically they are compatible with python 2.5). This
is a big drawback which currently requires more development effort (find the package needed; verify
compatibility; weigh choosing a not-as-good package which may be more compatible; take the best
version, update it to 3.2 which could take days; then begin doing something useful).
Likely in mid-2012 this will be less of a drawback.
Note that I guess I got downvoted by a fan-boy. During a developer discussion our high level developer
team reached the same conclusion though.
Maturity in one main sense means a team can use the technology and be very quickly up & running
without hidden risks (including compatibility problems). 3rd party python packages and many apps do
not work under 3.2 for the majority of the packages today. This creates more work of integration,
testing, reimplementing the technology itself instead of solving the problem at hand == less mature
technology.
Update for June 2013: Python 3 still has maturity problems. Every so often a team member will mention
a package needed then say "except it is only for 2.6" (in some of these cases I've implemented a
workaround via localhost socket to use the 2.6-only package with 2.6, and the rest of our tools stay
with 3.2). Not even MoinMoin, the pure-python wiki, is written in Python 3.
Jonathan
Cline IEEE
,
I agree with you only if your definition of maturity is
not
compatible with a version that is incompatible by design
.
–
tshepang
Jul
17 '11 at 7:25
Mason Wheeler
, 2010-10-28 22:35:52
Python's scoping is badly broken, which makes object-oriented programming in Python very awkward.
Access modifiers in Python are not enforcable - makes it difficult to write well structured,
modularized code.
I suppose that's part of @Mason's broken scoping - a big problem in general with this language. For
code that's supposed to be readable, it seems quite difficult to figure what can and should be in
scope and what a value will be at any given point in time - I'm currently thinking of moving on from
the Python language because of these drawbacks.
Just because "we're all consenting adults" doesn't mean that we don't make mistakes and don't work
better within a strong structure, especially when working on complex projects - indentation and
meaningless underscores don't seem to be sufficient.
ncoghlan
,
So lack of access controls is bad... but explicit scoping of variable writes to any non-local
namespace is also bad?
–
ncoghlan
Jul
13 '11 at 3:25
dan_waterworth
, 2010-12-26 13:05:49
The performance is not good, but is improving with pypy,
The GIL prevents the use of threading to speed up code, (although this is usually a premature
optimization),
It's only useful for application programming,
But it has some great redeeming features:
It's perfect for RAD,
It's easy to interface with C (and for C to embed a python interpreter),
It's very readable,
It's easy to learn,
It's well documented,
Batteries really are included, it's standard library is huge and pypi contains modules for
practically everything,
It has a healthy community.
dan_waterworth
,
What inspired to mention the advantages? The question for the problems. Anyways, what you
mean it's useful only for application programming? What other programming is there? What
specifically is it not good for?
–
tshepang
Dec
30 '10 at 13:27
Niklas R.
, 2011-07-23 07:31:38
I do favor python and the first disadvantage that comes to my mind is when commenting out a statement
like
if
myTest():
then you must change the indentation of the whole executed block which you wouldn't
have to do with C or Java. In fact in python instead of commenting out an if-clause instead I've
started to comment it out this way: `if True:#myTest() so I won't also have to change the following
code block. Since Java and C don't rely on indentation it makes commenting out statements easier with
C and Java.
Christopher
Mahan
,
You would seriously edit C or Java code to change the block level of some code without
changing its indentation?
–
Ben
Jul
24 '11 at 6:35
Jed
, 2012-09-08 13:49:04
Multiple dispatch does not integrate well with the established single-dispatch type system and is not
very performant.
Dynamic loading is a massive problem on parallel file systems where POSIX-like semantics lead to
catastrophic slow-downs for metadata-intensive operations. I have colleagues that have burned a
quarter million core-hours just getting Python (with numpy, mpi4py, petsc4py, and other extension
modules) loaded on 65k cores. (The simulation delivered a significant new science results, so it was
worth it, but it is a problem when more than a barrel of oil is burned to load Python once.) Inability
to link statically has forced us to go to great contortions to get reasonable load times at scale,
including patching libc-rtld to make
dlopen
perform
collective file system access.
Jed
,
Wow, seems highly technical, do you have any reference material, examples, blog posts or
articles on the subject ? I wonder if I might be exposed to such cases in a near future.
–
vincent
Sep
8 '12 at 20:00
vincent
, 2012-09-08 16:03:54
quite a bunch of very mainstream 3rd party libraries and software that are widely used, are quite
not pythonic. A few examples : soaplib, openerp, reportlab. Critique is out-of-scope, it's there,
it's widely used, but it makes the python culture confusing ( it hurts the motto that says " There
should be one-- and preferably only one --obvious way to do it "). Known pythonic successes ( such
as django or trac ) seem to be the exception.
the potentially unlimited depth of abstraction of instance, class, metaclass is conceptually
beautiful and unique. But to master it you have to deeply know the interpreter ( in which order
python code is interpreted, etc. ). It's not widely known and used ( or used correctly ), while
similar black magic such as C# generics, that is conceptually more convoluted ( IMHO ) seems more
widely known and used, proportionally.
to get a good grasp of memory and threading model, you have to be quite experienced with python,
because there's no comprehensive spec. You just know what works, maybe because you read the
interpreter's sources or experienced quirks and discovered how to fix them. For instance, there are
only strong or weak references, not the soft and phantom refs of java. Java has a thread for
garbage collection while there is no formal answer about when garbage collection happens in python
; you can just observe that garbage collection doesn't happen if no python code is executed, and
conclude it's probably happening sometimes when trying to allocate memory. Can be tricky when you
don't know why a locked resource wasn't released ( my experience about that was mod_python in
freeswitch ).
Anyhow, python is my main language for 4 years now. Being fanboys, elitists or monomaniacs is not a
part of the python culture.
Andrew
Janke
,
+1. Spec for memory and threading model is right on. But FWIW, the Java garbage collector
being on a thread (and most everything else about the GC) is not an aspect of the Java
language or VM specifications per se, but is a matter of a particular JVM's implementation.
However, the main Sun/Oracle JVM is extensively documented wrt GC behavior and
configurability, to the extent that there are whole books published on JVM tuning. In theory
one could document CPython in the same way, regardless of language spec.
–
Andrew
Janke
Nov
26 '12 at 3:44
deamon
, 2012-09-10 12:59:24
Strange OOP:
len(s)
through
__len__(self)
and
other "special methods"
extra special methods which could be derived from other special methods (
__add__
and
__iadd__
for
+
and
+=
)
self
as first method parameter
you can forget to call base class constructor
no access modifiers (private, protected ...)
no constant definitions
no immutability for custom types
GIL
poor performance which leads to a mix of Python and C and troubles with builds (looking for C libs,
platform dependencies ...)
bad documentation, especially in third party libs
incompatibility between Python 2.x and 3.x
poor code analysis tools (compared to what is offered for statically typed languages such as Java
or C#)
Konrad
Rudolph
,
Personally I think that incompatibility between between 2.x and 3.x is one of Python's
biggest advantages. Sure, it
also
is
a disadvantage. But the audacity of the developers to break backwards compatibility also
means that they didn't have to carry cruft around endlessly. More languages need such an
overhaul.
–
Konrad
Rudolph
Sep
10 '12 at 13:39
Kosta
, 2012-09-08 15:04:10
"Immutability" is not exactly it's strong point. AFAIK numbers, tuples and strings are immutable,
everything else (i.e. objects) is mutable. Compare that to functional languages like Erlang or Haskell
where everything is immutable (by default, at least).
However, Immutability really really shines with concurrency*, which is also not Python's strong point,
so at least it's consequent.
(*= For the nitpickers: I mean concurrency which is at least partially parallel. I guess Python is ok
with "single-threaded" concurrency, in which immutability is not as important. (Yes, FP-lovers, I know
that immutability is great even without concurrency.))
I'd love to have explicitly parallel constructs. More often than not, when I write a list
comprehension like
[ f(x) for x in lots_of_sx ]
I don't care the order in which the elements will be processed. Sometimes, I don't even care in which
order they are returned.
Even if CPython can't do it well when my f is pure Python, behavior like this could be defined for
other implementations to use.
Zoran
Pavlovic
,
//spawn bunch of threads //pass Queue que to all threads que.extend([x for x in lots_of_sx])
que.wait() # Wait for all lots_of_sx to be processed by threads.
–
Zoran
Pavlovic
Jan
7 '13 at 7:02
2 revs, 2 users 80%
, 2012-10-07 15:16:37
Python has no tail-call optimization, mostly for
philosophical
reasons
. This means that tail-recursing on large structures can cost O(n) memory (because of the
unnecessary stack that is kept) and will require you to rewrite the recursion as a loop to get O(1)
memory.
Joshua Day ,
Currently developing reporting and testing tools for linux
Updated Apr 26 · Author has 83 answers and 71k answer views
There are several reasons and ill try to name a few.
Perl syntax and semantics closely resembles shell languages that are part of core Unix
systems like sed, awk, and bash. Of these languages at least bash knowledge is required to
administer a Unix system anyway.
Perl was designed to replace or improve the shell languages in Unix/linux by combining
all their best features into a single language whereby an administrator can write a complex
script with a single language instead of 3 languages. It was essentially designed for
Unix/linux system administration.
Perl regular expressions (text manipulation) were modeled off of sed and then drastically
improved upon to the extent that subsequent languages like python have borrowed the syntax
because of just how powerful it is. This is infinitely powerful on a unix system because the
entire OS is controlled using textual data and files. No other language ever devised has
implemented regular expressions as gracefully as perl and that includes the beloved python.
Only in perl is regex integrated with such natural syntax.
Perl typically comes preinstalled on Unix and linux systems and is practically considered
part of the collection of softwares that define such a system.
Thousands of apps written for Unix and linux utilize the unique properties of this
language to accomplish any number of tasks. A Unix/linux sysadmin must be somewhat familiar
with perl to be effective at all. To remove the language would take considerable effort for
most systems to the extent that it's not practical.. Therefore with regard to this
environment Perl will remain for years to come.
Perl's module archive called CPAN already contains a massive quantity of modules geared
directly for unix systems. If you use Perl for your administration tasks you can capitalize
on these modules. These are not newly written and untested modules. These libraries have been
controlling Unix systems for 20 years reliably and the pinnacle of stability in Unix systems
running across the world.
Perl is particularly good at glueing other software together. It can take the output of
one application and manipulate it into a format that is easily consumable by another, mostly
due to its simplistic text manipulation syntax. This has made Perl the number 1 glue language
in the world. There are millions of softwares around the world that are talking to each other
even though they were not designed to do so. This is in large part because of Perl. This
particular niche will probably decline as standardization of interchange formats and APIs
improves but it will never go away.
I hope this helps you understand why perl is so prominent for Unix administrators. These
features may not seem so obviously valuable on windows systems and the like. However on Unix
systems this language comes alive like no other.
Posted by EditorDavid
on Saturday September 08, 2018 @03:34PM
from the
newer-kid-on-the-block
dept.
InfoWorld described the move as a "breakthrough":
As expected, Python has climbed into the Top 3 of the
Tiobe index of language popularity,
achieving that milestone for the first time
ever in the September 2018 edition of the index. With a rating
of 7.653 percent,
Python placed third
behind first-place Java,
which had a rating of 17.436 percent, and second-place C, rated at 15.447. Python displaced C++, which finished
third last month and took fourth place this month, with a rating of 7.394 percent...
Python also has been scoring high in two other language rankings:
- The PyPL Popularity of Programming Language index,
where it ranked
No. 1 this month
, as it has done before, and has had the most growth in the past five years.
- The RedMonk Programming Language Rankings,
where Python again placed third
.
Tiobe notes that Python's arrival in the top 3 "really took a long time," since it first entered their chart at
the beginning of the 1990s. But today, "It is already the first choice at universities (for all kinds of
subjects for which programming is demanded) and is now also conquering the industrial world." In February Tiobe
also added a new programming language to their index: SQL. (Since "SQL appears to be Turing complete.")
Never mind Python 2 vs 3; one major reason I shy away from Python is the incompatibility in
point releases. I'd see "requires Python 2.6â and see that I have Python 2.7 so it should be
fine, right? Nope, code written for 2.6 won't run under Python 2.7. It needs to be EXACTLY
2.6.
It's at this point that some Python fanboi gets really upset and starts screaming
about how that's now problem, with Python you set up separate virtual environments for each
script, so that each one can have exactly the version of Python it is written for, with
exactly the version of each library. When there is some bug or security issue you then hope
that there is a patch for each, and deal with all that. (As opposed to every other peice of
software in the world, which you simply upgrade to the latest version to get all the latest
fixes). Yes, you CAN deal with that problem, it's possible, in most cases. You shouldn't
have to. Every other language does some simple things to maintain backward compatibility in
point releases (and mostly in major releases too).
Also the fact that most languages use every day and have used for decades use braces for
blocks means my eyes and mind are very much trained for that. Braces aren't necessarily
BETTER than just using indentation, but it's kinda like building a car which uses the pedals
to steer and a hand stick for the gas. It's not necessarily inherently better or worse, but
it would be almost undriveable for an experienced driver with decades of muscle memory in
normal cars. Python's seemingly random choices on these things make it feel like using your
feet to steer a car. There should be compelling reasons before you break long-established
conventions and Python seems to prefer to break conventions just to be different. It seems
the Python team is a bit like Berstein in that way. It's really annoying.
Yeah, just FYI Python 2.7 is in a way its own thing. Different from the 2.x and
different from the 3.x series. 2.6 is a no holds barred pure 2.x whereas 2.7 is a mixture
of 2.x and 3.x features. So if you want to compare point releases, best to try that with
the 3.x series. Also, if you're using something that requires the 2.x series, you
shouldn't use that unless it is absolutely critical with zero replacements.
You shouldn't have to. Every other language does some simple things to maintain
backward compatibility in point releases (and mostly in major releases too).
Again see argument about 3.x, but yeah not every language does this. Java 8/9
transition breaks things. ASP.Net to ASP.Net core breaks things along the way. I'm
interested in what languages you have in mind, because I know quite a few languages that
do maintain backwards compatibility (ish). For example, C++ pre and post namespace breaks
fstreams in programs, but compilers provide flags to override that, so it depends on what
you mean by breaking. Does it count if the compiler by default breaks, but providing
flags fixes it? Because if your definition means including flags break compatibility,
then oooh boy are there a a shit ton of broken languages.
Also the fact that most languages use every day and have used for decades use braces
for blocks means my eyes and mind are very much trained for that
Yeah, it's clear that you've never used a positional programming language. I guess
it'll be a sign of my age, but buddy, program COBOL or RPG on punch cards and let me know
about that curly brace issue you're having. Positional and indentation has been used way,
way, way, longer than curly braces. That's not me knocking on the curly braces, I love my
C/C++ folks out there! But I hate to tell you C and C-style is pretty recent in the
timeline of all things computer.
> C++ pre and post namespace breaks fstreams in programs, but compilers provide flags
to override that, so it depends on what you mean by breaking. Does it count if the
compiler by default breaks, but providing flags fixes it?
If it results in weird
runtime errors, that's definitely a problem.
If the compiler I'm using gives the message "incompatible use of fstream, try
'-fstreamcompat' flag", that's no big deal.
On a similar note, if something is marked deprecated long before it's removed, that
matters. Five years of compiler/interpreter warnings saying "deprecated use of
function in null context on line #47" gives plenty of opportunity. To fix it. From
the bit of Python I've worked with, the recommended method on Friday completely
stops working on Monday.
That's plainly not true - Python follows the established
deprecate-first-remove-next cycle. This is readily obvious when you look at the
changelogs. For example, from the 2.6 changelog:
The threading module API is being changed to use properties such as daemon
instead of setDaemon() and isDaemon() methods, and some methods have been
renamed to use underscores instead of camel-case; for example, the
activeCount() method is renamed to active_count(). Both the 2.6 and 3.0
versions of the module support the same properties and renamed methods, but
don't remove the old methods. No date has been set for the deprecation of the
old APIs in Python 3.x; the old APIs won't be removed in any 2.x version.
For another example, the ability to throw strings (rather than
BaseException-derived objects) was deprecated in 2.3 (2003) and finally removed
in 2.6 (2008).
For comparison, in the C++ land, dynamic exception specifications were
deprecated in C++11, and removed in C++17. So the time scale is comparable.
That's great that they deprecate something on some occasions.
MY experience with the Python I run is that one version gives no warning,
going up one point release throws multiple fatal errors.
> This is readily
obvious when you look at the changelogs
Maybe that's the thing - one has read the changelogs to see what is
deprecated, as opposed to getting a clear deprecation warning from the
interpreter/compiler like you would with C, Perl, and other languages?
It's possible that a Python expert might be able to
MY experience with the Python I run is that one version gives no
warning, going up one point release throws multiple fatal errors.
Can you give an example? I'm just not aware of any, and it makes me
suspect that what you were running into was an issue in a third-party
library (some of which do indeed have a cowboy attitude towards breaking
changes - but that's common across all languages).
Maybe that's the thing - one has read the changelogs to see what is
deprecated, as opposed to getting a clear deprecation warning from the
interpreter/compiler like you would with C, Perl, and other languages?
And I have never, ever seen a deprecation warning in C or C++. You have
to read the change sections for new standards to see what was deprecated
or removed.
> And I have never, ever seen a deprecation warning in C or C++. You
have to read the change sections for new standards to see what was
deprecated or removed.
The default with gcc is to warn about
deprecation.
You can turn the warnings off by setting the CFLAGS environment
variable to include -Wno-deprecated, which you can do in your
.bashrc oe wherever. What's most often recommended is -Wall to
show all warnings of all types.
For example, C++ pre and post namespace breaks fstreams in programs, but compilers
provide flags to override that
Dude, that was in 1990, back before there even was a standard C++. And I very much
doubt those flags still exist today.
program COBOL or RPG on punch cards and let me know about that curly brace issue
you're having
You seem to have forgotten how that really worked in your old age though. Punch
cards had columns with specific functions assigned to them, so yes, of course you
would have to skip certain columns on occasion. That was not indentation, though. You
didn't have indentation; moving your holes by one position or one column meant the
machine would interpret your instruction as something else ent
Static typing isn't just about clarity to the programmer. In strict typing languages, the
rule is to use the type that matches the range that actually applies. This is to help
testing (something coders should not ignore), automated validation, compilation (a compiler
can choose sensible values, optimise the code, etc etc etc) and maintainers (a clear
variable name won't tell anyone if a variable's range can be extended without impacting the
compiled code).
Besides, I've looked at Python code. I'm not convinc
Type annotations and docstrings help with the whole lack of type declaration thing. Of
course that requires discipline, which is in short supply from my experience. If you can
force your developers to run pylint that will at least complain when they don't have
docstrings.
The list is compiled from a restricted pool and lists popularity.
That may mean a vendor
throwing out ten individually packaged Python scripts counts as ten sources with one C
program of equalling counts as one. If that's the case, Python would be ten times as popular
in the stats whilst being equally popular in practice.
So if Python needed ten times as many modules to be as versatile, it would seem popular
whilst only being frustrating.
The fact is, we don't know their methodology. We don't know if they're weighting results
in any way to factor in workarounds and hacks due to language deficiency that might show up
as extra use.
We do know they don't factor in defect density, complexity or anything else like that as
they do say that much. So are ten published attempts at a working program worth ten times
one attempt in a language that makes it easy first time? We will never know.
I find java in an uncanny valley. Its still a few times slower than c++ for the sort of
stuff I do but it isn't enough quicker to develop than c++ to be worth that hit. Python is
far slower than java even using numpy but its so easy to develop in that it is worth the
gamble that it will be fast enough. And the rewrite in c++ will go quickly even if it isn't.
The title is because VBA is 11x faster than numpy at small dense matricies and almost as
easy to develop in.
Java is useful because you can throw a team of lowskill developers at it and they won't
mess things up beyond the point of unmaintanability. It will be a pain to maintain, sure,
but the same developers using C would make memory errors that push things beyond
hopeless, and if they were using Python or JavaScript the types would become more and
more jumbled as the size of the program increases that no one would be able to understand
it and things would start breaking more and more. Java enforces a minimal lev
Tiobe notes that Python's arrival in the top 3 "really took a long time," since it first
entered their chart at the beginning of the 1990s. But today, "It is already the first
choice at universities (for all kinds of subjects for which programming is demanded)
Undergraduate was all C/C++ for me then I ended up at a graduate school where everything was
Java. I disliked it so much that I decided to find an alternative and teach myself. I found
Python and loved it. I still love it. You can't find anything better for both heavy duty
programming and quick and dirty scripting. It's versatility makes It like the Linux of
programming languages.
I found Python and loved it. I still love it. You can't find anything better for both
heavy duty programming...
What? Python is hopelessly inefficient for heavy duty programming, unless you happen to
be doing something that is mainly handled by a Python library, written in C. Python's
interface to C disgusting, so if you have a lot of small operations handled by a C library,
you will get pathetic performance.
It really isn't. There are some apps that actually need something faster and a lot of
apps that don't. It really doesn't help if a faster executable ends up waiting for I./O.
It really is
[debian.net] and you blathering about what you don't know does not
change that fact. (Python 14 minutes vs C++ 8..24 seconds for N-Body simulation.)
Well, since 99.99999999999% of all software run by literally everybody is an n-body
simulation....
That would be an example of the "some apps" I spoke of. I note
that Intel Fortran was at the top of the list (not surprising). Would ifort be your
first choice if you were writing a text editor or a tar file splitter? How about an
smtp daemon?
Well, since 99.99999999999% of all software run by literally everybody is an
n-body simulation..
Explaining the concept of "compute intensive" to you makes me feel more
stupid. Check out
any
of the compute intensive Python benchmarks.
Consider not waving your ignorance around quite so much.
Having actually built a cluster that was in the top 500 for a while, I am
well acquainted with compute intensive applications. I am also aware that
compute intensive is a subset of "heavy duty" programming which is a subset
of general programming.
Now, pull your head out of your ass and look
around, you might learn something. And while you're at it, consider working
on your social skills.
Either you understand that Python is crap for compute intensive work, or
you are lying about building a cluster. Or you just connected the cables,
more like it, and really don't have a clue about how to use it.
I do understand that python isn't the right choice for compute
intensive work. With the exception that if it is great for doing setup
for something in FORTRAN or C that does the heavy lifting.
I am
certain that YOU don't understand that compute intensive work is a
small fraction of what is done on computers. For example, I/O intensive
work doesn't really care if it is Python or FORTRAN that is waiting for
I/O to complete. There is a reason people don't drive a top fuel
dragster to work.
I am certain that YOU don't understand that compute intensive
work is a small fraction of what is done on computers.
First, you have no idea what I do or do not understand because
you find yourself way too entertained by your own blather, and
second, computers are used more for browsing than any other single
task these days, and wasteful use of the CPU translates into
perceptible lag. Playing media is very CPU intensive. You don't
write those things in Python because Python sucks for efficiency. My
point.
Yes, I had you figured, you're a sysadmin with delusions about
being a dev. Seen way too many of those. They tend to ta
As I said, "Python is hopelessly inefficient for heavy duty
programming". WTF are you blathering on about. Fresh air is good for
you, maybe get out of your basement more.
It really is
[debian.net] and you blathering about what you don't know does
not change that fact. (Python 14 minutes vs C++ 8..24 seconds for N-Body
simulation.)
I've just run it on my machine. C++: 2.3 seconds, Python: 22 seconds. That's for
straightforward mathy Python against C++ code with vector instrinsics. Concerning
C++ code without manual vectorization, it's 4 seconds against 22. Not terribly bad,
I'd say. Not to mention that this isn't the kind of code that would be typical for
a larger application.
The first python program I wrote was a test for a job interview.
It involved downloading meteorologic data from the internet.
Analyzing it, creating a kind of summary and using a graph plotting library
to display a graph (generate a *.png)
It would not have been noticeable
faster if I had written it in C++, because
... you know:
downloading via a network.
Then you looked at it without understanding it. Do you seriously
think you can out-optimize gcc's code generator? Do you even know
how to use LEA for arithmetic?
Is there a programming language out there, that is as fast as C++ or even C, has a proper
strict type system (no duck typing, nothing like Python or JS), fast garbage collection (no
fuckin' auto_pointer worst-of-both-worlds), is elegant and emergent (so very powerful for its
simplicity), and doesn't require an advanced degree in computer sciences to do simple things
(Hello Haskell!).
Of course with key libraries being available for it. (The equivalent of a standard library,
Vulcan, a simple GUI widget toolki
I really like the Qt framework. It's well done, well documented and well supported. Sure
it's C++ so it doesn't meet your need of finding a new language but the API is pretty clean
and simple so that you can avoid the complications and ugliness of C++ in most cases. If you
need to though, it's all right there so you don't give up the additional power if you need
it. The Python version is good too and very similar to the C++ version so it's not hard to
switch between languages as your needs change.
Is there a programming language out there, that is as fast as C++ or even C, has a
proper strict type system (no duck typing, nothing like Python or JS), fast garbage
collection
No.
Neither will there be. There's always a penalty for garbage collection.
Is there a programming language out there, that is as fast as C++ or even C, has a
proper strict type system (no duck typing, nothing like Python or JS), fast garbage
collection
No.
Neither will there be. There's always a penalty for garbage collection.
I think go is the closest to your requested feature list.
I think go is the closest to your requested feature list.
The GP, not mine.
And yuck, no thanks. Go just seems, well, deeply mediocre in many places. It's like
someone pdated C, ignoreing the last 40 years of language developments.
Sure I can program without generics, I'm at a loss to see why I'd want to though.
Its performance is good enough that I'm able
to drop C++ (I'm a mathematical modeller), it's amazing at multidimensional array
manipulation, and its typing system is really good. It just feels nice to program in. Bonus,
one of the inspirations was Lisp, so it's got good metaprogramming. Also it's free software,
made by people at MIT, so your conscience can remain appeased.
It's still a young language, but libraries are being built for it at an impressive rate,
and i
That advocated a language. Languages shift faster than sand on speed. Universities should teach
logic, reasoning, methodology, good practices and programming technique.
Languages should be
for the purpose of example only. Universities should teach programming, not Java, software
engineering, not Python. Java and Python should be in there, yes, along with Perl, C and Ada.
Syntax is just sugar over the semantics. Learn the semantics well and the syntax is irrelevant.
You want universities to teach kids how to
when Cobol and Fortran were the in thing. Last forever, they thought.
Any evidence most universities believed that? (They are still around and relatively
common, by the way.)
Universities have to pick something to program lesson projects in, and selecting
language(s) common in the current market helps student job prospects. I suggest STEM
students be required to learn at least one compiled/strong-typed language, and one
script/dynamic language.
My university (Manchester University, UK) certainly didn't pick a language.
We studied
many languages, compiler design, formal semantics and a boatload of other computer
science things but at no point did they try to teach me a programming language. In fact
at induction they said explicitly that they expected us all to know how to program before
we arrived.
(note: this is a UK perspective, other places may vary)
Universities have to work
with the students they can get.
I think you and your co-students were lucky to catch the height of the 80s
microcomputer boom, the time when computers booted into BASIC, when using a computer
pretty much meant programming it.
Then the windows PCs with their pre-canned applications and no obvious programming
language swept in. Leaning to program now meant not just finding a suitible book, it
often meant buying the programming lang
Didn't you have projects that involved turning in your code to the teacher/graders?
The graders don't want to see every which language. Multi-lingual graders are more
expensive. Most colleges dictate a narrow set of languages for such projects.
Didn't you have projects that involved turning in your code to the
teacher/graders? The graders don't want to see every which language.
Multi-lingual graders are more expensive. Most colleges dictate a narrow set of
languages for such projects.
Yes, but it was hardly narrow. We had homework to hand in using a variety of
languages, depending on the course. Pascal tended to be used for general algorithm
stuff. But Smalltalk, Prolog, ML and other usual suspects were used when they made
sense for the course. You were supposed to leave with a CompSci degree where you
understood the theory of languages more than the details of specific languages.
Usually, for project work, you were free to choose your language and would be
expected to justify the reason
Tablizer
( 95088 )
writes:
That's a pretty big jump. Groovy is a well-thought-out language and nicely facilitates
writing clean, readable, compact code (especially compared to Java). However, it needs a better
framework than Grails (85% really good convention over configuration stuff but 15% convoluted
j2ee era framework stuff).
Can someone explain to me why using a dynamically typed language is a good idea for "big"
applications ?
Python is subject to all sorts of really horrendous bugs that would not happen
in a compiled, type-checked language.
For example if you are accessing an undefined variable in the else branch of an if
statement, you won't know it's undefined unless that branch is taken. which means if it's
something like a rarely occurring error condition it's kind of annoying. yes you can figure it
out by writing enough t
It's really simple, Writing an application in Python is x3 quicker than writing it in
C/C++/Java, etc... That means you either get to market 3x faster or only need 1/3 the number
of programmers. Everything else is completely and utterly irrelevant. "you won't know it's
undefined unless that branch is taken" The code linter built into your Python IDE, will tell
you about it.
Hogwash. Even if x3 were true, Dev is roughly 20-40% of overall software cost. Unless
you're arguing that every aspect of coding is reliably 3x faster in Python. Given the
value of strong typing when refactoring, I'd wager python is not even competitive price
wise past the proof of concept/one-off script scenario.
I'm am arguing that because it's true. There isn't much benefit to strong typing when
refactoring but the benefits of duck typing when it comes to unit testing are quite
significant. I've done commercial software development in strong and weakly typed
languages before. The benefits of things like "strong typing" are generally not that
much. If you are on board with the whole agile bandwagon and writing unit tests and
all that. You would be much better off with Python's significally better unit testing
facilities than strong typing.
I'm at least in the caravan trailing the agile/unit-test bandwagon, but those are
orthogonal to typing (and being explicit generally). Looking at a method signature
and knowing that it requires a decimal and enumeration of a given type is more than
a run-time check; it provides information about the intent, limitations, and
discoverability options. There are very real trade-offs for the speed and
flexibility of a language like Python, and my view is that it's more jet-fuel than
solar power.
If you are using a good IDE "provides information about the intent, limitations,
and discoverability options" can all be found out with a couple of key strokes
(git blame, find all usages, pylint, etc..). So putting that information into
the language explicitly is an obsolete and backwards way of going about things
:p The job of the compiler in Python has just been redistributed
elsewhere. It's different but there are many ways to solve the same problems.
Six of one, half dozen of the other. The Python program will be smaller for the same
functionality and it won't have buffer overflows and memory leaks The C program will run
faster (unless it has to wait on I/O) and will check for variables used before assignment.
Using an undefined variable in Python triggers an exception, and you get a traceback. In a
larger program you will normally have a system for capturing and storing such tracebacks for
analysis, and with the traceback in hand, it's typically a very simple fix.
In C++ you get
an incorrect value created by default-initialisation (or maybe undefined behaviour): the
program hobbles along as best it can, and you may never find the problem. You just see your
program behaving strangely sometimes, and as the program gets larger, those strange
behaviours accumulate.
Python is subject to all sorts of really horrendous bugs that would not happen in a
compiled, type-checked language.
Horrendous is not the right word. Bugs that come with tracebacks are simple bugs. Zen#10:
"Errors should never pass silently" is exactly what you want in large-scale programming.
Writing big applications in Java/C++ takes too long. And then managements decide to avoid
'custom code' in favor of 'standard' vendor tools where you can drag and drop to build parts
of the 'big' application. This applies to ETL, reporting, messaging to name a few. With
Python, the development cycle shortens and you can still stick to writing code instead of
dealing with vendor binaries, lock-ins, licensing etc. Python with strong emphasis on unit
tests, coupled with plugging in C/C++ where necessary f
I think what has really propelled Python into a higher rank is machine learning, where it is
simply the de-facto language of choice by quite a margin.
I have to admit I am impressed with
the progress it has made; of many recent CS grads I've talked to it seemed to be the favorite
language...
I have to admit that over the years I've not really enjoyed Python much myself in the on and
off again times I've used it, for me the spaces as indent levels maybe get too close to the
meaningful whitespace of Fortran... I guess modern programmers do not have this hangup.
:-)
That's a great point, and to be honest that is probably a better language for learning
than Java... it would also explain why newer CS grads all like it more now.
The only
downside is that most jobs are still using Java or something besides python... but
probably it means we'll se more python used in businesses I guess. That usually ends up
following eventually.
I have been sporadically using Python for some years already and never really liked it. Note
that most of my experience is focused on C-based and strongly-typed programming languages.
Recently, I have been spending some time on a Python project and have realised about its
(newbie) friendliness.
I still don't quite understand the reason for all the tabs/spaces problems, consider it too
slow, don't like the systematic need of relying on external resources and I will certainly
continue using other languages before it. But I do understand now why newbies or those
performing relatively small developments or those wanting to rely on some of the associated
resources (although I don't like being systematically forced to include external dependencies,
I do recognise that Python deals with these aspects quite gracefully and that there are many
interesting libraries) might prefer Python. It is one of the most intuitive programming
languages which I have ever used, at least from what seems a newcomer perspective (e.g., same
command performing what are intuitively seen as similar actions).
I don't think this should be about lines of code written. A more interesting approach would be
to also count all dependencies, counting things like libc a gazillion times. Even more
interesting would be to count what's actually executed.
"Or any of the games in my library, which all appear to be C or C++, with a few C#."
From
what I've seen a lot of the core engine stuff is C/C++; but a lot of the UI, AI, and "mod
support" stuff is commonly done in Python and Lua.
Personally, I disagree with semantic whitespace so I don't like python. (I think its the
editors job to handle pretty formatting to reflect the structure, rather than the
programmers job to define structure with pretty formatting.) But I can see why python would
be a good learning l
I sort of see it as the opposite... semantic
whitespace teaches mostly good habits, its just fucking irritating to maintain, and to
work with snippets and code fragments etc.
But its highly readable, and pretty straightforward, and i don't see anything wrong
with it as a beginning/educational language; for teaching flow control, algorithms,
structured/modular programming, and so on.
Back in April 2010, Russ Cox charitably suggested that
only
fannkuch-redux, fasta, k-nucleotide, mandlebrot, nbody,
reverse-complement and spectral-norm were close to
fair
comparisons. As someone who implemented programming
languages, his interest was "measuring the quality of the generated code when both compilers are presented with what amounts
to the same program."
Differences in approach - to memory management, parallel programming, regex, arbitrary precision arithmetic,
implementation technique - don't fit in that kind-of
fair
comparison -- but we still have to deal with them.
These are only the fastest programs. There may be additional measurements for programs which seem more-like a
fair
comparison to you. Always look at the source code.
What happens when a
Benevolent Dictator For Life moves on from an open source project? up
2 comments Image credits : Original photo by Gabriel Kamener, Sown Together, Modified by
Jen Wike Huger x Subscribe now
Get the highlights in your inbox every week.
https://opensource.com/eloqua-embedded-email-capture-block.html?offer_id=70160000000QzXNAA0
Guido van Rossum ,
creator of the Python
programming language and Benevolent Dictator For Life
(BDFL) of the project, announced his intention to step away.
Below is a portion of his message, although the entire email is
not terribly long and worth taking the time to read if you're interested in the circumstances
leading to van Rossum's departure.
I would like to remove myself entirely from the decision process. I'll still be there for
a while as an ordinary core dev, and I'll still be available to mentor people -- possibly
more available. But I'm basically giving myself a permanent vacation from being BDFL, and you
all will be on your own.
After all that's eventually going to happen regardless -- there's still that bus lurking
around the corner, and I'm not getting younger... (I'll spare you the list of medical
issues.)
I am not going to appoint a successor.
So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A
federation?
It's worth zooming out for a moment to consider the issue at a larger scale. How an open
source project is governed can have very real consequences on the long-term sustainability of
its user and developer communities alike.
BDFLs tend to emerge from passion projects, where a single individual takes on a project
before growing a community around it. Projects emerging from companies or other large
organization often lack this role, as the distribution of authority is more formalized, or at
least more dispersed, from the start. Even then, it's not uncommon to need to figure out how to
transition from one form of project governance to another as the community grows and
expands.
But regardless of how an open source project is structured, ultimately, there needs to be
some mechanism for deciding how to make technical decisions. Someone, or some group, has to
decide which commits to accept, which to reject, and more broadly what direction the project is
going to take from a technical perspective.
Surely the Python project will be okay without van Rossum. The Python Software Foundation has plenty of formalized
structure in place bringing in broad representation from across the community. There's even
been a humorous April Fools Python Enhancement Proposal (PEP) addressing
the BDFL's retirement in the past.
That said, it's interesting that van Rossum did not heed the fifth lesson of Eric S. Raymond
from his essay, The Mail Must Get
Through (part of The
Cathedral & the Bazaar ) , which stipulates: "When you lose interest in a
program, your last duty to it is to hand it off to a competent successor." One could certainly
argue that letting the community pick its own leadership, though, is an equally-valid
choice.
What do you think? Are projects better or worse for being run by a BDFL? What can we expect
when a BDFL moves on? And can someone truly step away from their passion project after decades
of leading it? Will we still turn to them for the hard decisions, or can a community smoothly
transition to new leadership without the pitfalls of forks or lost participants?
Can you truly stop being a BDFL? Or is it a title you'll hold, at least informally, until
your death? TopicsCommunity management Python 2018 Open Source
Yearbook YearbookAbout the author Jason Baker - I use technology to make the world
more open. Linux desktop enthusiast. Map/geospatial nerd. Raspberry Pi tinkerer. Data analysis
and visualization geek. Occasional coder. Cloud nativist. Civic tech and open government
booster. More about
me
"So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A
federation?"
Power coalesced to one point is always scary when thought about in the context of
succession. A vacuum invites anarchy and I often think about this for when Linus Torvalds
leaves the picture. We really have no concrete answers for what is the best way forward but
my hope is towards a democratic process. But, as current history indicates, a democracy
untended by its citizens invites quite the nightmare and so too does this translate to the
keeping up of a project.
What happens when a Benevolent Dictator For Life moves on from an open source
project? 16 Jul 2018 Jason Baker (Red Hat) Feed 131 up
2 comments Image credits : Original photo by Gabriel Kamener, Sown Together, Modified by
Jen Wike Huger x Subscribe now
Get the highlights in your inbox every week.
https://opensource.com/eloqua-embedded-email-capture-block.html?offer_id=70160000000QzXNAA0
Guido van Rossum ,
creator of the Python
programming language and Benevolent Dictator For Life
(BDFL) of the project, announced his intention to step away.
Below is a portion of his message, although the entire email is
not terribly long and worth taking the time to read if you're interested in the circumstances
leading to van Rossum's departure.
I would like to remove myself entirely from the decision process. I'll still be there for
a while as an ordinary core dev, and I'll still be available to mentor people -- possibly
more available. But I'm basically giving myself a permanent vacation from being BDFL, and you
all will be on your own.
After all that's eventually going to happen regardless -- there's still that bus lurking
around the corner, and I'm not getting younger... (I'll spare you the list of medical
issues.)
I am not going to appoint a successor.
So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A
federation?
It's worth zooming out for a moment to consider the issue at a larger scale. How an open
source project is governed can have very real consequences on the long-term sustainability of
its user and developer communities alike.
BDFLs tend to emerge from passion projects, where a single individual takes on a project
before growing a community around it. Projects emerging from companies or other large
organization often lack this role, as the distribution of authority is more formalized, or at
least more dispersed, from the start. Even then, it's not uncommon to need to figure out how to
transition from one form of project governance to another as the community grows and
expands.
But regardless of how an open source project is structured, ultimately, there needs to be
some mechanism for deciding how to make technical decisions. Someone, or some group, has to
decide which commits to accept, which to reject, and more broadly what direction the project is
going to take from a technical perspective.
Surely the Python project will be okay without van Rossum. The Python Software Foundation has plenty of formalized
structure in place bringing in broad representation from across the community. There's even
been a humorous April Fools Python Enhancement Proposal (PEP) addressing
the BDFL's retirement in the past.
That said, it's interesting that van Rossum did not heed the fifth lesson of Eric S. Raymond
from his essay, The Mail Must Get
Through (part of The
Cathedral & the Bazaar ) , which stipulates: "When you lose interest in a
program, your last duty to it is to hand it off to a competent successor." One could certainly
argue that letting the community pick its own leadership, though, is an equally-valid
choice.
What do you think? Are projects better or worse for being run by a BDFL? What can we expect
when a BDFL moves on? And can someone truly step away from their passion project after decades
of leading it? Will we still turn to them for the hard decisions, or can a community smoothly
transition to new leadership without the pitfalls of forks or lost participants?
Can you truly stop being a BDFL? Or is it a title you'll hold, at least informally, until
your death? TopicsCommunity management Python 2018 Open Source
Yearbook YearbookAbout the author Jason Baker - I use technology to make the world
more open. Linux desktop enthusiast. Map/geospatial nerd. Raspberry Pi tinkerer. Data analysis
and visualization geek. Occasional coder. Cloud nativist. Civic tech and open government
booster. More about
me
"So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A
federation?"
Power coalesced to one point is always scary when thought about in the context of
succession. A vacuum invites anarchy and I often think about this for when Linus Torvalds
leaves the picture. We really have no concrete answers for what is the best way forward but
my hope is towards a democratic process. But, as current history indicates, a democracy
untended by its citizens invites quite the nightmare and so too does this translate to the
keeping up of a project.
Hey I've been using Linux for a while and thought it was time to finally dive into shell
scripting.
The problem is I've failed to find any significant advantage of using Bash over something
like Perl or Python. Are there any performance or power differences between the two? I'd
figure Python/Perl would be more well suited as far as power and efficiency goes.
Simplicity: direct access to all wonderful linux tools wc ,
ls , cat , grep , sed ... etc. Why
constantly use python's subprocess module?
I'm increasingly fond of using gnu parallel , with which you can
execute your bash scripts in parallel. E.g. from the man page, batch create thumbs of all
jpgs in directory in parallel:
ls *.jpg | parallel convert -geometry 120 {} thumb_{}
By the way, I usually have some python calls in my bash scripts (e.g. for plotting). Use
whatever is best for the task!
bash isn't a language so much as a command interpreter that's been hacked to death to allow
for things that make it look like a scripting language. It's great for the simplest 1-5 line
one-off tasks, but things that are dead simple in Perl or Python like array manipulation are
horribly ugly in bash. I also find that bash tends not to pass two critical rules of thumb:
The 6-month rule, which says you should be able to easily discern the purpose and basic
mechanics of a script you wrote but haven't looked at in 6 months.
The 'WTF per minute' rule. Everyone has their limit, and mine is pretty small. Once I
get to 3 WTFs/min, I'm looking elsewhere.
As for 'shelling out' in scripting languages like Perl and Python, I find that I almost
never need to do this, fwiw (disclaimer: I code almost 100% in Python). The Python os and
shutil modules have most of what I need most of the time, and there are built-in modules for
handling tarfiles, gzip files, zip files, etc. There's a glob module, an fnmatch module...
there's a lot of stuff there. If you come across something you need to parallelize, then
indent your code a level, put it in a 'run()' method, put that in a class that extends either
threading.Thread or multiprocessing.Process, instantiate as many of those as you want,
calling 'start()' on each one. Less than 5 minutes to get parallel execution generally.
There are a few things you can only do in bash (for example, alter the calling environment
(when a script is sourced rather than run). Also, shell scripting is commonplace. It is
worthwhile to learn the basics and learn your way around the available docs.
Plus there are times when knowing a shell well can save your bacon (on a fork-bombed
system where you can't start any new processes, or if /usr/bin and or
/usr/local/bin fail to mount).
The advantage is that it's right there. Unless you use Python (or Perl) as your shell,
writing a script to do a simple loop is a bunch of extra work.
For short, simple scripts that call other programs, I'll use Bash. If I want to keep the
output, odds are good that I'll trade up to Python.
For example:
for file in *; do process $file ; done
where process is a program I want to run on each file, or...
while true; do program_with_a_tendency_to_fail ; done
Doing either of those in Python or Perl is overkill.
For actually writing a program that I expect to maintain and use over time, Bash is rarely
the right tool for the job. Particularly since most modern Unices come with both Perl and
Python.
The most important advantage of POSIX shell scripts over Python or Perl scripts is that a
POSIX shell is available on virtually every Unix machine. (There are also a few tasks shell
scripts happen to be slightly more convenient for, but that's not a major issue.) If the
portability is not an issue for you, I don't see much need to learn shell scripting.
If you want to execute programs installed on the machine, nothing beats bash. You can always
make a system call from Perl or Python, but I find it to be a hassle to read return values,
etc.
And since you know it will work pretty much anywhere throughout all of of time...
The advantage of shell scripting is that it's globally present on *ix boxes, and has a
relatively stable core set of features you can rely on to run everywhere. With Perl and
Python you have to worry about whether they're available and if so what version, as there
have been significant syntactical incompatibilities throughout their lifespans. (Especially
if you include Python 3 and Perl 6.)
The disadvantage of shell scripting is everything else. Shell scripting languages are
typically lacking in expressiveness, functionality and performance. And hacking command lines
together from strings in a language without strong string processing features and libraries,
to ensure the escaping is correct, invites security problems. Unless there's a compelling
compatibility reason you need to go with shell, I would personally plump for a scripting
language every time.
"... Perl has native regular expression support, ..."
"... Perl has quite a few more operators , including matching ..."
"... In PHP, new is an operator. In Perl, it's the conventional name of an object creation subroutine defined in packages, nothing special as far as the language is concerned. ..."
"... Perl logical operators return their arguments, while they return booleans in PHP. ..."
"... Perl gives access to the symbol table ..."
"... Note that "references" has a different meaning in PHP and Perl. In PHP, references are symbol table aliases. In Perl, references are smart pointers. ..."
"... Perl has different types for integer-indexed collections (arrays) and string indexed collections (hashes). In PHP, they're the same type: an associative array/ordered map ..."
"... Perl arrays aren't sparse ..."
"... Perl supports hash and array slices natively, ..."
Perl and PHP are more different than alike. Let's consider Perl 5, since Perl 6 is still under development. Some differences,
grouped roughly by subject:
Perl has native regular expression support, including regexp literals. PHP uses Perl's regexp functions as an
extension.
In PHP, new is an operator. In Perl, it's the conventional
name of an object creation
subroutine defined in packages, nothing special as far as the language is concerned.
Perl logical operators return their arguments, while they
return booleans in PHP. Try:
$foo = '' || 'bar';
in each language. In Perl, you can even do $foo ||= 'default' to set $foo to a value if it's not already set.
The shortest way of doing this in PHP is $foo = isset($foo) ? $foo : 'default'; (Update, in PHP 7.0+ you can do
$foo = $foo ?? 'default' )
Perl variable names indicate built-in
type, of which Perl has three, and the type specifier is part of the name (called a "
sigil "), so $foo is a
different variable than @foo or %foo . (related to the previous point) Perl has separate
symbol table entries
for scalars, arrays, hashes, code, file/directory handles and formats. Each has its own namespace.
Perl gives access to the symbol table
, though manipulating it isn't for the faint of heart. In PHP, symbol table manipulation is limited to creating
references and the extract function.
Note that "references" has a different meaning in PHP and Perl. In PHP,
references are symbol table aliases. In Perl,
references are smart pointers.
Perl has different types for integer-indexed collections (arrays) and string indexed collections (hashes). In PHP,
they're the same type: an associative array/ordered map.
Perl arrays aren't sparse: setting an element with index larger than the current size of the array will set all
intervening elements to undefined (see perldata
). PHP arrays are sparse; setting an element won't set intervening elements.
Perl supports hash and array slices natively,
and slices are assignable, which has all sorts of
uses . In PHP, you use array_slice to extract a slice
and array_splice to assign to a slice.
In addition, Perl has global, lexical (block), and package
scope . PHP has global, function, object,
class and namespace scope .
In Perl, variables are global by default. In PHP, variables in functions are local by default.
Perl supports explicit tail calls via the
goto function.
Perl's prototypes provide more limited type
checking for function arguments than PHP's
type hinting . As a result, prototypes are of more limited utility than type hinting.
In Perl, the last evaluated statement is returned as the value of a subroutine if the statement is an expression (i.e.
it has a value), even if a return statement isn't used. If the last statement isn't an expression (i.e. doesn't have a value),
such as a loop, the return value is unspecified (see perlsub
). In PHP, if there's no explicit return, the
return value is NULL .
Perl flattens lists (see perlsub ); for un-flattened
data structures, use references.
@foo = qw(bar baz);
@qux = ('qux', @foo, 'quux'); # @qux is an array containing 4 strings
@bam = ('bug-AWWK!', \@foo, 'fum'); # @bam contains 3 elements: two strings and a array ref
PHP doesn't flatten arrays.
Perl has special
code blocks ( BEGIN , UNITCHECK , CHECK , INIT and END
) that are executed. Unlike PHP's auto_prepend_file and
auto_append_file
, there is no limit to the number of each type of code block. Also, the code blocks are defined within the scripts, whereas
the PHP options are set in the server and per-directory config files.
In Perl, the semicolon separates statements
. In PHP, it terminates
them, excepting that a PHP close tag ("?>") can also terminate a statement.
Negative subscripts in Perl are relative to the end of the array. $bam[-1] is the final element of the array.
Negative subscripts in PHP are subscripts like any other.
In Perl 5, classes are based on packages and look nothing like classes in PHP (or most other languages). Perl 6 classes
are closer to PHP classes, but still quite different. (Perl 6 is
different from Perl 5 in many other ways, but that's
off topic.) Many of the differences between Perl 5 and PHP arise from the fact that most of the OO features are not built-in
to Perl but based on hacks. For example, $obj->method(@args) gets translated to something like (ref $obj)::method($obj,
@args) . Non-exhaustive list:
PHP automatically provides the special variable $this in methods. Perl passes a reference to the object
as the first argument to methods.
Perl requires references to be blessed to
create an object. Any reference can be blessed as an instance of a given class.
In Perl, you can dynamically change inheritance via the packages @ISA variable.
Strictly speaking, Perl doesn't have multiline comments, but the
POD system can be used for the same affect.
In Perl, // is an operator. In PHP, it's the start of a one-line comment.
Until PHP 5.3, PHP had terrible support for anonymous functions (the create_function function) and no support
for closures.
PHP had nothing like Perl's packages until version 5.3, which introduced
namespaces .
Arguably, Perl's built-in support for exceptions looks almost nothing like exceptions in other languages, so much so that
they scarcely seem like exceptions. You evaluate a block and check the value of $@ ( eval instead
of try , die instead of
throw ). The ErrorTry::Tiny module supports exceptions as you find them in other languages
(as well as some other modules listed in Error's See Also
section).
PHP was inspired by Perl the same way Phantom of the Paradise was inspired by Phantom of the Opera , or Strange
Brew was inspired by Hamlet . It's best to put the behavior specifics of PHP out of your mind when learning Perl, else
you'll get tripped up.
I've noticed that most PHP vs. Perl pages seem to be of the
PHP is better than Perl because <insert lame reason here>
ilk, and rarely make reasonable comparisons.
Syntax-wise, you will find PHP is often easier to understand than Perl, particularly when you have little experience. For example,
trimming a string of leading and trailing whitespace in PHP is simply
$string = trim($string);
In Perl it is the somewhat more cryptic
$string =~ s/^\s+//;
$string =~ s/\s+$//;
(I believe this is slightly more efficient than a single line capture and replace, and also a little more understandable.)
However, even though PHP is often more English-like, it sometimes still shows its roots as a wrapper for low level C, for example,
strpbrk and strspn are probably rarely used, because most PHP dabblers write their own equivalent functions
for anything too esoteric, rather than spending time exploring the manual. I also wonder about programmers for whom English is
a second language, as everybody is on equal footing with things such as Perl, having to learn it from scratch.
I have already mentioned the manual. PHP has a fine online manual, and unfortunately it needs it. I still refer to it from
time to time for things that should be simple, such as order of parameters or function naming convention. With Perl, you will
probably find you are referring to the manual a lot as you get started and then one day you will have an a-ha moment and
never need it again. Well, at least not until you're more advanced and realize that not only is there more than one way, there
is probably a better way, somebody else has probably already done it that better way, and perhaps you should just visit CPAN.
Perl does have a lot more options and ways to express things. This is not necessarily a good thing, although it allows code
to be more readable if used wisely and at least one of the ways you are likely to be familiar with. There are certain styles and
idioms that you will find yourself falling into, and I can heartily recommend reading
Perl Best Practices (sooner rather than
later), along with Perl Cookbook, Second Edition
to get up to speed on solving common problems.
I believe the reason Perl is used less often in shared hosting environments is that historically the perceived slowness of
CGI and hosts' unwillingness to install mod_perl due to security
and configuration issues has made PHP a more attractive option. The cycle then continued, more people learned to use PHP because
more hosts offered it, and more hosts offered it because that's what people wanted to use. The speed differences and security
issues are rendered moot by FastCGI these days, and in most
cases PHP is run out of FastCGI as well, rather than leaving it in the core of the web server.
Whether or not this is the case or there are other reasons, PHP became popular and a myriad of applications have been written
in it. For the majority of people who just want an entry-level website with a simple blog or photo gallery, PHP is all they need
so that's what the hosts promote. There should be nothing stopping you from using Perl (or anything else you choose) if you want.
At an enterprise level, I doubt you would find too much PHP in production (and please, no-one point at Facebook as a
counter-example, I said enterprise level).
Perl is used plenty for websites, no less than Python and Ruby for example. That said, PHP is used way more often than any of
those. I think the most important factors in that are PHP's ease of deployment and the ease to start with it.
The differences in syntax are too many to sum up here, but generally it is true that it has more ways to express yourself (this
is know as TIMTWOTDI, There Is More Than One Way To Do It).
My favorite thing about Perl is the way it handles arrays/lists. Here's an example of how you would make and use a Perl function
(or "subroutine"), which makes use of this for arguments:
sub multiply
{
my ($arg1, $arg2) = @_; # @_ is the array of arguments
return $arg1 * $arg2;
}
In PHP you could do a similar thing with list() , but it's not quite the same; in Perl lists and arrays are actually
treated the same (usually). You can also do things like:
And another difference that you MUST know about, is numerical/string comparison operators. In Perl, if you use <
, > , == , != , <=> , and so on, Perl converts both operands to numbers. If
you want to convert as strings instead, you have to use lt , gt , eq , ne
, cmp (the respective equivalents of the operators listed previously). Examples where this will really get you:
if ("a" == "b") { ... } # This is true.
if ("a" == 0) { ... } # This is also true, for the same reason.
Python was developed organically in the scientific space as a prototyping language that
easily could be translated into C++ if a prototype worked. This happened long before it was
first used for web development. Ruby, on the other hand, became a major player specifically
because of web development; the Rails framework extended Ruby's popularity with people
developing complex websites.
Which programming language best suits your needs? Here is a quick overview of each language
to help you choose:
Approach: one best way vs. human-languagePython
Python takes a direct approach to programming. Its main goal is to make everything obvious
to the programmer. In Python, there is only one "best" way to do something. This philosophy has
led to a language strict in layout.
Python's core philosophy consists of three key hierarchical principles:
Explicit is better than implicit
Simple is better than complex
Complex is better than complicated
This regimented philosophy results in Python being eminently readable and easy to learn --
and why Python is great for beginning coders.
Python has a big foothold in introductory programming courses . Its syntax is very simple,
with little to remember. Because its code structure is explicit, the developer can easily tell
where everything comes from, making it relatively easy to debug.
Python's hierarchy of principles is evident in many aspects of the language. Its use of
whitespace to do flow control as a core part of the language syntax differs from most other
languages, including Ruby. The way you indent code determines the meaning of its action. This
use of whitespace is a prime example of Python's "explicit" philosophy, the shape a Python app
takes spells out its logic and how the app will act.
Ruby
In contrast to Python, Ruby focuses on "human-language" programming, and its code reads like
a verbal language rather than a machine-based one, which many programmers, both beginners and
experts, like. Ruby follows the principle of " least astonishment ," and
offers myriad ways to do the same thing. These similar methods can have multiple names, which
many developers find confusing and frustrating.
Unlike Python, Ruby makes use of "blocks," a first-class object that is treated as a unit
within a program. In fact, Ruby takes the concept of OOP (Object-Oriented Programming) to its
limit. Everything is an object -- even global variables are actually represented within the
ObjectSpace object. Classes and modules are themselves objects, and functions and operators are
methods of objects. This ability makes Ruby especially powerful, especially when combined with
its other primary strength: functional programming and the use of lambdas.
In addition to blocks and functional programming, Ruby provides programmers with many other
features, including fragmentation, hashable and unhashable types, and mutable strings.
Ruby's fans find its elegance to be one of its top selling points. At the same time, Ruby's
"magical" features and flexibility can make it very hard to track down bugs.
Communities:
stability vs. innovation
Although features and coding philosophy are the primary drivers for choosing a given
language, the strength of a developer community also plays an important role. Fortunately, both
Python and Ruby boast strong communities.
Python
Python's community already includes a large Linux and academic community and therefore
offers many academic use cases in both math and science. That support gives the community a
stability and diversity that only grows as Python increasingly is used for web
development.
Ruby
However, Ruby's community has focused primarily on web development from the get-go. It tends
to innovate more quickly than the Python community, but this innovation also causes more things
to break. In addition, while it has gotten more diverse, it has yet to reach the level of
diversity that Python has.
Final thoughts
For web development, Ruby has Rails and Python has Django. Both are powerful frameworks, so
when it comes to web development, you can't go wrong with either language. Your decision will
ultimately come down to your level of experience and your philosophical preferences.
If you plan to focus on building web applications, Ruby is popular and flexible. There is a
very strong community built upon it and they are always on the bleeding edge of
development.
If you are interested in building web applications and would like to learn a language that's
used more generally, try Python. You'll get a diverse community and lots of influence and
support from the various industries in which it is used.
Tom Radcliffe -Tom Radcliffe has over 20 years experience in software
development and management in both academia and industry. He is a professional engineer (PEO
and APEGBC) and holds a PhD in physics from Queen's University at Kingston. Tom brings a
passion for quantitative, data-driven processes to ActiveState .
Re:Neither! (Score 2,
Interesting)817 by
M. D. Nahas on Friday December
23, 2005 @06:08PM ( #14329127 ) Attached to:
Learning
Java or C# as a Next Language? The cleanest languages I've used are C, Java, and OCaml. By
"clean", I mean the language has a few concepts that can be completely memorized, which results
in less "gotchas" and manual reading. For these languages, you'll see small manuals (e.g.,
K&R's book for C) which cover the complete language and then lots of pages devoted to the
libraries that come with the language. I'd definitely recommend Java (or C, or OCaml) over C#
for this reason. C# seems to have combined every feature of C++, Java, and VBA into a single
language. It is very complex and has a ton of concepts, for which I could never memorize the
whole language. I have a feeling that most programmers will use the subset of C# that is
closest to the language they understand, whether it is C++, Java or VBA. You might as well
learn Java's style of programming, and then, if needed, switch to C# using its Java-like
features.
Andrei • 8 years ago
I'm a programmer with 13+ years experience in web and desktop applications, and I use Python
on occasions (not for the language itself, but for some applications written in Python).
I don't recall seeing a programming language more hectic that Python. It looks like an
April's Fool joke that caught on with the public, like a hack that people just don't let
go.
I spent a few days reading some books about it and I got pretty good with it, but in
many parts I consider it a hack. You want some examples, I assume:
- lists: add an item: append/insert method; get+remove an item: pop method (strange name
matching)
- lists: add an item: append/insert method; remove an item: del STATEMENT (that's right,
not a method, but a statement)
- lists: add an item: append/insert method; get the size: len FUNCTION (that's right, not a
method, but a standalone function)
- iterate over items: for dicts use the iteritems method, for lists use the enumerate
function
- and many others.
I like programming languages which are either brief, or well designed (so that you can
"guess" how API calls will look like before you read about them, by extrapolating your
previous experience in that language). Python is none of that. Moreover, IMHO it's
widespread use in Linux's desktop apps is even hurting Linux's image as a good desktop
OS.
Now the good part: I like Python's whitespaces matter approach. Again, it has some
design problems, but it's nice.
ython3kFTW • 8 years ago
Honestly, anyone who accuses Python of lacking documentation or readability is entirely off
their tree. Python has:
- Docstrings (access them via help(object) or help() and type the name in)
-
docs.python.org , which uses the excellent Sphinx documentation tool
- Most modules come with a readme (although this is common to *just about every* language,
people often overlook it)
- Crunchy (
http://code.google.com/p/cr... which makes online tutorials 'come alive', so to speak,
by embedding an interpreter in the browser
Python even has it's own version of CPAN, the Python Package Index (PyPI,
http://pypi.python.org/pypi) with an absolutely huge listing of packages.
And comparing Django and PHP is ridiculous as Django is a framework, PHP is not. This
probably explains "anonymous"'s comment.
The one point I have to agree on is that Python is *S.L.O.W*, and although you can
increase it's speed quite easily (Psyco, Cython, C Extensions, Stackless Python (which is
an incredible implementation), etc) and bring it up to scratch.
On whitespace: Yes, Python does use a HUGE amount of whitespace, but as "Just a
Developer" pointed out, it's not all necessary and does drastically increase the
readability of your code. Someone tell me this is not criptic:
for(@x){s/(http:.*)/urlencode($1)/eg} and this is the problem you will always face with
people who don't know the language they are talking about (and I am no exception, I don't
know ANY Perl)
Guest Python3kFTW
• 6 years
ago
Docs.python.org is about the least most helpful documentation I've ever read. Want
a simple example of something? Go elsewhere. If Sphinx is the tool responsible for the
awful (the index doesn't scroll with the page - wfh?), the Sphinx is _not_ an excellent
documentation tool.Where I do agree, though, is that Perl is truly, direly, appallingly
awful. Oh, and I do (or did) know Perl. see
more
doc
• 8 years ago
i like perl's implicit arguments. they reflect what i actually do with my code... like, you
know, read from the list of arguments to the program. or, say, do something with a list
variable. try doing this in python and it will lokk like some reverse polish meltdown.
for(@x){s/(http:.*)/urlencode($1)/eg} see
more
Kilroy • 8 years ago
Yes, Python is a very powerful language BUT it is also very slow!
And I am not comparing it with C or other compiled language or statically typed language.
Python is also slow compared to other dynamically typed interpretive languages.
It is okay for PHP and ASP to be slow because PHP and ASP do not claim to be powerful or
advanced languages and they are easy to learn. But Python claims to be an advanced
language. Advanced and yet so slow????
Doug • 9 years ago I
can write perl in my sleep. I'm just learning python. Somehow I found this. Python whitespace
is mostly a non issue. Not better. Not worse. Different. For myself, I like to put temporary
debug print statements flush left...guess I'll have to change that habit with Python. Ok,
that does suck. But in case you haven't figured it out by now, ALL PROGRAMMING LANGUAGES
SUCK(tm). Perl, Python. They suck equally, in different ways. Now get back to work.
Joe Krahn • 10 years ago
There is no explanation here as to why Python sucks. The main problem with Python is that
changes in whitespace can change the function. Having a language that enforces indentation is
OK, but Python depends on precise alignment across many lines of code. Also, an indentation
always counts as one indentation level, no matter what the size, but a dedent can be any
number of dedents, depending on the previous lines of code. It works OK for small bits of
code, but larger programs get really ugly. A folding or Python-aware text editor helps, but
it is still a language weakness. It makes about as much sense as Fortran77 indentation rules.
Perl has it's own problems. Object oriented features are a hack, and even well-formatted
code can look rather cryptic. The documentation is much better just because it has been
around much longer than Python. It is also much faster, probably for the same reason.
I would rather use something less cryptic than Perl, but without the fragile and
annoying indentation rules of Python. Ruby looks promising, but I have not used it much
yet.
Pvdmeer • 7 years ago
Python isn't fast. But I think it's fast enough. I've been a long-time user of Perl. Perl is
sloppy by default. Python isn't, and still it's possible to do a quick five-line experiment
without the pain. I think Python is a slow version of Perl (including the awesome amounts of
modules), but way more tidy and suited for developing somewhat bigger apps. For developing
off-line scientific tools, it's the weapon of choice (because of the speed of the numpy
vector operations). And if you hate a language for it not being able to not make a binary
then, you sir, have never heard of package managers. Also, I made apps with Java, and the
development process was excruciatingly slow, same for C++ with its gazillion features which
all bear caveats. Python is a productive language. And btw, the Python documentation is
actually pretty good and widely available. Maybe in 2003 it wasn't, I don't know.
I use Python somewhat regularly, and overall I consider it to be a very good language.
Nonetheless, no language is perfect. Here are the drawbacks in order of importance to me
personally:
It's slow. I mean really, really slow. A lot of times this doesn't matter, but it
definitely means you'll need another language for those performance-critical bits.
Nested functions kind of suck in that you can't modify variables in the outer scope.
Edit: I still use Python 2 due to library support, and this design flaw irritates
the heck out of me, but apparently it's fixed in Python 3 due to the nonlocal
statement. Can't wait for the libs I use to be ported so this flaw can be sent to the ash
heap of history for good.
It's missing a few features that can be useful to library/generic code and IMHO are
simplicity taken to unhealthy extremes. The most important ones I can think of are
user-defined value types (I'm guessing these can be created with metaclass magic, but I've
never tried), and ref function parameter.
It's far from the metal. Need to write threading primitives or kernel code or
something? Good luck.
While I don't mind the lack of ability to catch semantic errors upfront as a
tradeoff for the dynamism that Python offers, I wish there were a way to catch syntactic
errors and silly things like mistyping variable names without having to actually run the
code.
The documentation isn't as good as languages like PHP and Java that have strong
corporate backings.
And of course also why it sucks a lot less than any other language. But it's not perfect. My
personal problems with python:
It's dict and not Dict, it's list and not List and you cannot subclass them without
overriding every method.......
it's copy.copy and not just copy. Why in god's name is that an import?
clean up the stdlib
there is BaseHTTPServer and not py.http.baseserver or something like that. Why is that
darn stdlib flat?
there are soo many bad libraries in the stdlib and so many good ones not...
no goddamn styleguide for the stdlib. it's UnitTest.assertEqual and not
UnitTest.assert_equal like PEP 8 proposes
By now you cannot reassign a variable from and outer scope. (there is a pep!)
clean up the stdlib
assignments are not expressions. gaaaaa. I want to do (foo |= []).append(42) and
not foo |= []; foo.append(42) etc.
No regexp literal and match objects are not instances of a Regexp class. Move the sre
module into the core, add a @/foo/ literal and create a Regexp class instead of
something like _sre.SRE_Pattern which you cannot import to make isinstance tests
missing blocks. darn. i want blocks
unify unicode and string. quick! (waiting for Python 3000)
clean up the stdlib
Why it still sucks less? Good question. Probably because the meta programming capabilities
are great, the libraries are awesome, indention based syntax is hip, first class functions ,
quite fast, many bindings (PyGTW FTW!) and the community is nice and friendly. And there is
WSGI!
"... Python is relatively constraining - in the sense that it does not give the same amount of freedom as PERL in implementing something (note I said 'same amount' - there is still some freedom to do things). But I also see that as Python's strength - by clamping down the parts of the language that could lead to chaos we can live without, I think it makes for a neat and tidy language. ..."
"... Perl 5, Python and Ruby are nearly the same, because all have copied code from each other and describe the same programming level. Perl 5 is the most backward compatible language of all. ..."
"... Python is notably slower than Perl when using regex or data manipulation. ..."
Perl is better.
Perl has almost no constraints. It's philosophy is that there is more than one way to do
it (TIMTOWTDI, pronounced Tim Toady). Python artificially restricts what you can do as a programmer. It's philosophy is that
there should be one way to do it. If you don't agree with Guido's way of doing it, you're
sh*t out of luck.
Basically, Python is Perl with training wheels. Training wheels are a great thing for a
beginner, but eventually you should outgrow them. Yes, riding without training wheels is less
safe. You can wreck and make a bloody mess of yourself. But you can also do things that you
can't do if you have training wheels. You can go faster and do interesting and useful tricks
that aren't possible otherwise. Perl gives you great power, but with great power comes great
responsibility.
A big thing that Pythonistas tout as their superiority is that Python forces you to write
clean code. That's true, it does... at the point of a gun, sometimes at the detriment of
simplicity or brevity. Perl merely gives you the tools to write clean code (perltidy,
perlcritic, use strict, /x option for commenting regexes) and gently encourages you to use
them.
Perl gives you more than enough rope to hang yourself (and not just rope, Perl gives you
bungee cords, wire, chain, string, and just about any other thing you can possibly hang
yourself with). This can be a problem. Python was a reaction to this, and their idea of
"solving" the problem was to only give you one piece of rope and make it so short you can't
possibly hurt yourself with it. If you want to tie a bungee cord around your waist and jump
off a bridge, Python says "no way, bungee cords aren't allowed". Perl says "Here you go, hope
you know what you are doing... and by the way here are some things that you can optionally
use if you want to be safer"
One liners. Perl has a whole set of shortcuts for making it easy to write ad-hoc
scripts on the command line
Speed. For most tasks, Perl is significantly faster than Python
Regular expressions are a first-class datatype rather than an add in. This means you
can manipulate them programatically like any other first-class object.
Power. You can do things in Perl that are either much harder, or prohibited, in Python.
For instance the <> operator... this lets you trivially deal with the complexities of
opening files from the command line and/or accepting streams from pipes or redirection. You
have to write several lines of boilerplate Python code to duplicate the behavior of Perl's
while (<>) ... construct (or even more trivially the -n switch, which
automatically wraps your code with this construct).
No significant whitespace. If your formatting gets mangled (by, say, posting it to a
web forum or sending it in an email that munges whitespace), the meaning of your code
doesn't change, and you can trivially re-format your code with Perltidy according to whatever coding style you
define. You can format your code as to what is most clear in context, rather than having to
conform to an arbitrary set of restrictions.
Postfix notation. This can be ugly and is easily misused, but used with care it makes
your code easier to read, especially for things like die if $condition or
die unless $condition assertions.
Sigils. It's a love it or hate it thing, but sigils unambiguously distinguish variables
from commands, make interpolation effortless, and make it easy to tell at a glance what
kind of variable it is without having to resort to some ugly hack like Hungarian
notation.
Inline::C and all of the
other Inline::* modules). Yes, you can write Python extensions in C but Inline::C makes it
effortless.
Pod is vastly more powerful than Docstrings, especially when you throw in the power of
something like Pod::Weaver to
write/manipulate your documentation programatically.
Advantages of Python
JVM interoperatiblity. For me this is huge. It's the only thing that Python does better
than Perl. Being able to write code that runs in the JVM and to work with Java objects/APIs
without having to write Java code is a huge win, and is pretty much the only reason I ever
write anything in Python.
Learning curve. Python is easier to learn, no denying it. That's why I'm teaching it to
my 12 year old son as his first programming language
User community. Python is more popular and has a larger active user community. Appeal
to popularity is a fallacy, but you can't just dismiss mindshare and 3rd party support
either.
Though I may get flamed for it, I will put it even more bluntly than others have: Python
is better than Perl . Python's syntax is cleaner, its object-oriented type system is more
modern and consistent, and its libraries are more consistent. ( EDIT: As Christian Walde points out
in the comments, my criticism of Perl OOP is out-of-date with respect to the current de facto
standard of Moo/se. I do believe that Perl's utility is still encumbered by historical
baggage in this area and others.)
I have used both languages extensively for both professional work and personal projects
(Perl mainly in 1999-2007, Python mainly since), in domains ranging from number crunching
(both PDL and NumPy are excellent) to web-based programming (mainly with
Embperl and Flask ) to good ol' munging text files and database
CRUD
Both Python and Perl have large user communities including many programmers who are far
more skilled and experienced than I could ever hope to be. One of the best things about
Python is that the community generally espouses this
aspect of "The Zen of Python"
Python's philosophy rejects the Perl " there is more than one
way to do it " approach to language design in favor of "there should be one -- and
preferably only one -- obvious way to do it".
... while this principle might seem stultifying or constraining at first, in practice it
means that most good Python programmers think about the principle of least
surprise and make it easier for others to read and interface with their code.
In part as a consequence of this discipline, and definitely because of Python's strong typing , and
arguably because of its "cleaner" syntax, Python code is considerably easier to read
than Perl code. One of the main events that motivated me to switch was the experience of
writing code to automate lab equipment in grad school. I realized I couldn't read Perl code
I'd written several months prior, despite the fact that I consider myself a careful and
consistent programmer when it comes to coding style ( Dunning–Kruger effect ,
perhaps? :-P).
* For example, the one-liner perl bak pe 's/foo/bar/g' *. txt will go through a
bunch of text files and replace foo with bar everywhere while
making backup files with the bak extension.
Neither language is objectively better. If you get enthused about a language - and by all
means, get enthused about a language! - you're going to find aspects of it that just strike
you as beautiful. Other people who don't share your point of view may find that same aspect
pointless. Opinions will vary widely. But the sentence in your question that attracted my
attention, and which forms the basis of my answer, is "But, most of my teammates use Perl."
If you have enough charisma to sway your team to Python, great. But in your situation,
Perl is probably better . Why? Because you're part of a team, and a team is more
effective when it can communicate easily. If your team has a signifigant code base written in
Perl, you need to be fluent in it. And you need to contribute to the code base in that same
language. Life will be easier for you and your team.
Now, it may be that you've got some natural lines of demarcation in your areas of interest
where it makes sense to write code for one problem domain in Perl and for another in Python -
I've seen this kind of thing before, and as long as the whole team is on board, it works
nicely. But if your teammates universally prefer Perl, then that is what you should focus
on.
It's not about language features, it's about team cohesion.
I used Perl since about 1998 and almost no Python until 2013. I have now (almost) completely
switched over to Python (written 10s of thousands of lines already for my project) and now
only use Perl one-liners on the Linux command line when I want to use regex and format the
print results when grepping through multiple files in my project. Perl's one-liners are
great.
This surprisingly easy transition to fully adopt Python and pretty much drop Perl simply
would not be have been possible without the Python modules, collections and re
(regex package). Python's numpy, matplotlib, and scipy help seal the deal.
The collections package makes complex variables even easier to create than in Perl.
It was created in 2004, I think. The regex package, re , works great, but I wish it
was built into the Python language like it is in Perl because using regex usage is smooth in
Perl and clunky(er) in Python.
OOP is super easy and not as verbose as in C++, so I find it faster to write, if needed in
Python.
I've drank the Kool-Aid and there is no going back. Python is it. (for now)
Python is easier to learn, Perl takes a while to get used to and is not intuitive. Perl
is great, if you already know it.
I use Perl to write quick scripts using regular expressions, to perform text/data
manipulations. If there is anything Perl can do well, it is string manipulations.
I use Python for writing reusable code. I personally think OO in Perl is a little odd,
and find Python to be more consistent. For example, I find it easier to create modules in
Python.
Perl scripts are often messy (it takes me a while to understand my own scripts),
whereas, Python is very clean.
I can't think of anything that you can do with Perl that you can't with Python. If I were
you, I'd stick with Python.
It's kind of funny; back in the early 1970's, C won out over Pascal despite being much more
cryptic. They actually have the same level of control over the machine, Pascal is just more
verbose about it, and so it's quicker to write little things in C. Today, with Python and
Perl, the situation is reversed; Python, the far less cryptic of the two, has won out over
Perl. It shows how values change over time, I suppose.
One of the values of Python is the readability of the code. It's certainly a better
language for receiving someone else's work and being able to comprehend it. I haven't had the
problem where I can't read my own Perl scripts years later, but that's a matter of fairly
strict discipline on my part. I've certainly received some puzzling and unreadable code from
other Perl developers. I rather hate PowerShell, in part because the messy way it looks
on-screen and its clumsy parameter passing reminds me of Perl.
For collaboration, the whole team would do better on Python than on Perl because of the
inherent code readability. Python is an extreme pain in the neck to write without a
syntax-aware editor to help with all the whitespace, and that could create a barrier for some
of your co-workers. Also Python isn't as good for a really quick-and-dirty script, because
nothing does quick (or dirty) better than Perl. There are a number of things you can do in
Perl more quickly and I've done some things with Perl I probably wouldn't be interested in
even trying in Python. But if I'm doing a scripting task today, I'll consider Python and even
Scala in scripting mode before I'll consider Perl.
I'll take a guess that your co-workers are on average older than you, and probably started
Perl before Python came along. There's a lot of value in both. Don't hate Perl because of
your unfamiliarity with it, and if it's a better fit for the task, maybe you will switch to
Perl. It's great to have the choice to use something else, but on the other hand, you may
pick up an awful lot of maintenance burden if you work principally in a language nobody else
in your company uses.
I have used Perl and Python both. Perl from 2004-2007, and Python, early 2009 onward. Both
are great, malleable languages to work with. I would refrain from making any comments
on the OOP model of PERL since my understanding is most likely out-of-date now.
Library-wise PERL and Python both have a fantastic number of user-contributed libraries.
In the initial days of Python, PERL definitely had an edge in this regard - you could find
almost anything in its library repository CPAN, but I am not sure whether this edge exists
anymore; I think not.
Python is relatively constraining - in the sense that it does not give the same amount of
freedom as PERL in implementing something (note I said 'same amount' - there is still some
freedom to do things). But I also see that as Python's strength - by clamping down the parts
of the language that could lead to chaos we can live without, I think it makes for a neat and
tidy language.
I loved PERL to death in the years I used it. I was an ardent proselytizer. My biggest
revelation/disappointment around the language came when I was asked to revisit a huge chunk
of production code I had written a mere 6 months ago. I had a hard time understanding various
parts of the code; most of it my own code! I realized that with the freedom that PERL offers,
you and your team would probably work better (i.e. write code that's maintainable ) if
you also had some coding discipline to go with it. So although PERL provides you a lot of
freedom, it is difficult to make productive use of it unless you bring in your own discipline
(why not Python then?) or you are so good/mature that any of the many ways to do something in
the language is instantly comprehensible to you (i.e. a steeper learning curve if you are not
looking forward to brain-teasers during code-maintenance).
The above is not an one-sided argument; it so happened that some years later I was in a
similar situation again; only this time the language was Python. This time around I was
easily able to understand the codebase. The consistency of doing things in Python helps.
Emerson said consistency is the hobgoblin of little minds , but maybe faced with the
daunting task of understanding huge legacy codebases we are relatively little minds.
Or maybe its just me (actually not, speaking from experience :) ).
All said and done, I am still a bit miffed at the space/tab duality in Python :)
You're asking the wrong question because the answer to your question is, it depends. There is
no best language. It depends on what you're going to use it for. About 25 years ago, some
bureaucratic decided that every system written by the DoD was to be written in Ada. The
purpose was that we'd only have to train software developers in one language. The DoD could
painlessly transfer developers from project to project. The only problem was that Ada wasn't
the best language for all situations. So, what problem do you wish to solve by programming.
That will help to determine what language is the best.
Perl 5, Python and Ruby are nearly the same, because all have copied code from each other and
describe the same programming level. Perl 5 is the most backward compatible language of all.
Python is much better, if only because it's much more readable. Python programs are therefore
easily modifiable, and then more maintainable, extensible, etc.
Perl is a powerful language, and a Perl script can be fun to write. But is a pain to read,
even by the one who wrote it, after just a couple of months, or even weeks. Perl code usually
looks like(and in many cases just is) a hack to get something done quickly and "easily".
What is still confusing and annoying in Python are the many different frameworks employed
to build and install modules, the fact that much code and modules are still in beta stage,
unavailable on certain platforms, or with difficult or almost impossible to satisfy
binary(and also non-binary, i.e. due to different/incompatible versions) dependencies. Of
course, this is related to the fact that Python is still a relatively young language.
Python 3 vs. 2 incompatibilities, though justifiable and logical, also don't help in this
regard.
Perl is the unix of programming languages. Those who don't know it are condemned to
re-implement it (and here I'm looking at you, Guido), badly. I've read a lot of Python books,
and many of the things they crow about as being awesome in Python have existed in Perl since
the beginning. And most of those Perl stole from sed or awk or lisp or shell. Sometimes I
think Pythonistas are simply kids who don't know any other languages, so of course they think
Python is awesome.
as someone that worked professionally with Perl, and moved to python only two years ago the
answer sound simple.
Work with whatever you can that feels more comfortable, however if your teammates use Perl it
would be better to learn Perl in order to share code and refrain from creating code that
cannot be reused.
in terms of comparison
1. python is object oriented by design, Perl can be object oriented but it is not a
must
2. Python has a very good standard library, Perl has cpan with almost everything.
3. Perl is everywhere and in most cases you won't need newer perl for most cpan modules,
python is a bit more problematic in this regard
4. Python is more readable after a month than Perl
there are other reasons but those are the first that comes to mind
Your question sounds a bit like "Which is better a boat or a car?". You simply do not do the same things with them. Or more precisely, some things are easier
to do with Perl and others are easier with Python. None of them is robust (compare with Eiffel or Oberon, and if you never heard of these it
is because robustness is not so important for you). So learn both, and choose for yourself. And also pick a nice one in http://en.wikipedia.org/wiki/Tim...
(why not Julia?). A language that none of your friend knows about and stick out your tongue
to them.
Python is notably slower than Perl when using regex or data manipulation. I think if
you're worried about the appeal of Perl, you could use PyCharm with Perl too. Furthermore, I believe the primary reason why someone would use
an interpreted language on the job is to manipulate or analyze data. Therefore, I would use
the Perl in order to get the job done quickly and worry about the appears another time.
I had to learn Perl in an old position at work, where system build scripts were written in
Perl and we are talking system builds that would take 6 to 8 hours to run, and had to run in
both Unix and Windows environments.
That said, I have continued to use Perl for a number of reasons
I love the ability to automate other systems with Perl, making data entry, problem
definition, etc. quick and easy.
The ability to deal with hashes while at first one of the more difficult concepts to
grasp has been a blessing.
Working with JSON and data structures is similarly a blessing, and curse.
Play with BIGINT a little, you can deal with integers that are hundreds of characters
long not that I have found where this helps with "work" but it does make some of the
programming challenges easier.
Yes, I now need to use Python at work, but I have actually found it more difficult to
learn than Perl, especially for pulling in a web page and extracting data out of the
page.
For beginner, I suggest Python. Perl 6 is released and Perl 5 will be replaced by Perl 6 or Ruby. Python is easier for a
beginner and more useful for future life no matter you want to be a scientist or a
programmer. Perl is also a powerful language but it only popular in U.S., Japan, etc.
Anyway, select the one you like, and learn the other as a second-language.
Perl is and older language and isn't really in the vogue. Python has a wider array of
applications and as a "trendy" language, greater value on the job market.
First, I'll say it's almost impossible to say if any one language is 'better' than
another, especially without knowing what you're using them for, but...
Short answer, it's Python. To be honest, I don't know what you mean by 'robust', they are both established languages,
been around a long time, they are both, to all intents and purposes, bug free, especially if
you're just automating a few tasks. I've not used Perl in quite some time, except when I delve into a very old project I
wrote. Python has terrible syntax, and Perl has worse, in my opinion. Just to make my answer a bit more incendiary, both Perl and Python both suck, Python sucks
significantly less.
"... Secondly I am personally not overly concerned with what the popular language of the day is. As I commented ages ago at RE (tilly) 1: Java vs. Perl from the CB , the dream that is sold to PHBs of programmers as interchangable monkeys doesn't appeal to me, and is a proven recipe for IT disasters. See Choose the most powerful language for further discussion, and a link to an excellent article by Paul Graham. As long as I have freedom to be productive, I will make the best choice for me. Often that is Perl. ..."
"... Indeed languages like Python and Ruby borrow some of Perl's good ideas, and make them conveniently available to people who want some of the power of Perl, but who didn't happen to click with Perl. I think this is a good thing in the end. Trying different approaches allows people to figure out what they like and why they like it, leading to better languages later. ..."
"... Well, to start off, I think you're equating "popularity" with "success". It's true that Perl awareness is not as widespread as the other languages you mention. (By the way, I notice that two of them, C# and Java, are products of corporations who would like to run away with the market regardless of the technical merit of their solution). But when I first read the title of your note, I thought a lot of other things. To me, "decline" means disuse or death, neither of which I think apply to Perl today. ..."
I love Perl and have been using it since 1996 at my work for administrative tasks as well as
web based products. I use Perl on Unix and Windows based machines for numerous tasks.
Before I get in depth about the decline let me give a little background of myself. I got my
first computer in 1981, a TRS-80 Model III 4 MHz Z80 processor, 16K RAM, no HD, no FD, just a
cassette tape sequential read/write for storage and retrieval. The TRS-80 line allowed for
assembler or BASIC programs to be run on it. I programmed in both BASIC and assembler, but most
BASIC since I had limited memory and using the tape became very annoying. Lets time warp
forward to 1987 when Perl was first released.
The introduction of Perl was not household knowledge; the use of computers in the home was
still considerably low. Those that did have computers most likely did very specific tasks; such
as bring work home from the office. So it is fairly safe to say that Perl was not targeted at
inexperienced computer users, but more to system administrators and boy did system
administrators love it. Now lets time warp ahead to 1994.
1994 marked what I consider the start of the rush to the WWW (not the internet) and it was
the birth year of Perl 5 and DBI. The WWW brought to use the ability to easily link to any
other site/document/page via hypertext markup language or as we like to say, HTML. This "
new " idea
caused created a stir in the non-tech world for the first time. The WWW, as HTML progressed,
started to make using and knowing about computers a little less geek. Most servers were UNIX
based and as the needs for dynamic content or form handling grew what language was there to
assist? Perl. So Perl became, in a way, the default web language for people that hadn't been
entrenched in programming another CGI capable language and just wanted to process a form,
create a flat file data store, etc. that is non-techies.
Perl served us all well, but on the horizon were the competitors. The web had proven itself
not to be a flash in the pan, but a tool through which commerce and social interaction could
take new form and allow people that had never considered using a computer before a reason to
purchase one. So the big software and hardware giants looked for ways to gain control over the
web and the Internet in general. There were even smaller players that were Open Source and
freeware just like Perl.
So by 2000 there were several mature choices for Internet development and Perl was a drift
in the sea of choice. I also see 2000 as the year the tide went out for Internet development in
general. The "rush" had subsided, companies and investor started to really analyze what they
had done and what the new media really offered to them. Along with analyzing comes consultants.
Consultants have an interest in researching or developing the best product possible for a
company. The company is interested in that when they terminate the contract with the consultant
that they will be able to maintain what they bought. This brings us to the rub on Perl. How can
a consultant convince a company that his application language of choice is free and isn't
backed by a company? ActiveState I believe backs Perl to some extent, but one company generally
isn't enough to put a CTO at ease.
So the decline of Perl use can be summarized with these facts:
Perl is thought of as a UNIX administrative tool
There are not enough professional organizations or guilds to bolster confidence with
corporations that investing in a Perl solution is a good long-term plan.
Perl doesn't have large scale advertising and full time advocates that keep Perl in major
computing publications and remind companies that when they chose, chose Perl.
There is no official certification. I have seen Larry's comments on this and I agree with
him, but lack of certification hurts in the corporate world.
Lack of college or university Perl class, or maybe better-stated lack of Perl promotion
by colleges.
I suppose all of this really only matter to people that don't make their living extending Perl
or using it for system admin work that isn't approved by a board or committee. People that make
final products based on Perl for the Internet and as standalone applications are effected by
the myths and facts of Perl.
Last year a possible opportunity I had to produce a complete package for a large
telecommunications firm failed in part due to lack of confidence in Perl as the language of
choice, despite the fact that two districts had been successfully using the prototype and
increased efficiency.
Another factor is the overseas development services. My most recent employer had a
subsidiary in India with 30 developers. Training for Perl was unheard of. There were signs
literally everywhere for C++ , C# and Java, but no mention of Perl. It seems Perl is used for
down and dirty utilities not full scale applications.
Maybe Perl isn't "supposed" to be for large-scale applications, but I think it can be and I
think it's more then mature enough and supported to provide a corporation with a robust and
wise long-term solution.
I am very interested in your opinions about why you feel Perl is or isn't gaining
ground.
First of all I don't know whether Perl is declining. Certainly I know that some of the
Perl 6 effort has done exactly what it was intended to do, and attracted effort and interest
in Perl. I know that at my job we have replaced the vast majority of our work with Perl, and
the directions we are considering away from Perl are not exactly popularly publicized
ones.
Secondly I am personally not overly concerned with what the popular language of the day
is. As I commented ages ago at RE (tilly) 1: Java vs. Perl from the CB , the
dream that is sold to PHBs of programmers as interchangable monkeys doesn't appeal to me, and
is a proven recipe for IT disasters. See Choose the most powerful language for further
discussion, and a link to an excellent article by Paul Graham. As long as I have freedom to
be productive, I will make the best choice for me. Often that is Perl.
Third I don't see it as a huge disaster if Perl at some point falls by the wayside. Perl
is not magically great to push just because it is Perl. Perl is good because it does things
very well. But other languages can adopt some of Perl's good ideas and do what Perl already
does. Indeed languages like Python and Ruby borrow some of Perl's good ideas, and make them
conveniently available to people who want some of the power of Perl, but who didn't happen to
click with Perl. I think this is a good thing in the end. Trying different approaches allows
people to figure out what they like and why they like it, leading to better languages
later.
Perhaps I am being narrow minded in focusing so much on what makes for good personal
productivity, but I don't think so. Lacking excellent marketing, Perl can't win in the hype
game. It has to win by actually being better for solving problems. Sure, you don't see Perl
advertised everywhere. But smart management understands that something is up when a small
team of Perl programmers in 3 months manages to match what a fair sized team of Java
programmers had done in 2 years. And when the Perl programmers come back again a year later
and in a similar time frame do what the Java programmers had planned to do over the next 5
years...
Well, to start off, I think you're equating "popularity" with "success". It's true that
Perl awareness is not as widespread as the other languages you mention. (By the way, I notice
that two of them, C# and Java, are products of corporations who would like to run away with
the market regardless of the technical merit of their solution). But when I first read the
title of your note, I thought a lot of other things. To me, "decline" means disuse or death,
neither of which I think apply to Perl today.
The fact that there isn't a company with a lot of money standing behind Perl is probably
the cause of the phenomena you observe. The same applies to other software that is produced
and maintained by enthusiasts rather than companies. Linux is a very good example. Up to
recently, Linux was perceived as just a hobbyist's toy. Now there are small glimmers of its
acceptance in the corporate world, mainly from IBM stepping up and putting together a
marketing package that non-technical people can understand. (I'm thinking of recent TV ad
campaigns.) But does that make Linux "better"? Now there's a way to start an argument.
I agree that except in certain cases (look at The Top Perl Shops for some
examples), most companies don't "get" Perl. Last year at my current client, I suggested that
a new application be prototyped using a Perl backend. My suggestion was met with something
between ridicule and disbelief ("We don't want a bunch of scripts , we want a
real program ". That one stung.) To give them credit -- and this lends credence to one
of your points -- they had very few people that could program Perl. And none of then were
very good at it.
So has this lack of knowledge among some people made Perl any worse, or any less useful?
No, definitely not. I think the ongoing work with Perl 6 is some of the most interesting and
exciting stuff around. I think the language continues to be used in fascinating leading-edge
application areas, such as bioinformatics. The state of Perl definitely doesn't fit my
definition of "decline".
Nonetheless, I think your point of "corporate acceptance" is well-taken. It's not that the
language is declining, it's that it's not making inroads in the average boardroom. How do you
get past that barrier? For my part, I think the p5ee project is a step in the right direction. We need to
simplify Perl training, which is one of the goals of the standardization, and provide
something for a corporate executive to hold on to -- which is a topic of discussion in the
mailing list right now.
And the nice part is that the standardized framework doesn't stop all
the wonderful and creative Cool uses for Perl that we've
become accustomed to. If the lack of corporate acceptance is of concern to you, then join the
group. "Dont' curse the darkness, light a candle" is an old Chinese proverb .
Re: Re: The Decline of
Perl - My Opinion
There was a post on the mod_perl list later the same day that I wrote this, that shows a
steady rise in the use of mod_perl
based servers. The graph
.
Maybe a better title should be, Top Hindrances in Selling Perl Solutions
I agree with your timeline and general ideas about what brought perl into focus. I also
agree with perl being adrift in a sea of choices and with the rush subsiding in 2000. I whole
heartedly disagree with your arguments about why perl will decline. Let's not look at your
summary but at the pillars of your summary.
1. Perl is thought of as a UNIX administrative tool.
You really don't have much support for this summary. You state that system
administrators love it but so do a whole lot of developers!
2. There are not enough professional organizations or guilds to bolster confidence with
corporations that investing in a Perl solution is a good long-term plan.
Well you're at one of the most professional guilds right now. I don't see a cold fusion
monks site? What do you want? Certification? I think more of my BS and BA then I do of any
certification. As for "good long-term plans" - very few business see past the quarter. While
I think this is generally bad , I think it's going to work wonders for open software.
Where can you trim the budget to ensure profitability - cut those huge $$$$ software licenses
down to nothing.
3. Perl doesn't have large scale advertising and full time advocates that keep Perl in
major computing publications and remind companies that when they chose, chose Perl.
Hmmm ... not sure I want to base my IT selection on what the mags have to say -- I've seen
a whole lot of shelf-ware that was bought due to what some wags say in the latest issue of
some Ziff Davis trash.
3. There is no official certification. I have seen Larry's comments on this and I agree
with him, but lack of certification hurts in the corporate world.
The are only two certifications that count - one is years of experience and the other is a
sheep skin. Anything else is pure garbage. As long as you have the fundamentals of algorithm
design down - then who cares what the cert is.
4. Lack of college or university Perl class, or maybe better-stated lack of Perl
promotion by colleges.
I wouldn't expect anyone right out of college to be productive in any language. I would
expect them to know what makes a good algorithm - and that my friend is language agnostic. Be
it VB, C, C++, or perl - you have to know big-o.
It sounds like you're a little worried about a corporations perception about our language
of choice. I wouldn't be. Given the current perception of corporate management (ala Enron), I
think the people who make the (ehh) long-range plans may be around a lot less than us tech
weenies. Bring it in back doors if you want. Rename it if you have to - an SOAP enabled
back-end XML processor may be more appealling then an apache/mod_perl engine (that's where
the BA comes in).
It also sound like you're worried about overseas chop shops. Ed Yourdan rang that bell
about ten years ago with "The Decline and the Fall of the American Programmer." I must say I
lost a lot of respect for Ed on that one. Farming out development to India has proven to be
more of a lead egg than the golden hen - time zone headaches and culture clash has proved
very hard to overcome.
Perl is moving on ... it seemed static because everyone was catching up to it. That being
said, some day other OSS languages may overtake it but Python and Ruby are still in perl's
review mirror.
Just like loved ones, we tend to ignore those which are around us everyday. For this
Valentines day, do us all a favor and by some chocolates and a few flowers for our
hard-working and beloved partner - We love you perl.
A few thoughts and data points: Perl may have gained ground initially in System Administration, and since the Web came
along, Perl now is though of more as the language of CGIs.
My previous employer also had a subsidiary in India, and my distributed project included a
team there, working on a large (80K line) web application in Perl. Folks coming out of
University in India are more likely to have been trained in C++ or Java, but Perl isn't
unknown.
On Certification: Be very careful with this. HR departments might like to see
certifications on resumes, but in the development teams I've worked in, a Very Big Flag is
raised by someone claiming to have a certification. The implication, fair or not, is "this
person is a Bozo."
Here's the thing: to some extent, you're right, but at the same time, you're still way off
base. Now let's say, just for a second, that the only thing Perl can / should be used for is
system administration and web programming (please don't flame me, guys. I know that is by no
means the extent of Perl's capabilities, but I don't have time to write a post covering all
the bases right now.) Even assuming that's true, you're still wrong.
Considering the web side of it, yes, Perl is being used in far fewer places now. There are
two major reasons for this: one is the abundance of other languages (PHP and ::shudder:: ASP,
for example). Another is the fact that a lot of sites backed by Perl programming crashed and
burned when the dot-coms did. You know what? I don't see this as a big deal. The techies who
wrote those sites are still around, likely still using Perl, and hopefully not hurting its
reputation by using it to support companies that will never, ever, make any money or do
anything useful...ever. (Not to say that all dot-coms were this way, but c'mon, there were
quite a few useless companies out there.) These sites were thrown together (in many cases) to
make a quick buck. Granted, Perl can be great for quick-and-dirty code, but do we really want
it making up the majority of the volume of the code out there?
System administration: I still think Perl is one of the finest languages ever created for
system administration, especially cross-platform system admin, for those of us who don't want
to learn the ins and outs of shell scripting 100x over. I really don't think there'll be much
argument there, so I'll move on.
The community: when was the last time Perl had organizations as devoted as the Perl
Mongers and Yet Another Society? Do you see a website as popular and helpful as Perlmonks for
PHP? Before last year, I don't remember ever having programmers whose sole job is to improve
and evangelize Perl. Do you? I can't remember ever before having an argument on the Linux
kernel mailing list on whether Linux should switch to a quasi-Perl method of patch
management. (This past week, for those who haven't been reading the kernel mailing list or
Slashdot.)
To be honest, I have no idea what you're talking about. As far as I'm concerned, Perl is
as strong as it's ever been. If not, then it's purely a matter of evangelization. I know I've
impressed more than one boss by getting what would've been a several-day-long job done in an
hour with Perl. Have you?
I'm not sure how you backup the statement that Perl is declining , but
anyway.
There's a huge difference between writing sysadmin tools and writing business
oriented applications. (Unless your business is to provide sysadmin tools. ;-)
In my shop, the sysadmins are free to use almost any tools, languages, etc. to
get their work done. OTOH, when it comes to business supporting applications, with end user
interface, the situation is very different. This is when our middle level management starts
to worry.
My personal experience is that Perl does have a very short and low learning curve when it
comes to writing different 'tools' to be used by IT folks.
The learning curve may quickly become long and steep when you want to create a business
oriented application, very often combining techniques like CGI, DBI (or SybPerl), using non
standard libraries written as OO or not plus adding your own modules to cover your
shop-specific topics. Especially if you want to create some shared business objects to be
reused by other Perl applications. Add to this that the CGI application shall create
JavaScript to help the user orient through the application, sometimes even JS that
eval() 's more JS and it becomes tricky. (Did someone mention 'security' as
well?)
Furthermore, there is (at least in Central Europe) a huge lack of good training. There are
commercial training courses, but those that I've found around where I live are all beginners
courses covering the first chapters in the llama. Which is good, but not enough.
Because after the introduction course, my colleagues ask me how to proceed. When I tell them
to go on-line, read books and otherwise participate, they are unhappy. Yes, many of them
still haven't really learnt how to take advantage of the 'Net. And yes again, not enough
people (fewer and fewer?) appreciates to RTFM. They all want quick solutions. And no,
they don't appreciate to spend their evenings reading the Cookbook or the Camel. (Some odd
colleagues, I admit. ;-)
You can repeatedly have quick solutions using Perl, but that requires efforts to
learn. And this learning stage (where I'm still at) is not quick if you need to do
something big .
Too many people (around where I make my living) want quick solutions to everything with no
or little investment.
(Do I sound old? Yeah, I guess I am. That's how you become after 20+ years in this business.
;-)
Conclusion: In my shop, the middle management are worried what will happen if I
leave.
Questions like: " Who will take over all this Perl stuff? " and " How can we get a
new colleague up to speed on this Perl thingy within a week or two? " are commonplace
here. Which in a way creates a resistance.
I'd say: Momentum! When there is a hord of Perl programmers available the middle
management will sleep well during the nights. (At least concerning "The Perl Problem".
;-)
I'm working very hard to create the momentum that is necessary in our shop and I hope you
do the same . ( Biker points a finger at the reader.)
I agree with most of this, but a major problem that I have noticed is that with the recent
'dot.gone burn', the (job) market is literally flooded with experienced Perl programmers, but
there are no positions for them. Mostly this is due to Perl being free. To learn C++, C#,
Java you've got to spend a lot of money. Courses do not come cheap, the software doesn't come
cheap and certification (where it is offered) isn't cheap.
However, if anybody with just programming knowledge in anything from BASIC upwards and the
willingness to learn can get hold for software that is free to use, free to download, free to
'learn by example' (the quickest and easiest way to learn IMHO) - you can probably have a
Perl programmer that can make a basic script in next to no time. He runs his own website off it and other scripts he wrote,
learns, looks at other scripts and before you know it, he's writing a complete Intranet based
Management Information System
in it... If that person had to get C++, learn by reading books and going to courses (and the
associated costs - there isn't that much code available to read and learn by), it would have
taken so much longer and if you are on a budget - it isn't an option.
Compare Linux+MySQL+Apache+Perl to (shudder) Windows 2000 Advanced Server+MS SQL
Server+IIS+ASP. Which costs a lot more in the set up costs, staff costs and maintenance. Let
alone security holes? But which do big corporations go for (even though ever techy knows
which is the best one to go for). Why? Because 'oh, things are free for a reason - if we've
got to pay lots of money for it it has got to be damn good - just look at all those ASP
programmers asking 60,000UKP upwards, it must be good if they are charging that much'.
All in all, if Perl6+ had a license fee charge for it and a 'certification' was made
available AND Perl programmers put up their 'minimum wage', Perl would take off again big
time. Of course, it's all IMHO, but you did ask for my opinion :-)
If you really think that by asking money and shutting up Perl, you would make it more
popular and profitable, then I challenge you to go out and try to do it.
If you read the licensing terms, you can take Perl, take advantage of the artistic
license, rename it slightly, and make your own version which can be proprietary if you
want. (See oraperl and sybperl for examples where this was done with Perl 4.)
My prediction based on both theory and observation of past examples (particularly
examples of what people in the Lisp world do wrong time after time again) is that you will
put in a lot of energy, lose money, and never achieve popularity. For some of the theory,
the usually referred to starting place is The Cathedral and the Bazaar
.
Of course if you want to charge money for something and can get away with it, go ahead.
No less than Larry Wall has said that, It's almost like we're doing Windows users a
favor by charging them money for something they could get for free, because they get
confused otherwise. But I think that as time goes by it is becoming more mainstream to
accept that it is possible for software to be both free and good at the same time.
I know, but that's how head of departments and corporate management think: these are the
people that believe the FUD that Microsoft put out ('XP is more secure - we best get it
then', never mind that Linux is more secure and the Windows 2000 machines are also secure).
Sometimes it's just the brand name which also helps - I know of a certain sausage
manufacture who makes sausages for two major supermarkets. People say 'Oh, that's from
Supermarket X' upon tasting, although it is just the same sausage.
All in all - it comes down to packaging. 'Tart' something up by packaging, brand names
and high prices are, despite the rival product being better in every respect, the 'well
packaged' product will win.
The author pays outsize attention to superficial things like popularity with particular
groups of users. For sysadmin this matter less then the the level of integration with the underling
OS and the quality of the debugger.
The real story is that Python has less steep initial learning curve and that helped to entrenched
it in universities. Students brought it to large companies like Red Hat. The rest is history. Google support also was a positive factor.
Python also basked in OO hype. So this is more widespread language now much like Microsoft
Basic. That does not automatically makes it a better language in sysadmin domain.
The phase " Perl's quirky stylistic conventions, such as using $ in front to declare
variables, are in contrast for the other declarative symbol $ for practical programmers today–the
money that goes into the continued development and feature set of Perl's frenemies such as Python
and Ruby." smells with "syntax junkie" mentality. What wrong with dereferencing using $ symbol?
yes it creates problem if you are using simultaneously other languages like C or Python, but for
experienced programmer this is a minor thing. Yes Perl has some questionable syntax choices so so
are any other language in existence. While painful, it is the semantic and "programming
environment" that mater most.
My impression is that Perl returned to its roots -- migrated back to being an
excellent sysadmin tool -- as there is strong synergy between Perl and Unix shells. The fact
that Perl 5 is reasonably stable is a huge plus in this area.
Notable quotes:
"... By the late 2000s Python was not only the dominant alternative to Perl for many text parsing tasks typically associated with Perl (i.e. regular expressions in the field of bioinformatics ) but it was also the most proclaimed popular language , talked about with elegance and eloquence among my circle of campus friends, who liked being part of an up-and-coming movement. ..."
"... Others point out that Perl is left out of the languages to learn first –in an era where Python and Java had grown enormously, and a new entrant from the mid-2000s, Ruby, continues to gain ground by attracting new users in the web application arena (via Rails ), followed by the Django framework in Python (PHP has remained stable as the simplest option as well). ..."
"... In bioinformatics, where Perl's position as the most popular scripting language powered many 1990s breakthroughs like genetic sequencing, Perl has been supplanted by Python and the statistical language R (a variant of S-plus and descendent of S , also developed in the 1980s). ..."
"... By 2013, Python was the language of choice in academia, where I was to return for a year, and whatever it lacked in OOP classes, it made up for in college classes. Python was like Google, who helped spread Python and employed van Rossum for many years. Meanwhile, its adversary Yahoo (largely developed in Perl ) did well, but comparatively fell further behind in defining the future of programming. Python was the favorite and the incumbent; roles had been reversed. ..."
"... from my experience? Perl's eventual problem is that if the Perl community cannot attract beginner users like Python successfully has ..."
"... The fact that you have to import a library, or put up with some extra syntax, is significantly easier than the transactional cost of learning a new language and switching to it. ..."
"... MIT Python replaced Scheme as the first language of instruction for all incoming freshman, in the mid-2000s ..."
I first heard of Perl when I was in middle school in the early
2000s. It was one of the world's most versatile programming languages, dubbed the
Swiss army knife of the Internet.
But compared to its rival Python, Perl has faded from popularity. What happened to the web's most
promising language? Perl's low entry barrier compared to compiled, lower level language alternatives
(namely, C) meant that Perl attracted users without a formal CS background (read: script kiddies
and beginners who wrote poor code). It also boasted a small group of power users ("hardcore hackers")
who could quickly and flexibly write powerful, dense programs that fueled Perl's popularity to a
new generation of programmers.
A central repository (the Comprehensive Perl Archive Network, or
CPAN ) meant that for every person who wrote code,
many more in the Perl community (the
Programming Republic of Perl
) could employ it. This, along with the witty evangelism by eclectic
creator Larry Wall , whose interest in
language ensured that Perl led in text parsing, was a formula for success during a time in which
lots of text information was spreading over the Internet.
As the 21st century approached, many pearls of wisdom were wrought to move and analyze information
on the web. Perl did have a learning curve–often meaning that it was the third or fourth language
learned by adopters–but it sat at the top of the stack.
"In the race to the millennium, it looks like C++ will win, Java will place, and Perl will show,"
Wall said in the third State of Perl address in 1999. "Some of you no doubt will wish we could erase
those top two lines, but I don't think you should be unduly concerned. Note that both C++ and Java
are systems programming languages. They're the two sports cars out in front of the race. Meanwhile,
Perl is the fastest SUV, coming up in front of all the other SUVs. It's the best in its class. Of
course, we all know Perl is in a class of its own."
Then Python came along. Compared to Perl's straight-jacketed scripting, Python was a lopsided
affair. It even took after its namesake, Monty Python's Flying Circus. Fittingly, most of Wall's
early references to Python were lighthearted jokes at its expense. Well, the millennium passed, computers
survived Y2K , and
my teenage years came and went. I studied math, science, and humanities but kept myself an arm's
distance away from typing computer code. My knowledge of Perl remained like the start of a new text
file: cursory , followed by a lot of blank space to fill up.
In college, CS friends at Princeton raved about Python as their favorite language (in spite of
popular professor
Brian
Kernighan on campus, who helped popularize C). I thought Python was new, but I later learned
it was around when I grew up as well,
just not visible on the
charts.
By the late 2000s Python was not only the dominant alternative to Perl for many text parsing tasks
typically associated with Perl (i.e.
regular expressions
in the field of
bioinformatics
) but it was also the
most proclaimed popular language
, talked about with elegance and eloquence among my circle of
campus friends, who liked being part of an up-and-coming movement.
Despite Python and Perl's
well documented rivalry
and design decision differences–which persist to this day–they occupy a similar niche in the
programming ecosystem. Both are frequently referred to as "scripting languages," even though later
versions are retro-fitted with object oriented programming (OOP) capabilities.
Stylistically, Perl and Python have different philosophies. Perl's best known mottos is "
There's
More Than One Way to Do It ". Python is designed to have one obvious way to do it. Python's construction
gave an advantage to beginners: A syntax with more rules and stylistic conventions (for example,
requiring whitespace indentations for functions) ensured newcomers would see a more consistent set
of programming practices; code that accomplished the same task would look more or less the same.
Perl's construction favors experienced programmers: a more compact, less verbose language with built-in
shortcuts which made programming for the expert a breeze.
During the dotcom era and the tech recovery of the mid to late 2000s, high-profile websites and
companies such as
Dropbox
(Python) and Amazon and
Craigslist
(Perl), in addition to some of the world's largest news organizations (
BBC ,
Perl ) used
the languages to accomplish tasks integral to the functioning of doing business on the Internet.
But over the course of the last
15 years , not only how companies do business has changed and grown, but so have the tools they
use to have grown as well,
unequally to the
detriment of Perl. (A growing trend that was identified in the last comparison of the languages,
" A Perl
Hacker in the Land of Python ," as well as from the Python side
a Pythonista's evangelism aggregator
, also done in the year 2000.)
Today, Perl's growth has stagnated. At the Orlando Perl Workshop in 2013, one of the talks was
titled "
Perl is not Dead, It is a Dead End
," and claimed that Perl now existed on an island. Once Perl
programmers checked out, they always left for good, never to return.
Others
point out that Perl is
left out of the languages to learn first
–in an era where Python and Java had grown enormously,
and a new entrant from the mid-2000s, Ruby, continues to gain ground by attracting new users in the
web application arena (via Rails ), followed
by the Django framework in Python (PHP
has remained stable as the simplest option as well).
In bioinformatics, where Perl's position as the most popular scripting language powered many 1990s
breakthroughs like genetic sequencing, Perl has been supplanted by Python and the statistical language
R (a variant of S-plus and descendent of
S , also
developed in the 1980s).
In scientific computing, my present field, Python, not Perl, is the open source overlord, even
expanding at Matlab's expense (also a
child of the 1980s
, and similarly retrofitted with
OOP abilities
). And upstart PHP grew in size
to the point where it is now arguably the most common language for web development (although its
position is dynamic, as Ruby
and Python have quelled PHP's dominance and are now entrenched as legitimate alternatives.)
While Perl is not in danger of disappearing altogether, it
is in danger of
losing cultural relevance , an ironic fate given Wall's love of language. How has Perl become
the underdog, and can this trend be reversed? (And, perhaps more importantly, will
Perl 6 be released!?)
Why Python , and not Perl?
Perhaps an illustrative example of what happened to Perl is my own experience with the language.
In college, I still stuck to the contained environments of Matlab and Mathematica, but my programming
perspective changed dramatically in 2012. I realized lacking knowledge of structured computer code
outside the "walled garden" of a desktop application prevented me from fully simulating hypotheses
about the natural world, let alone analyzing data sets using the web, which was also becoming an
increasingly intellectual and financially lucrative skill set.
One year after college, I resolved to learn a "real" programming language in a serious manner:
An all-in immersion taking me over the hump of knowledge so that, even if I took a break, I would
still retain enough to pick up where I left off. An older alum from my college who shared similar
interests–and an experienced programmer since the late 1990s–convinced me of his favorite language
to sift and sort through text in just a few lines of code, and "get things done": Perl. Python, he
dismissed, was what "what academics used to think." I was about to be acquainted formally.
Before making a definitive decision on which language to learn, I took stock of online resources,
lurked on PerlMonks , and acquired several used
O'Reilly books, the Camel
Book and the Llama Book
, in addition to other beginner books. Yet once again,
Python reared its head , and
even Perl forums and sites
dedicated to the language were lamenting
the
digital siege their language was succumbing to . What happened to Perl? I wondered. Ultimately
undeterred, I found enough to get started (quality over quantity, I figured!), and began studying
the syntax and working through examples.
But it was not to be. In trying to overcome the engineered flexibility of Perl's syntax choices,
I hit a wall. I had adopted Perl for text analysis, but upon accepting an engineering graduate program
offer, switched to Python to prepare.
By this point, CPAN's enormous
advantage had been whittled away by ad hoc, hodgepodge efforts from uncoordinated but overwhelming
groups of Pythonistas that now assemble in
Meetups , at startups, and on
college and
corporate campuses
to evangelize the Zen of Python . This has created a lot of issues with importing (
pointed out by Wall
), and package download synchronizations to get scientific computing libraries (as I found),
but has also resulted in distributions of Python such as
Anaconda that incorporate
the most important libraries besides the standard library to ease the time tariff on imports.
As if to capitalize on the zeitgiest, technical book publisher O'Reilly
ran this ad , inflaming
Perl devotees.
By 2013, Python was the language of choice in academia, where I was to return for a year, and
whatever it lacked in OOP classes, it made up for in college classes. Python was like Google, who
helped spread Python and
employed van Rossum
for many years. Meanwhile, its adversary Yahoo (largely developed in
Perl
) did well, but comparatively fell further behind in defining the future of programming.
Python was the favorite and the incumbent; roles had been reversed.
So after six months of Perl-making effort, this straw of reality broke the Perl camel's back and
caused a coup that overthrew the programming Republic which had established itself on my laptop.
I sheepishly abandoned the llama
. Several weeks later, the tantalizing promise of a
new MIT edX course
teaching general CS principles in Python, in addition to
numerous n00b examples , made Perl's
syntax all too easy to forget instead of regret.
Measurements of the popularity of programming languages, in addition to friends and fellow programming
enthusiasts I have met in the development community in the past year and a half, have confirmed this
trend, along with the rise of Ruby in the mid-2000s, which has also eaten away at Perl's ubiquity
in stitching together programs written in different languages.
While historically many arguments could explain away any one of these studies–perhaps Perl programmers
do not cheerlead their language as much, since they are too busy productively programming. Job listings
or search engine hits could mean that a programming language has many errors and issues with it,
or that there is simply a large temporary gap between supply and demand.
The concomitant picture, and one that many in the Perl community now acknowledge, is that Perl
is now essentially a second-tier language, one that has its place but will not be the first several
languages known outside of the Computer Science domain such as Java, C, or now Python.
I believe
Perl has a future
, but it could be one for a limited audience. Present-day Perl is more suitable
to users who have
worked with the language from its early days
, already
dressed to impress
. Perl's quirky stylistic conventions, such as using $ in front to declare
variables, are in contrast for the other declarative symbol $ for practical programmers today–the
money that goes into the continued development and feature set of Perl's frenemies such as Python
and Ruby. And the high activation cost of learning Perl, instead of implementing a Python solution.
Ironically, much in the same way that Perl jested at other languages, Perl now
finds
itself at the receiving
end .
What's wrong
with Perl , from my experience? Perl's eventual problem is that if the Perl community cannot
attract beginner users like Python successfully has, it runs the risk of become like Children of Men
, dwindling away to a standstill; vast repositories of hieroglyphic code looming in sections
of the Internet and in data center partitions like the halls of the Mines of
Moria . (Awe-inspiring
and historical? Yes. Lively? No.)
Perl 6 has been an ongoing
development since 2000. Yet after 14 years it is not officially done
, making it the equivalent of Chinese Democracyfor Guns N'
Roses. In Larry Wall's words
: "We're not trying to make Perl a better language than C++, or Python, or Java, or JavaScript.
We're trying to make Perl a better language than Perl. That's all." Perl may be on the same self-inflicted
path to perfection as Axl Rose, underestimating not others but itself. "All" might still be too much.
Absent a game-changing Perl release (which still could be "too little, too late") people who learn
to program in Python have no need to switch if Python can fulfill their needs, even if it is widely
regarded as second or third best in some areas. The fact that you have to import a library, or put
up with some extra syntax, is significantly easier than the transactional cost of learning a new
language and switching to it. So over time, Python's audience stays young through its gateway strategy
that van Rossum himself pioneered,
Computer Programming for Everybody
. (This effort has been a complete success. For example, at MIT
Python replaced Scheme as
the first language of instruction for all incoming freshman, in the mid-2000s.)
Python continues to gain footholds one by one in areas of interest, such as visualization (where
Python still lags behind other language graphics, like Matlab, Mathematica, or
the recent d3.js
), website creation (the Django framework is now a mainstream choice), scientific
computing (including NumPy/SciPy), parallel programming (mpi4py with CUDA), machine learning, and
natural language processing (scikit-learn and NLTK) and the list continues.
While none of these efforts are centrally coordinated by van Rossum himself, a continually expanding
user base, and getting to CS students first before other languages (such as even Java or C), increases
the odds that collaborations in disciplines will emerge to build a Python library for themselves,
in the same open source spirit that made Perl a success in the 1990s.
As for me? I'm open to returning to Perl if it can offer me a significantly different experience
from Python (but "being frustrating" doesn't count!). Perhaps Perl 6 will be that release. However,
in the interim, I have heeded the advice of many others with a similar dilemma on the web. I'll just
wait and C .
27 Answers Dan Lenski , I do all my
best thinking in Python, and I've written a lot of it
Updated Jun 1 2015 Though I may get flamed for it, I will put it even more bluntly than
others have: Python is better than Perl . Python's syntax is cleaner, its
object-oriented type system is more modern and consistent, and its libraries are more
consistent. ( EDIT: As Christian Walde points out in the comments,
my criticism of Perl OOP is out-of-date with respect to the current de facto standard of
Moo/se. I do believe that Perl's utility is still encumbered by historical baggage in this area
and others.)
I have used both languages extensively for both professional work and personal projects
(Perl mainly in 1999-2007, Python mainly since), in domains ranging from number crunching (both
PDL and NumPy are excellent) to web-based programming (mainly with Embperl and Flask ) to good ol' munging text files and database CRUD
Both Python and Perl have large user communities including many programmers who are far more
skilled and experienced than I could ever hope to be. One of the best things about Python is
that the community generally espouses this
aspect of "The Zen of Python"
Python's philosophy rejects the Perl " there is more than one way
to do it " approach to language design in favor of "there should be one!and preferably
only one!obvious way to do it".
... while this principle might seem stultifying or constraining at first, in practice it means
that most good Python programmers think about the principle of least surprise
and make it easier for others to read and interface with their code.
In part as a consequence of this discipline, and definitely because of Python's strong typing , and
arguably because of its "cleaner" syntax, Python code is considerably easier to read
than Perl code. One of the main events that motivated me to switch was the experience of
writing code to automate lab equipment in grad school. I realized I couldn't read Perl code I'd
written several months prior, despite the fact that I consider myself a careful and consistent
programmer when it comes to coding style ( Dunning–Kruger effect , perhaps?
:-P).
* For example, the one-liner perl bak pe 's/foo/bar/g' *. txt will go through a
bunch of text files and replace foo with bar everywhere while making
backup files with the bak extension.
whenever you have to write a quick and dirty script that uses regular expressions or that
executes system commands. Perl has been designed for automating operations on files and file
systems; in fact, in perl to use regular expressions or to call system commands you don't
need to import anything, while in python, you need to import a library to do these
operations.
perl programmers usually adopt the Unix Philosophy of " Make one tool that does only one specific
task ". This is the reason why most perl script don't even include functions, not to
speak of objects. Each perl script must be written in order to execute a single task, and
then the scripts are piped together through the Unix piping system. However, consider that
this approach can lead to a lot of confusion, and is generally difficult to mantain.
Moreover, you can do "One tool one task" in python, too; the only difference is that you will
have to import sys in every script.
whenever you need to use a library available only for perl. Have a look at the modules in
CPAN . I think that BioPerl is still
slightly more complete than BioPython, and that there are more bioinformatics-oriented
modules for perl than for python (unfortunately). The Ensembl APIs are also available only
for perl.
When to use python:
whenever you need to use the script more than once.
whenever there is a even remote possibility that one of your colleagues or someone else
will ever use your script.
whenever you need to use functions or objects. As I was saying before, the majority of
perl scripts don't even include functions, because they are more difficult to write than in
python. For example, in perl, you need to learn how to pass the reference to a variable,
etc.. and this leads to scripts that are more difficult to understand (in perl).
if this is the first programming language you are learning, I suggest you to start with
Python. Python is much cleaner than Perl, and is designed to respect some good practices that
any programmer should know. Have a look at the Python Zen for some ideas.
Edit after 5 years:
Python has now support for tabular-like data structure (data frames), which are very
important for data analysts. Use Python or R whenever you have to work with tables
Python has now excellent support for machine learning algorithms and data analysis in
general. Use Python or R whenever you need to do one of these things.
I think very few people are completely agnostic about programming languages especially when
it comes to languages with very similar strengths and weaknesses like: perl/python/ruby -
therefore there is no general reason for using one language vs the other.
It is more common to find someone equally proficient in C and perl, than say equally
proficient in perl and python. My guess would be that complementary languages require
complementary skill sets that occupy different parts of the brain, whereas similar concepts
will clash more easily.
You are totally correct with your initial assumption. This question is similar to choosing
between Spanish and English, which language to choose? Well if you go to Spain,...
All (programming) languages are equal, in the sense of that you can solve the same class of
problems with them. Once you know one language, you can easily learn all imperative languages.
Use the language that you already master or that suits your style. Both (Perl & Python) are
interpreted languages and have their merits. Both have extensive Bio-libraries, and both have
large archives of contributed packages.
An important criterion to decide is the availability of rich, stable, and well maintained
libraries. Choose the language that provides the library you need. For example, if you want to
program web-services (using SOAP not web-sites), you better use Java or maybe C#.
Conclusion: it does no harm to learn new languages. And no flame wars please.
ADD COMMENT
• link modified 5.8
years ago • written 5.8 years ago by Michael Dondrup ♦ 42k
What is the Josephus problem? To quote from Concepts, Techniques, and Models of Computer
Programming (a daunting title if ever there was one):
Flavius Josephus was a roman historian of Jewish origin. During the Jewish-Roman wars of
the first century AD, he was in a cave with fellow soldiers, 40 men in all, surrounded by
enemy Roman troops. They decided to commit suicide by standing in a ring and counting off
each third man. Each man so designated was to commit suicide...Josephus, not wanting to die,
managed to place himself in the position of the last survivor.
In the general version of the problem, there are n soldiers numbered from 1 to
n and each k -th soldier will be eliminated. The count starts from the first
soldier. What is the number of the last survivor?
I decided to model this situation using objects in three different scripting
languages, Perl, Ruby, and Python. The solution in each of the languages is similar. A Person
class is defined, which knows whether it is alive or dead, who the next person in the circle
is, and what position number it is in. There are methods to pass along a kill signal, and to
create a chain of people. Either of these could have been implemented using iteration, but I
wanted to give recursion a whirl, since it's tougher on the languages. Here are my results.
Most people are surprised when I tell them what language we use in our undergraduate AI programming class. That's understandable.
We use GAWK. GAWK, Gnu's version of Aho, Weinberger, and Kernighan's old pattern scanning language isn't even viewed as a programming
language by most people. Like PERL and TCL, most prefer to view it as a "scripting language." It has no objects; it is not functional;
it does no built-in logic programming. Their surprise turns to puzzlement when I confide that (a) while the students are allowed
to use any language they want; (b) with a single exception, the best work consistently results from those working in GAWK. (footnote:
The exception was a PASCAL programmer who is now an NSF graduate fellow getting a Ph.D. in mathematics at Harvard.) Programmers in
C, C++, and LISP haven't even been close (we have not seen work in PROLOG or JAVA).
The classic paper by designer of TCL. Highly recommended
...Scripting languages such as Perl and Tcl represent a very different style of programming than system
programming languages such as C or Java. Scripting languages are designed for "gluing" applications; they use typeless approaches
to achieve a higher level of programming and more rapid application development than system programming languages. Increases
in computer speed and changes in the application mix are making scripting languages more and more important for applications of the
future.
...Scripting languages and system programming languages are complementary, and most major computing
platforms since the 1960's have provided both kinds of languages. The languages are typically used together in component frameworks,
where components are created with system programming languages and glued together with scripting languages. However, several recent
trends, such as faster machines, better scripting languages, the increasing importance of graphical user interfaces and component
architectures, and the growth of the Internet, have greatly increased the applicability of scripting languages. These trends
will continue over the next decade, with more and more new applications written entirely in scripting languages and system programming
languages used primarily for creating components.
...The second difference between assembly language and system programming languages is typing. I use
the term "typing" to refer to the degree to which the meaning of information is specified in advance of its use. In a strongly typed
language the programmer declares how each piece of information will be used and the language prevents the information from being
used in any other way. In a weakly typed language there are no a priori restrictions on how information can be used: the
meaning of information is determined solely by the way it is used, not by any initial promises
...Scripting languages such as Perl, Python, Rexx, Tcl, Visual Basic, and the Unix shells represent
a very different style of programming than system programming languages. Scripting languages assume that there already exists
a collection of useful components written in other languages. Scripting languages aren't intended for writing
applications from scratch; they are intended primarily for plugging together components. For example, Tcl and Visual Basic can be
used to arrange collections of user interface controls on the screen, and Unix shell scripts are used to assemble filter programs
into pipelines. Scripting languages are often used to extend the features of components but they are rarely used for complex algorithms
and data structures; features like these are usually provided by the components. Scripting languages are sometimes referred to as
glue languages or system integration languages.
In order to simplify the task of connecting components, scripting languages tend to be typeless:
all things look and behave the same so that they are interchangeable. For example, in Tcl or Visual Basic a variable can
hold a string one moment and an integer the next. Code and data are often interchangeable, so that a program can write another program
and then execute it on the fly. Scripting languages are often string-oriented, since this provides a uniform representation for many
different things.
The strongly typed nature of system programming languages discourages reuse. Typing encourages
programmers to create a variety of incompatible interfaces ("interfaces are good; more interfaces are better"). Each interface
requires objects of specific types and the compiler prevents any other types of objects from being used with the interface, even
if that would be useful. In order to use a new object with an existing interface, conversion code must be written to translate
between the type of the object and the type expected by the interface. This in turn requires recompiling part or all of the application,
which isn't possible in the common case where the application is distributed in binary form.
...It might seem that the typeless nature of scripting languages could allow errors to go undetected,
but in practice scripting languages are just as safe as system programming languages. For example, an error will occur if the font
size specified for the button example above is a non-integer string such as xyz.
The difference is that scripting languages do their error checking at the last possible moment, when a value is used. Strong typing
allows errors to be detected at compile-time, so the cost of run-time checks is avoided. However, the price to be paid for this efficiency
is restrictions on how information can be used: this results in more code and less flexible programs.
...Scripting languages are less efficient than system programming languages, in part because they use
interpreters instead of compilers but also because their basic components are chosen for power and ease of use rather than an efficient
mapping onto the underlying hardware. For example, scripting languages often use variable-length strings in situations where a system
programming language would use a binary value that fits in a single machine word, and scripting languages often use hash tables where
system programming languages use indexed arrays.
Scripting languages are higher level than system programming languages, in the sense that a single statement
does more work on average. A typical statement in a scripting language executes hundreds or thousands of machine instructions, whereas
a typical statement in a system programming language executes about five machine instructions. Part of this difference is because
scripting languages use interpreters, which are less efficient than the compiled code for system programming languages. But much
of the difference is because the primitive operations in scripting languages have greater functionality. For example, in Perl it
is about as easy to invoke a regular expression substitution as it is to invoke an integer addition. In Tcl, a variable can have
traces associated with it so that setting the variable causes side effects; for example, a trace might be used to keep the variable's
value updated continuously on the screen.
A scripting language is not a replacement for a system programming language or vice versa. Each is suited
to a different set of tasks. For gluing and system integration, applications can be developed 5-10x faster with a scripting language;
system programming languages will require large amounts of boilerplate and conversion code to connect the pieces, whereas this can
be done directly with a scripting language. For complex algorithms and data structures, the strong typing of a system programming
language makes programs easier to manage. Where execution speed is key, a system programming language can often run 10-20x faster
than a scripting language because it makes fewer run-time checks.
Most of the major computing platforms over the last 30 years have provided both system programming and
scripting languages. For example, one of the first scripting languages, albeit a crude one, was JCL (Job Control Language), which
was used to sequence job steps in OS/360. The individual job steps were written in PL/1, Fortran, or assembler language, which were
the system programming languages of the day. In the Unix machines of the 1980's, C was used for system programming and shell programs
such as sh and csh
for scripting. In the PC world of the 1990's, C and C++ are used for system programming and Visual Basic for scripting. In the Internet
world that is taking shape now, Java is used for system programming and languages such as JavaScript, Perl, and Tcl are used for
scripting.
Scripting languages have existed for a long time, but in recent years several factors have combined
to increase their importance. The most important factor is a shift in the application mix towards gluing applications. Three examples
of this shift are graphical user interfaces, the Internet, and component frameworks.
The third example of scripting-oriented applications is component frameworks such as ActiveX, OpenDoc,
and JavaBeans. Although system programming languages work well for creating components, the task of assembling components into applications
is better suited to scripting. Without a good scripting language to manipulate the components, much of the power of a component framework
is lost. This may explain in part why component frameworks have been more successful on PCs (where Visual Basic provides a convenient
scripting tool) than on other platforms such as Unix/CORBA where scripting is not included in the component framework.
Another reason for the increasing popularity of scripting languages is improvements in scripting technology.
Modern scripting languages such as Tcl and Perl are a far cry from early scripting languages such as JCL. For example, JCL didn't
even provide basic iteration and early Unix shells didn't support procedures. Scripting technology is still relatively immature even
today. For example, Visual Basic isn't really a scripting language; it was originally implemented as a simple system programming
language, then modified to make it more suitable for scripting. Future scripting languages will be even better than those available
today.
One final reason for the increasing use of scripting languages is a change in the programmer community.
Twenty years ago most programmers were sophisticated programmers working on large projects. Programmers of that era expected to spend
several months to master a language and its programming environment, and system programming languages were designed for such programmers.
However, since the arrival of the personal computer, more and more casual programmers have joined the programmer community. For these
people, programming is not their main job function; it is a tool they use occasionally to help with their main job. Examples of casual
programming are simple database queries or macros for a spreadsheet. Casual programmers are not willing to spend months learning
a system programming language, but they can often learn enough about a scripting language in a few hours to write useful programs.
Scripting languages are easier to learn because they have simpler syntax than system programming languages and because they omit
complex features like objects and threads. For example, compare Visual Basic with Visual C++; few casual programmers would attempt
to use Visual C++, but many have been able to build useful applications with Visual Basic.
Scripting languages have been mostly overlooked by experts in programming languages and software engineering.
Instead, they have focused their attention on object-oriented system programming languages such as C++ and Java. Object-oriented
programming is widely believed to represent the next major step in the evolution of programming languages. Object-oriented features
such as strong typing and inheritance are often claimed to reduce development time, increase software reuse, and solve many other
problems including those addressed by scripting languages.
...How much benefit has object-oriented programming actually provided? Unfortunately I haven't seen
enough quantitative data to answer this question definitively. In my opinion objects provide only a modest benefit: perhaps a 20-30%
improvement in productivity but certainly not a factor of two, let alone a factor of 10. C++ now seems to be reviled as much as it
is loved, and some language experts are beginning to speak out against object-oriented programming
[2]. The rest of this section
explains why objects don't improve productivity in the dramatic way that scripting does, and it argues that the benefits of object-oriented
programming can be achieved in scripting languages.
...The reason why object-oriented programming doesn't provide a large improvement in productivity is
that it doesn't raise the level of programming or encourage reuse. In an object-oriented language such as C++ programmers still work
with small basic units that must be described and manipulated in great detail. In principle, powerful library packages could be developed,
and if these libraries were used extensively they could raise the level of programming. However, not many such libraries have come
into existence. The strong typing of most object-oriented languages encourages narrowly defined packages that are hard to reuse.
Each package requires objects of a specific type; if two packages are to work together, conversion code must be written to translate
between the types required by the packages.
Scripting languages, on the other hand, have actually generated significant software reuse. They use
a model where interesting components are built in a system programming language and then glued together into applications using the
scripting language. This division of labor provides a natural framework for reusability. Components are designed to be reusable,
and there are well-defined interfaces between components and scripts that make it easy to use components. For example, in Tcl the
components are custom commands implemented in C; they look just like the builtin commands so they are easy to invoke in Tcl scripts.
In Visual Basic the components are ActiveX extensions, which can be used by dragging them from a palette onto a form.
Scripting languages represent a different set of tradeoffs than system programming languages. They give
up execution speed and strength of typing relative to system programming languages but provide significantly higher programmer productivity
and software reuse. This tradeoff makes more and more sense as computers become faster and cheaper in comparison to programmers.
System programming languages are well suited to building components where the complexity is in the data structures and algorithms,
while scripting languages are well suited for gluing applications where the complexity is in the connections. Gluing tasks are becoming
more and more prevalent, so scripting will become an even more important programming paradigm in the next century than it is today.
I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford
style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important
to get all of the following characteristics right:
Simplicity -- the design must be simple, both in implementation and interface. It is more
important for the interface to be simple than the implementation.
Correctness -- the design must be correct in all observable aspects. Incorrectness is simply
not allowed.
Consistency -- the design must not be inconsistent. A design is allowed to be slightly
less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
Completeness -- the design must cover as many important situations as is practical. All
reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
I believe most people would agree that these are good characteristics. I will call the use of this
philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.
The worse-is-better philosophy is only slightly different:
Simplicity -- the design must be simple, both in implementation and interface. It is more
important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
Correctness -- the design must be correct in all observable aspects. It is slightly better
to be simple than correct.
Consistency -- the design must not be overly inconsistent. Consistency can
be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances
than to introduce either implementational complexity or inconsistency.
Completeness -- the design must cover as many important situations as is practical. All
reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact,
completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness
if simplicity is retained; especially worthless is consistency of interface.
Early Unix and C are examples of the use of this school of design, and I will call the use of this
design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that
it is obviously a bad philosophy and that the New Jersey approach is a bad approach.
However, I believe that worse-is-better, even in its strawman form, has better survival characteristics
than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.
The concept known as "worse is better" holds that in software making (and perhaps in other arenas
as well) it is better to start with a minimal creation and grow it as needed. Christopher Alexander might call this
"piecemeal growth." This is the story of the evolution of that concept.
From 1984 until 1994 I had a Lisp company called "Lucid, Inc." In 1989 it was clear that the Lisp
business was not going well, partly because the AI companies were floundering and partly because those AI companies were starting
to blame Lisp and its implementations for the failures of AI. One day in Spring 1989, I was sitting out on the Lucid porch with some
of the hackers, and someone asked me why I thought people believed C and Unix were better than Lisp. I jokingly answered, "because,
well, worse is better." We laughed over it for a while as I tried to make up an argument for why something clearly lousy could be
good.
A few months later, in Summer 1989, a small Lisp conference called EuroPAL (European Conference on
the Practical Applications of Lisp) invited me to give a keynote, probably since Lucid was the premier Lisp company. I agreed, and
while casting about for what to talk about, I gravitated toward a detailed explanation of the worse-is-better ideas we joked about
as applied to Lisp. At Lucid we knew a lot about how we would do Lisp over to survive business realities as we saw them, and so the
result was called "Lisp: Good News, Bad News, How to Win Big." [html]
(slightly abridged version) [pdf] (has more
details about the Treeshaker and delivery of Lisp applications).
I gave the talk in March, 1990 at Cambridge University. I had never been to Cambridge (nor to Oxford),
and I was quite nervous about speaking at Newton's school. There were about 500-800 people in the auditorium, and before my talk
they played the Notting Hillbillies over the sound system - I had never heard the group before, and indeed, the album was not yet
released in the US. The music seemed appropriate because I had decided to use a very colloquial American-style of writing in the
talk, and the Notting Hillbillies played a style of music heavily influenced by traditional American music, though they were a British
band. I gave my talk with some fear since the room was standing room only, and at the end, there was a long silence. The first person
to speak up was Gerry Sussman, who largely ridiculed the talk, followed by Carl Hewitt who was similarly none too kind. I spent 30
minutes trying to justify my speech to a crowd in no way inclined to have heard such criticism - perhaps they were hoping for a cheerleader-type
speech.
I survived, of course, and made my way home to California. Back then, the Internet was just starting
up, so it was reasonable to expect not too many people would hear about the talk and its disastrous reception. However, the press
was at the talk and wrote about it extensively in the UK. Headlines in computer rags proclaimed "Lisp Dead, Gabriel States." In one,
there was a picture of Bruce Springsteen with the caption, "New Jersey Style," referring to the humorous name I gave to the worse-is-better
approach to design. Nevertheless, I hid the talk away and soon was convinced nothing would come of it.
About a year later we hired a young kid from Pittsburgh named Jamie Zawinski. He was not much more
than 20 years old and came highly recommended by Scott Fahlman. We called him "The Kid." He was a lot of fun to have around: not
a bad hacker and definitely in a demographic we didn't have much of at Lucid. He wanted to find out about the people at the company,
particularly me since I had been the one to take a risk on him, including moving him to the West Coast. His way of finding out was
to look through my computer directories - none of them were protected. He found the EuroPAL paper, and found the part about worse
is better. He connected these ideas to those of Richard Stallman, whom I knew fairly well since I had been a spokesman for the League
for Programming Freedom for a number of years. JWZ excerpted the worse-is-better sections and sent them to his friends at CMU, who
sent them to their friends at Bell Labs, who sent them to their friends everywhere.
Soon I was receiving 10 or so e-mails a day requesting the paper. Departments from several large companies
requested permission to use the piece as part of their thought processes for their software strategies for the 1990s. The companies
I remember were DEC, HP, and IBM. In June 1991, AI Expert magazine republished the piece to gain a larger readership in the US.
However, despite the apparent enthusiasm by the rest of the world, I was uneasy about the concept
of worse is better, and especially with my association with it. In the early 1990s, I was writing a lot of essays and columns for
magazines and journals, so much so that I was using a pseudonym for some of that work:
Nickieben Bourbaki. The original idea for the name was that
my staff at Lucid would help with the writing, and the single pseudonym would represent the collective, much as the French mathematicians
in the 1930s used "Nicolas Bourbaki" as their collective name while rewriting the foundations of mathematics in their image. However,
no one but I wrote anything under that name.
In the Winter of 1991-1992 I wrote an essay called "Worse
Is Better Is Worse" under the name "Nickieben Bourbaki." This piece attacked worse is better. In it, the fiction was created
that Nickieben was a childhood friend and colleague of Richard P. Gabriel, and as a friend and for Richard's own good, Nickieben
was correcting Richard's beliefs.
In the Autumn of 1992, the Journal of Object-Oriented Programming (JOOP) published a "rebuttal" editorial
I wrote to "Worse Is Better Is Worse" called "Is
Worse Really Better?" The folks at Lucid were starting to get a little worried because I would bring them review drafts of papers
arguing (as me) for worse is better, and later I would bring them rebuttals (as Nickieben) against myself. One fellow was seriously
nervous that I might have a mental disease.
In the middle of the 1990s I was working as a management consultant (more or less), and I became interested
in why worse is better really could work, so I was reading books on economics and biology to understand how evolution happened in
economic systems. Most of what I learned was captured in a presentation I would give back then, typically as a keynote, called "Models
of Software Acceptance: How Winners Win," and in a chapter called "Money
Through Innovation Reconsidered," in my book of essays, "Patterns of Software: Tales from the Software Community."
You might think that by the year 2000 I would have settled what I think of worse is better - after
over a decade of thinking and speaking about it, through periods of clarity and periods of muck, and through periods of multi-mindedness
on the issues. But, at OOPSLA 2000, I was scheduled to be on a panel entitled "Back to the Future: Is Worse (Still) Better?" And
in preparation for this panel, the organizer, Martine Devos, asked me to write a position paper, which I did, called "Back
to the Future: Is Worse (Still) Better?" In this short paper, I came out against worse is better. But a month or so later, I
wrote a second one, called "Back to the
Future: Worse (Still) is Better!" which was in favor of it. I still can't decide. Martine combined the two papers into the single
position paper for the panel, and during the panel itself, run as a fishbowl, participants routinely shifted from the pro-worse-is-better
side of the table to the anti-side. I sat in the audience, having lost my voice giving my Mob Software talk that morning, during
which I said, "risk-taking and a willingness to open one's eyes to new possibilities and a rejection of worse-is-better make an environment
where excellence is possible. Xenia invites the duende, which is battled daily because there is the possibility of failure in an
aesthetic rather than merely a technical sense."
The Programming Language Wars
Questions and Responsibilities for the Programming Language Community Andreas Stefik University of Nevada, Las Vegas, U.S.A. [email protected]
Stefan Hanenberg University of Duisburg-Essen, Germany
J. R. Mashey Using a command language as a high-level programming language
Pdf (925 KB) International Conference on Software Engineering
archive Proceedings of the 2nd international conference on Software engineering
table of contents San Francisco, California, United States Pages: 169 - 176 1976
Schwartz, Jacob T., "Set Theory as a Language for Program Specification and Programming". Courant Institute of Mathematical Sciences,
New York University, 1970. Later book The SETL Programming
Language by Dewar and Smosna is available.
The Last but not LeastTechnology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Alex Jones , works at Own My Own Business Answered January 12, 2020 · Author has 259 answers and 76.1K answer views
Tom Le , CSO • CISO • CTO | Security Expert Answered April 3, 2015
Avi Mehenwal , Ex-perl programmer, but still cannot let it go. I feel the RegEx Attachement Answered April 2, 2016 · Author has 64 answers and 226.8K answer views
Dave Cross , I make things with software. Answered October 1, 2014 · Author has 1.6K answers and 1.4M answer views
I should be working 16 hours ago remove link
mike_1010 17 hours ago (Edited)
Steve J , Software Engineer Answered November 4, 2017 · Author has 486 answers and 133.6K answer views Originally Answered: Why does Perl so hated and not commanly used? And why should I learn it?
Joachim Pense , Perl is my language of choice Answered November 4, 2017 · Author has 6.5K answers and 8M answer views
Michael Yousrie , A programmer, A Problem Solver Answered November 4, 2017 · Author has 82 answers and 169.1K answer views Originally Answered: Why does Perl so hated and not commanly used? And why should I learn it?
Randal L. Schwartz , Literally "wrote the books" on it Answered March 3, 2018 · Author has 109 answers and 105.1K answer views
Richard Conto , Programmer in multiple languages. Debugger in even more Answered December 18, 2017 · Author has 7K answers and 5.4M answer views
Pekka Järveläinen , studied at Tampere University of Technology Answered November 4, 2017
Reed White , former Engineer at Hewlett-Packard (1978-2000) Answered November 7, 2017 · Author has 3K answers and 695.9K answer views
Anonymous Answered May 2, 2020
Curt J. Sampson says: 7 OCTOBER 2019 AT 09:27
thehftguy says: 7 OCTOBER 2019 AT 13:51
dex4er says: 7 OCTOBER 2019 AT 15:59
anon says: 7 OCTOBER 2019 AT 16:40
Share this with your friends! From To Compose your message Share
Guest Python3kFTW • 6 years ago Docs.python.org is about the least most helpful documentation I've ever read. Want a simple example of something? Go elsewhere. If Sphinx is the tool responsible for the awful (the index doesn't scroll with the page - wfh?), the Sphinx is _not_ an excellent documentation tool.Where I do agree, though, is that Perl is truly, direly, appallingly awful. Oh, and I do (or did) know Perl. see more
Dan Lenski , I do all my best thinking in Python, and I've written a lot of it Updated Jun 1 2015 Though I may get flamed for it, I will put it even more bluntly than others have: Python is better than Perl . Python's syntax is cleaner, its object-oriented type system is more modern and consistent, and its libraries are more consistent. ( EDIT: As Christian Walde points out in the comments, my criticism of Perl OOP is out-of-date with respect to the current de facto standard of Moo/se. I do believe that Perl's utility is still encumbered by historical baggage in this area and others.)
PDF
