Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Introduction to Perl 5.10 for Unix System Administrators

(Perl 5.10 without excessive complexity)

by Dr Nikolai Bezroukov

Contents : Foreword : Ch01 : Ch02 : Ch03 : Ch04 : Ch05 : Ch06 : Ch07 : Ch08 :


Chapter 1: History of Perl and Perl Programming Environment Overview

Note: This is unpublished copyrighted material  licensed under the Creative Commons Attribution-NoDerivs-NonCommercial License.

Prev | Up | Contents | Down | Next

1.2.The Place of Perl among other scripting languages; good and bad things about Perl

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:

 

Is Perl Interpreted or compiled

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.

What is good about Perl: pointers and flexibility

There is a lot of blackmail on the market about Perl. In really Perl is a great scripting language despite being one of the earliest. 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.  In its great because of some architecture features that Larry Wall put into it with amazing, almost superhuman insight.
  1. Perl is a higher level language then either Python or PHP. That means that the same problem can be programmed in Perl with fewer lines of code.  In this respect it is closer to the level of shell.
  2. It is also the only mainstream scripting language that supports pointers. And support of pointers, pioneered in PL/1, BCPL and C is one of the major feature that make language tremendously more powerful and simultaneously more flexible. You can forgive a lot of Perl transgressions for including this feature against so called academic "language construction" wisdom ;-). And in reality this so called  "academic wisdom" in this particular case is nothing but a "pseudoacaodemnic wisdom" as in this case it is blatantly wrong.  In other words "Viva Perl !!!", "Viva Larry Wall !!!" :-)
  3. It has a great integration of regular expressions into the language, actually influencing adoption of regular expressions by all major competing scripting languages.
  4. Perl encourages sketching. As Paul Graham aptly put in his essay Hackers and Painters, it is the "sketching" process that is the essence of software design:
  5. It has a neutral stance on OO programming (which is oversold and misunderstood by most practitioners at the same time ;-).
  6. Clean lexical and syntax levels of the language. Despite the fact that Larry Wall did not have any compiling algorithms training he avoided major syntax and lexical design flaws. Perl has a very clean (albeit novel) lexical structure and it its syntax avoided common pitfall of Algol-style syntax such as gangling else problem (that is hunting PHP and tells something about PHP design quality).
  7. Perl is an indispensible sysadmin tool due to the blend of features most needs for sysadmin tasks and great integration with Unix. It is well suited for sysadmin script development and for CGI scripts development.  This is the last, but not least advantage that I see

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?

What is problematic

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

The price that you need to pay

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 diagnostics

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

Perl and regular expressions

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:

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.

Shell vs. Macro language

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.
Perl's strengths are on the shell side of scripting; it's much weaker on the macro language side

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.

Is Perl Slow ?

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

Webliography

Slightly Skeptical View on Larry Wall and Perl

The Importance of Perl - O'Reilly Media

Prev | Up | Contents | Down | Next



Etc

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 in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

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.

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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June 04, 2016