|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
Contents : Foreword : Ch01 : Ch02 : Ch03 : Ch04 : Ch05 : Ch06 : Ch07 : Ch08 :
Note: This is unpublished copyrighted material licensed under the Creative Commons Attribution-NoDerivs-NonCommercial License.
Prev | Up | Contents | Down | Next
|
|
All programming languages are essentially compilations. There have always been important programming languages that differ from mainstream ALGOL-style languages. For example Fortran was different and more suitable than Algol-style languages for numeric computations. One should see Perl as one of such non-Algol family languages suitable for text processing. Among important non-traditional precursors of Perl are:
Shell is inadequate for the second role. Perl was one of the first scripting languages that attempted to combine those two role under a single umbrella. As system integration language they go far beyond Unix shell and are closer to full-fledged programming languages. As for macro language the successes are more modest and one of the few successful applications with scripting support is Microsoft Office (which uses VB, but can use JavaScript via .Net). Previously OS/2 has had some level of success with using REXX as both shell and macrolanguage for applications.
Another problem with shell is scalability. Shell scripts are a very good
example of the initial stage of scripting languages development. But as scripts
became more complex shell became difficult to debug and maintain. Also for many
application such as CGI it never got any traction. Here Perl can fill the niche.
AWK was a really brilliant language at the moment of its creation.
But the desire to limit its role to a Unix utility prevented extending
language to fill the application automation role. AWK was probably second after Snobol a string processing language
that extensively use regular expressions. The first version was created in BellLabs
by Alfred V. Aho, Peter J. Weinberger, and Brian W. Keringhan in 1977. In 1985,
just before Perl, a new version made the programming language more powerful,
introducing user-defined functions, multiple input streams, and computed regular
expressions. It became generally available with System V Release 3.1. The version
in System V Release 4 added some new features and also cleaned up the behavior
in some of the ``dark corners'' of the language. The specification for AWK in
the POSIX Command Language and Utilities standard further extend and clarified
the language. The GNU implementation, gawk, was written in 1986 by Paul Rubin
and Jay Fenlason, with advice from Richard Stallman. John Woods contributed
parts of the code as well. In 1988 and 1989, David Trueman, with help from Arnold
Robbins, thoroughly reworked gawk for compatibility with the newer AWK (nawk).
REXX. REXX was to certain extent a parallel development to Perl.
It was included in the third release of IBM's VM/CMS shipped in 1983; the first
PC implementation was released in 1985. I do not know when the first Unix implementation
appeared, but anyway REXX on Unix was never widely used outside small group
of programmers that migrate to Unix from mainframes. REXX contain concept of
associative arrays much like hashes but in a very limited fashion (there is
no possibility to enumerate keys and values of the array, etc.). Like in Snobol
REXX arrays expand as necessary to accommodate new entries. As there was no
way to get all keys of the REXX array that looks clumsy. Perl provide more powerful
and convenient operations on hashes. At the same time REXX has one definite
advantage over Perl -- much like TCL REXX can serve and actually served as both
scripting and a macro language -- in fact both in VM/CMS and OS/2 several important
programs (for example XEDIT) use REXX as a macro language.
The TCL scripting
language grew out of work of
John Ousterhout
on creating the design tools for integrated circuits at the University of California
at Berkeley in the early 1980's. In the fall of 1987, while on sabbatical at
DEC's Western Research Laboratory, he decided to build an embeddable command
language. He started work on TCL in early 1988, and began using the first version
of TCL in a graphical text editor in the spring of 1988. The idea of TCL is
different and to certain extent more interesting than idea of Perl -- TCL was
designed as embeddable macro language for applications. In this sense TCL is
closer to REXX (which was probably was one of the first language that was used
both as a shell language and as a macrolanguage). Important products that use
TCL are TK toolkit and Expect. At the same time judging from Usenet
traffic TCL user community is three to ten times smaller than Perl community
-- again popularity is an important feature of the language -- nothing success
in this world like success.
When studying Perl you can feel that authors tried to break the ice
and get into new territory. They make many mistakes, but they
broke into new territory and explored it. When learning PHP it is clear
that the designers have no abilities to think clearly even about limited
domain of Web applications.
|
|
C compilers usually convert programs into machine language -- that means that executable is platform dependent. Perl does not produce any executable, but is closer to compiler model that one may think -- if you run a Perl program in interpreter, it's first compiled into bytecode, which is then converted (as the program runs) into machine instructions. So like Java, Perl does have an intermediate representation, but unlike Java you cannot get it separately.
It's somewhere in between traditional shells that does not have any intermediate format and Java that has well defined platform independent intermediate format (Java machine), There is a separate utility called the Perl Compiler, but reliability can be problem and actually one cannot get much speed improvement for such a complex language -- most features are functions calls anyway.
Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you've already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that's not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.
I come to Perl with some mainframe PL/1 (and REXX) programming background and was surprised that Perl emulated some PL/1 ideas (see below) despite the fact that Larry Wall definitely has no mainframe experience. And probably because of my positive experience with PL/1 (and especially with PL/1 compilers) I like complex, non-orthogonal expressive languages and unlike most people from academia do not share excessive excitement about ortogonality of programming languages.
IMHO programming languages should be more like Hamming Code : the most frequently used constructs should be made into very short special constructs. That idea, pioneered in C, actually is pretty foreign to the lovers of ortogonality in languages and all those "proof of program" stupidities that often linger in Pascal style languages. Actually due to my PL/1 background I do not regard C as a good multipurpose language. It's too low for this, although it is probably the first language that systematically tried to provide Humming code style design: shortcuts for the most frequently used operations.
Note such C idioms as i++; i+=2; and "compact" form of if statement: "(condition)?then-statement:else;". The value of C-language is based on the fact that it provides a very good abstraction of the instruction set for most popular modern CPUs. . That's why it managed to dominate system programming for more then 40 years. As C was derived from PL/1, it. lich like Unix itself, had thrown away some and valuable important PL/1 features like flexibility of its exception mechanism as well as the advantages of strings as a built-in class.
Even in the field of syntax PL/1 has features, that are not present even in modern C dialects. One example is multilevel closure of blocks with end statement that use suffix equal to the label on the most outer blocks. Here is one example:
outer: do;
.... ... ...
do;
... ... ...
do;
... ... ...
end outer; /* this end statement close all inner blocks with outer: do scope
In this sense Perl is much closer to PL/1 in philosophy: it is a complex non-orthogonal language with an excellent string processing capabilities and that's why I like it.
But at the same time I think that Perl designers did not completely understand PL/1 tradition which in some areas is more rich that we see in Perl. In some places where I like to write short expressive idioms Perl still provide unnecessary verbose solutions. Built-in function selection in Perl, including string functions selection looks to me raw and not quite thought out. There are "strange" like chop, chomp and tr that behave differently from other string handling functions like index and substr. Also there is a big discrepancy between string handling functions and array handling functions despite the fact that strings are essentially arrays of characters. This situation can be improved as Perl library of built-in functions can sill be enhanced and extended. For example, to compensate for badly designed functions chop, chomp REXX-style function trim can be used.
Like any scripting language and more than many other scripting languages Perl is a very high level language -- it hides details a particular structures and underscored the purpose of algorithms/data structures.
Many people complain about naming convention in Perl (prefixing certain typed of data structures with certain letters. But actually naming convention for variables in Perl can be considered as a kind of Hungarian notation and as such are not that bad even from a puritan view of classic academic language designer.
What is important is that Perl try to move in the right direction extending existing structures to add more power or flexibility or both. In many areas it succeeded. In some it failed. But all in all Perl is the most successful of the new breed of very high language and it generated a lot of following. Think about Python, PHP and Ruby as three prominent examples. In this sense Perl is as influential as Algol-60 was many years ago.
Also judging Perl we need to understand that it belongs to the family of complex non-orthogonal languages, the family that was started by PL/1 and successfully continued by Ada and later C++ (paradoxically C++ did not solve one of the key C language problem: difficulties of working with strings).
In some areas Perl gone too far and contains features that overcomplicated the language . One example that is often mentioned in this area is the postfix if statement. It doesn't add any new capability to the language, and it confuses new users. But reality is not as simple as academic view of programming languages constructs just expressed: for seasoned professionals it provides a convenient notation for an important special case -- writing exit conditions in loops. For example:
for $i=0; $i<$x; $i++ {
last if ($x[$i] eq $a);
}
So there is a general contradiction between ease of learning and ease of use by professionals. In Perl (in the best Unix tradition), compromise tends to favor professionals. And while we can criticize the language we need to understand the nature of this tradeoff: Perl was not designed for a casual users.
I also like the fact that Perl OO is an afterthought, not a principle like is Java. Isn't that the Perl way?
Language faults are logical continuation of their strong points. JavaScript has more clean syntax, is standardized and now supported by Microsoft in the form of JScript as a scripting language for ActiveX (actually Perl is also partially supported by Microsoft via investment in ActiveState). But Microsoft JavaScript implementation is well integrated into Windows (via scripting engine) and can (theoretically) used everywhere where VBA is used. On practice that does not happens.
Python is more academic and since version 2.4 supports coroutines. One of the best reasons I can think of for a Perl programmer to learn Python is simply the fact that it enriches your understanding of scripting languages and improves your understanding of Perl. Superficial minds even might leave Perl for Python, but in reality Perl is stronger and in key respects better scripting language despite its flaws. Like in people in programming languages flaws are often just a continuation of strong features, kind of inevitable externalities like economists used to say ;-). My expectation would be that there are good things about Python that are applicable outside Python. Determining what they are and adopting them (perhaps in a more Perlish fashion) should make a Perl programmer better over time.
Exposure to TCL is also very beneficial and this language provide cleanest and best interface to C (this was a design goal). It also enhance your understanding of Perl and usage of some more esoteric Perl constructs.
Generally exposure to other scripting language should be a part of Perl language training. After all, how many of us started using closures in Perl without seeing them first in something Lisp-like?
Of course, there are many things a Perl programmer will find disturbing about Python (The opposite is also true.)
Now, if Python really was Fred Brooke's silver bullet to slay the software engineering beast, I'd be shouting the word from the roof-tops. Python is does not significantly reduce the complexity of software development. "Cleaner" or more restrictive syntax may aid newbies, but it more likely hinders experienced programmers. Bad habits aside, there are usually more ways to express a solution correctly than a traditionally orthogonal language may lend itself to. B&D style tools like Java, which have an amazing paranoid class protection system, seem to implicitly doubt the ability of its users. Although there are probably good uses for it, "finalizing" a class to me is the height of arrogance. Better to say "none can improve on this fabled code!".
Paradoxically the most viable competitor among open source products in not Python as many think -- it's PHP. PHP is now running over a million web sites and with good reason. PHP is open source, it runs equally well on Windows and UNIX, is now supported in some Microsoft products such as Web expressions 4.0. It's well documented and has tremendous amount of published books, some of them good. PHP is no doubt had stolen most of the Perl market share in web-space, but the "open source media" has been unusually quiet about the issue.
|
The main competitor of Perl is not Java or Python, two major competitors are JavaScript and PHP |
A concept of "cognitive dissonance" exists in psychological literature. When mastering a new language first you face a level of "cognitive overload" until the quirks of the language become easily handled by your unconscious mind. At that point, cognitive dissonance disappears, and all of the sudden the quirky interaction becomes a "standard" way of performing the task. Once learned the quirks become incorporated into your understanding of the language.
One early sign of the disappearance of the cognitive dissonance in learning Perl is when you start to put $ on all scalar variables automatically, and overcome the notational difficulties of using different set of operations for numbers and strings ("==" and eq for equality, correspondingly ). The latter is remnant of shell and actually does not make much sense.
|
Perl uses "==" for numeric comparison and "eq" for string. This is a constant source of a number of difficult to find errors even for experienced programmers as most of them use several languages simultaneously. It is less a problem for system administrators as this is a convention similar to used in shell. While inherited from shell it is probably one of the most glaring "misfeatures" of Perl |
From the point of view of a computer scientist Perl is a rather strange language. It adopts what could be called "assembler-style approach to operators". Perl is probably the only high-level language in which like in assembler operation defines type of the operator. The buzz-word context is used in Perl literature for this particular feature. You will see the catch phrases scalar context, string context, numeric context pretty soon. That means that, like as assembler, the accidental use of wrong comparison operation leads to a subtle error that is difficult to detect. It is a design flaw similar to the controversial decision to consider statements to be expressions in C that lead to typical and nasty errors like accidental use of an assignment instead of a comparison in if statement ( if (a=1)... ) by beginners (and not only beginners ;-)
You to check your scripts against most common errors with some king of lint program (might be a custom one) and create special checklists for most common errors. Checklists in the chapters might help you but it is your own experience and idiosyncrasies that matter most.
The other useful advice for Perl programmer please is the famous KISS principle. Please be vary of using complex constructs -- diagnostic in Perl is not impressive and the beginner can easily shoot himself in the foot. A lot of Perl Gurus are addicted to complexity so treat their advice skeptically. Cutting addition dozen of bytes from the code is not always a noble goal :-).
Perl is a difficult language to master and it is oriented more of professionals then on novices. Exacerbating all problems with the language are the diagnostics the interpreter generate, which are sometimes cruelly misleading and often uninformative.
Complaints that something is wrong on line X can often mean that the error is several lines above or below. In no way one should rely on lines numbers that Perl interpreter included in the error message. Consider it as a very fuzzy pointer and search the vicinity.
You need to document your previous errors as people tend to commit the same types of errors again and again. This is even more typical for large, complex languages like Perl, when you often forget specific construct from one usage to another.
As the same time Perl has a great debugger (PHP used to have none -- another testament the quality of language).
A related problem is Perl's over-reliance on regular expressions that is exaggerated by advocating regex-based solution in almost all O'Reilly books. The latter until recently were the most authoritative source of published information about Perl.
While simple regular expression is a beautiful thing and can greatly simplify operations with strings, overcomplexity in regular expressions is extremely dangerous: it cannot serve a basis for serious, professional programming, it is fraught with pitfalls, a big semantic mess as a result of outgrowing its primary purpose. Diagnostic for errors in regular expressions is even weaker then for the language itself and here many things can just go unnoticed.
Unless you understand semantic of regular expressions well and is able to debug them, you should limit the complexity to the level at which you feel comfortable and not to jump over your head creating "one regular expression which solve the whole problem" type of mess. Complex regular expressions are the source of subtle bugs that are difficult to find even for people who wrote regular expression engines for living. But again, like sharp blade in skilled hands regex is a very powerful tool. Yes, you may cut yourself, but you can do the work quickly if you have necessary skills. Just don't overdo it in your programs.
This advice can be extended to other features of the language: remember about the KISS principle and try to use a particular feature in the simplest way possible. For example it's perfectly possible to write simple Perl scripts without complex regular expressions or the fancy OO idioms recommended by some Perl gurus.
|
Remember the KISS principle: it is vital for successful programming in Perl. |
PL/I style conversions-on-demand between arithmetic and string types adopted by Perl, lead to problems that are well known to seasoned PL/1 programmers -- everything is fine until Perl makes a wrong decision and then you end up searching for this error for a day or more that might wipe any economy achieved by the feature. After a couple of such errors one usually starts thinking about moving to another language, but this similar to cigarettes this Camel is addictive and few will ;-).
As I already noted the flaws in languages are logical continuations of their strongest points -- some are inherent to the language and beyond redemption, others could in theory be fixed, say in Perl 6...
Anyway, we must to live (and survive) in a far from perfect world. Unlike PL/1, Perl will never die just because simpler languages are available (PL/1 was mainly overrun by C and Pascal). WWW created a huge niche for complex non-orthogonal languages in which those who came first (and Perl was) preserve some niche presence long after they were overtaken by more lucky competitors. Perl provides an excellent level of integration with Unix, especially for the integration of classic Unix tools into the program. In this respect it is almost as convenient as shell. I'm a hard-core believer that by integrating components from several level, and especially from the OS utilities level (classic Unix tools), programs get simpler and take less time to create to maintain and modify.
|
Perl provides an excellent level of integration with Unix, especially as for usage of classic Unix tools. I'm a hard-core believer that by integrating components from several level, and especially from the OS utilities level (classic Unix tools), programs get simpler and take less time to create to maintain and modify. |
If somebody tries to teach Perl as the first language I do not envy the students. IMHO Perl should never be taught as the first language. See What's wrong with Perl for more information. I agree with most points but disagree with conclusion and prefer Perl to Python.
In general, what this means is that Perl is a large and complex language, which takes a long time to learn properly. In my opinion, this complexity is unnecessary and a simpler language would have been much better. I think this also means that many non-expert Perl developers write suboptimal code.
Another thing is that I think few Perl developers (percentage-wise) write general and reusable modules, because you need to learn the language well before doing so, something that is relatively hard and takes time. Another thing is that the language itself does not encourage this.
Perl's rise to prominence (as is true of all other popular languages) is to a certain extent accidental and is more of a result of being at the right place at right time. It is not directly connected with the quality of the language. The WEB tide raised all boats and it raised Perl much like it raised HTML, Javascript, PHP and Java. But after the language became popular this very fact became an extremely important "feature" of the language and should be considered as such. Nothing succeeds like success. The same situation exists with VB -- popularity is probably the most important feature of that language.
Situations in which a language is excessively complex become especially annoying when you need to learn and support several such languages: Bash/ksh, Perl, Java, C++, etc. Resistance is futile and most programmers who need to work in a Unix environment in fact end up having to learn at least a half-dozen half-baked languages. I use the term "half-baked" for the language without a standard -- in this sense Perl is half-baked. If you need to work on both Windows and Unix the situation is much worse, but most of Unix-based languages are now ported to Win32. Actually the ActiveState's Perl debugger for Win32 is better than any Perl debugger that exists for Unix. Bad thing is that even if you need to work in two environments you still have only one head.
| In the current overcomplicated environment the idea of minimizing your language collection is very important. In this sense Perl can be a very reasonable choice -- it is easier to learn this complex language than several simple and less universal Unix utilities that have the same functionality |
Some folks have argued that you should to use the "right language for the job" -- but with so many of them one cannot afford to divert too many resources into "treading water". Therefore minimizing your "language collection" is very important and here there is an important question of whether one needs to use Perl or Tcl or Python. It looks like the idea of PL/1 as a universal high level language now is much more realistic than before. One of Perl advantages is that it's pretty universal and can be used instead of a collection of several other scripting languages. The complexity and fuzziness are definite disadvantages, but power is an important advantage. In any case there is no free lunch. Perl looks ugly and smalls bad, but the other scripting language may be even worse.
What we need is to create a decent framework for Perl -- distinct from all this "Perl is similar to the natural languages" blah-blah-blah in which some Perl advocates are engaged. Perl has nothing to do with natural languages, and any specialist who claims otherwise can be considered a pure marketer.
|
Perl has nothing to do with natural languages and any specialist who claims otherwise can be considered a pure marketer |
Moreover, while it is a Unix language Perl breaks with Unix tradition -- it is a universal language and it is written in a language tradition represented by PL/1 and MS Office. Perl is the language that breaks with Unix tradition. And that's why in no case it should be your first language, Python or Javascript probably would be a better choice. Here is one interesting comment from Linux Today Perl.com Teaching Perl to First-Time Programmers that illustrates one typical problem with Perl:
Internet Dog - Subject: The example illustrate the contrary (Nov 19, 1999, 13:57:54 )The article state:
"For instance, the automatic conversion between string and numeric types is what non-programmers expect"
The automatic conversion "feature" of Perl should be considered a flaw. It allows silent errors to be missed. A newbie might expect the conversion to be automatic, but a skilled programmer will appreciate the problems that automatic silent type conversion can cause. The first time this occurs it is a simple matter to explain the difference between types. A good teaching language would flag the addition of unlike types as an error. The example assumes that other languages would interpret the string "3" as the numerical value of 51. This type of error can occur in a weakly typed language like C, but not in strongly typed languages. To compare Perl to C and state it is a good teaching language is to compare it to a straw dog. There are many other languages to consider for the role.
I like the Unix idea, of "hyper tools" the collection of small utilities cooperating to achieve tasks. But the problem is that one hundred simple tools, each with a dozen of slightly different one letter options are not that simple. It's actually a pretty complex "ad-hoc" language and far from being orthogonal meta language -- paradoxically the Unix tools collection became exact opposite of the initial idea. And Perl as an opposite approach is still simpler, it is a honest attempt to integrate as much functionality as possible into a single monstrous utility (like MS Office) and this integration make things more orthogonal. anyway, if you are a Unix fundamentalist please stop here -- you will be much better off using TCL.
I also reject the assumption that because some people have difficulties with a language, it is a bad language -- this is too simplistic. People are very flexible and can adapt to any language even a horrible one. If, for example, novices has difficulties in mastering the language (and some of them probably will never be able to master it due to luck of IQ, motivation, needs or all those factors) that does not mean that most professional programmers cannot benefit from it.
A scripting language is an amalgam of two roles: shell for integrating of existing components and a macro language for applications. Bourne shell was historically the first successful language for the first role; REXX, TCL and JavaScript were reasonably successful in the second. A bigger problem for Perl is that it is mainly a shell. It's presence of as a macro language is almost non-existence. There are several reasons for that. One of them is that Perl was never designed to have a clean interface with the high level languages (for example C that the implementation language for Perl interpreter). .
|
Regrettably, Perl cannot be used both as a
scripting language and as a macro language. |
All in all, Perl is a good example of the New Jersey "Worse is Better" approach. It works, it is here now (standard on all Unixes, including such obscure flavors as AIX and HP-UX), but it's far from being small, simple and bug-free implementation. However given its text oriented approach and a vast amount of operators, Perl makes an excellent integration of the capabilities of the existing Unix text-oriented filters, making many of them obsolete. It is interesting to note that Perl can replace many traditional Unix utilities -- good thing because most of them outlived their usefulness anyway. You can connect with pipes small Perl scripts and accomplish the same task more easily using just one syntax not ten different syntaxes for ten different utilities (find, grep, awk, sed, cut, etc.). Unfortunately you cannot connect internal Perl subroutines with pipes -- in this sense Perl is weaker than ksh93. So, the traditional "worse is better" holds because "better is the enemy of done".
|
Unfortunately you cannot connect via pipes internal Perl subroutines (coroutines are absent from Perl) -- in this sense Perl is weaker than ksh93 shell. So, the traditional "worse is better" holds because "better is the enemy of done". |
Now let's talk about Perl and performance problems and that will bring us to Perl vs. Java and Perl vs. C/C++. Yes, Perl is slow, but performance problems that are attributed to the text orientation are often overblown. I think that expressing things using text primitives and pipes with the set of filters and lower level partially written in C often leads to simpler and more manageable programs than using any other notations including object-oriented approach. Programs that have acceptable efficiency in most circumstances and that can be easily tuned to achieve higher efficiency when necessary. In comparison with OO-style solutions, you trade fashionable notation and buzzwords for a lot more power.
Like it or not, the vast majority (90%) of software written is not (and need not be) of operating system or compiler caliber in terms of efficiency (and probably robustness, quality, performance, maintainability). A lot of software belongs to the category of one season software -- in many cases, the life expectancy of the software is far too short, because needs, requirements, etc. change very quickly, to warrant the additional time spent on development. The costs just don't justify the benefits.
Also in many cases developers are under too much pressure, lack the skills, or simply don't care enough about the quality of their work to do a good enough job with Java, C or C++. So anyone who truly thinks that Perl is "too slow" on modern hardware should understand that any speed comparison is meaningless if the program does not work and if it works that any program can be improved with profiling and experimentation quite considerably.
|
Perl might be slow for some applications, but this is not terminal disadvantage and sped can be improved by selective tuning of less then 20% of the code. All-in-all it is much less disadvantage that one may think |
There are few problems that I've needed to solve in the last few years that I couldn't solve with Perl with reasonable efficiency, and never did I think that the quality or performance suffered. You can get some feeling for the compromises involved from the following questions:
As Donald Knuth discovered, profiling any code shows that more then 80% of computational time is spent in less then 20% of the code. Let's reverse this fact and assume that approximately the same percentage of the code has requirements demanding top performance? Probably less than 20%. So I feel that within those limits Perl is a pragmatic approach and as such deserves your attention. For remaining 20% C programs can and should be written and interfaced with existing Perl code (for example via pipes or sockets).
Slightly Skeptical View on Larry Wall and Perl
The Importance of Perl - O'Reilly Media
Prev | Up | Contents | Down | Next
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology 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
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This 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.
Last modified: March 12, 2019
