Commits

Anonymous committed ccefdb4

1. Added the end-of-it-slavery document.

2. Revamped the build system accordingly.

Comments (0)

Files changed (7)

 $(SITE_SOURCE_INSTALL_TARGET): INSTALL
 	cp -f $< $@
 
-docbook_targets: lib/docbook/rendered/intro-prog-lang.html
+DOCBOOK_DOCS = introductory-language end-of-it-slavery
 
-lib/docbook/rendered/intro-prog-lang.html: lib/docbook/essays/introductory-language/intro-lang-all-in-one.html
+DOCBOOK_TARGETS = $(patsubst %,lib/docbook/rendered/%.html,$(DOCBOOK_DOCS))
+
+docbook_targets: $(DOCBOOK_TARGETS)
+
+lib/docbook/rendered/%.html: lib/docbook/essays/%/all-in-one.html
 	./bin/clean-up-docbook-xsl-xhtml.pl $< > $@
 
 %.show:

lib/docbook/essays/end-of-it-slavery/all-in-one.html

+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The End of IT Slavery</title><link rel="stylesheet" href="style.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.72.0" /><link rel="start" href="index.html" title="The End of IT Slavery" /><link rel="next" href="facts-about-working.html" title="Some Facts about Working" /></head><body><div class="center ads_top"><script type="text/javascript">
+google_ad_client = "pub-2480595666283917";
+google_ad_width = 468;
+google_ad_height = 60;
+google_ad_format = "468x60_as";
+google_ad_type = "text";
+google_ad_channel ="";
+google_color_border = "336699";
+google_color_text = "000000";
+google_color_bg = "FFFFFF";
+google_color_link = "0000FF";
+google_color_url = "008000";
+</script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script></div><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">The End of IT Slavery</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="facts-about-working.html">Next</a></td></tr></table><hr /></div><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="index"></a>The End of IT Slavery</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Shlomi</span> <span class="surname">Fish</span></h3><div class="affiliation"><div class="address"><p><br />
+                        <code class="email">&lt;<a href="mailto:shlomif@iglu.org.il">shlomif@iglu.org.il</a>&gt;</code><br />
+                    </p></div></div></div></div></div><div><p class="copyright">Copyright © 2007 Shlomi Fish</p></div><div><div class="legalnotice"><a id="id2510139"></a><p>
+                
+                This work is licensed under the <a href="http://creativecommons.org/licenses/by/2.5/">Creative Commons Attribution 2.5 License</a> (or at your option any greater version of it).
+            </p></div></div><div><div class="revhistory"><table border="1" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1746</td><td align="left">1 May 2007</td><td align="left">shlomif</td></tr><tr><td align="left" colspan="3">
+                    Corrected many errors courtesy of a reviewer from the
+                    IRC.
+                </td></tr><tr><td align="left">Revision 1742</td><td align="left">1 May 2007</td><td align="left">shlomif</td></tr><tr><td align="left" colspan="3">
+                    Corrected many things, added more bolds, and a few extra
+                    text for completeness.
+                </td></tr><tr><td align="left">Revision 1740</td><td align="left">1 May 2007</td><td align="left">shlomif</td></tr><tr><td align="left" colspan="3">
+                    Finished the article.
+                </td></tr><tr><td align="left">Revision 1705</td><td align="left">17 April 2007</td><td align="left">shlomif</td></tr><tr><td align="left" colspan="3">
+                    Forked the template from a previous work and working on 
+                    it.
+                </td></tr></table></div></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="index.html#introduction">Introduction</a></span></dt><dt><span class="section"><a href="facts-about-working.html">Some Facts about Working</a></span></dt><dd><dl><dt><span class="section"><a href="facts-about-working.html#achieving-productivity">Achieving Productivity</a></span></dt><dd><dl><dt><span class="section"><a href="facts-about-working.html#reuse">Re-use instead of Start-over</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="we-cant-find-good-programmers.html">"We Can't Find Good Programmers"</a></span></dt><dt><span class="section"><a href="how-to-find-great-developers.html">How to find Great Developers?</a></span></dt><dd><dl><dt><span class="section"><a href="how-to-find-great-developers.html#open-source">Open Source</a></span></dt><dt><span class="section"><a href="how-to-find-great-developers.html#language">Language</a></span></dt><dt><span class="section"><a href="how-to-find-great-developers.html#philosophy">Philosophy</a></span></dt></dl></dd><dt><span class="section"><a href="how-to-treat-great-developers.html">How to treat Great Developers</a></span></dt><dd><dl><dt><span class="section"><a href="how-to-treat-great-developers.html#best-equipment-money-can-buy">The Best Equipment Money can Buy</a></span></dt><dt><span class="section"><a href="how-to-treat-great-developers.html#leave-your-developers-alone">Leave Your Developers Alone</a></span></dt><dt><span class="section"><a href="how-to-treat-great-developers.html#be_honest_to_your_developers">Be Honest with your Developers</a></span></dt><dt><span class="section"><a href="how-to-treat-great-developers.html#let_them_grow">Let Them Grow</a></span></dt><dt><span class="section"><a href="how-to-treat-great-developers.html#take-some-advice">Take Some Good Advice</a></span></dt><dt><span class="section"><a href="how-to-treat-great-developers.html#respect-and-cherish">Respect and Cherish Your Developers</a></span></dt></dl></dd><dt><span class="section"><a href="conclusion.html">Conclusion</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="introduction"></a>Introduction</h2></div></div></div><p>
+            This is the year 2007. This is Shlomi Fish, <span class="bold"><strong>a good hacker</strong></span>, 
+            where hacker
+            is a good enthusiastic programmer, not necessarily a computer
+            intruder. And I have an announcement to make: <span class="bold"><strong>I refuse to be an IT
+                slave</strong></span>. Moreover: if you want to employ people like me (and you 
+            do), you should not give us only good conditions - <span class="bold"><strong>you should give us
+                exceptional ones</strong></span>. Otherwise, we'll probably leave, or be 
+            fired, much to your misfortune.
+        </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="facts-about-working.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"> </td><td width="40%" align="right" valign="top"> Some Facts about Working</td></tr></table></div></body></html>

lib/docbook/essays/introductory-language/all-in-one.html

+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Thoughts about the Best Introductory Language</title><meta name="generator" content="DocBook XSL Stylesheets V1.72.0" /><link rel="start" href="#index" title="Thoughts about the Best Introductory Language" /><link rel="next" href="#introduction" title="Introduction" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="index"></a>Thoughts about the Best Introductory Language</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Shlomi</span> <span class="surname">Fish</span></h3><div class="affiliation"><div class="address"><p><br />
+                        <code class="email">&lt;<a href="mailto:shlomif@iglu.org.il">shlomif@iglu.org.il</a>&gt;</code><br />
+                    </p></div></div></div></div></div><div><p class="copyright">Copyright © 2006 Shlomi Fish</p></div><div><div class="legalnotice"><a id="id2766735"></a><p>
+
+This work is licensed under the <a href="http://creativecommons.org/licenses/by/2.5/" target="_top">Creative Commons Attribution 2.5 License</a> (or at your option a greater version of it).
+		                
+            </p></div></div><div><div class="revhistory"><table border="1" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1562</td><td align="left">04 August 2006</td><td align="left">shlomif</td></tr><tr><td align="left" colspan="3">
+                    Forked the template from a previous work and working on 
+                    it.
+                </td></tr><tr><td align="left">Revision 1691</td><td align="left">10 April 2007</td><td align="left">shlomif</td></tr><tr><td align="left" colspan="3">
+                    Finished writing the document - about to release.
+                </td></tr></table></div></div></div><hr /></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="introduction"></a>Introduction</h2></div></div></div><p>
+        The purpose of this essay is to contemplate what is the best
+        introductory programming language to teach for beginning programmers,
+        or for them to teach themselves.
+    </p><p>
+        First, I will mention several approaches taken by other people who
+        discussed this issue before, and try to explain why I disagree with 
+        them. Then I will propose and explain some relations ("Language A
+        should be learned before Language B") that are good to follow. After
+        that, I will propose my verdict, and discuss some orthogonal 
+        alternatives. Finally, I will discuss some different types of
+        teaching and how each should be conducted differently.
+    </p><p>
+        As for how I started programming myself, I should note that I learned
+        BASIC at the age of 10 (back in 1987), and then learned C when I was 
+        15 years old (in 1992); 
+        I later learned 
+        <a href="http://en.wikipedia.org/wiki/Visual_Basic_for_Applications" target="_top">Visual 
+            Basic for Applications</a> and when I was 19 years old I was
+        introduced to Perl and UNIX at my workplace, which was a web site 
+        creation shop (back in 1996, when the Internet started to become 
+        popular). I have later learned other languages and
+        technologies and still do to a large extent.
+    </p><p>
+        One note that is in order is that you shouldn't feel bad about
+        having learned using a different programming language. By all means,
+        you can still learn things on your own otherwise.
+    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="various_approaches"></a>The Various (Wrong) Approaches to an Introductory 
+        Programming Languages</h2></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="linda_mciver_approach"></a>Linda McIver's Thesis Approach</h3></div></div></div><p>
+            <a href="http://www.csse.monash.edu.au/~lindap/" target="_top">Linda 
+                McIver</a> published along with Damian Conway
+            a <a href="http://www.csse.monash.edu.au/~lindap/papers/SevenDeadlySins.pdf" target="_top">paper 
+                titled "Seven Deadly Sins of Introductory Programming Language
+                Design"</a> that explains the problems they found with
+            most popular introductory programming languages. The article makes
+            a very good read.
+        </p><p>
+            Later on, <a href="http://www.csse.monash.edu.au/~lindap/papers/LindaMcIverThesis.pdf" target="_top">her
+                Ph.D. thesis</a> introduced her idea of a good
+            introductory programming language.
+        </p><p>
+            Now, if I had to summarise this language in one word it would be
+            this: sexless. It's incredibly limited, not flexible, and not fun.
+            It has no pointers or references and instead relies on nested
+            structures and arrays. There are two basic data types - a number
+            and a string. The language does not have functions
+            as first-order objects, closures, objects and classes in the 
+            Object Oriented Programming sense, and has very few ways for one 
+            to express oneself. As a result implementing many algorithms 
+            would be very difficult in it. 
+        </p><p>
+            When I program, I'm using every tool in my arsenal, and expect
+            the language to be powerful enough to be able to translate my
+            thoughts into code. McIver's language is too limited and limiting,
+            to be effective for programming in, and being planned exclusively
+            for beginners, lacks the richness and interesting idioms that
+            make programmers like or even love their languages.
+        </p><p>
+            This is a language that I won't enjoy programming in. And I 
+            don't believe a professor who doesn't enjoy programming in a 
+            certain language can effectively convey it to his students, while
+            lacking the enthusiasm and love for the tool he chose.
+        </p><p>
+            McIver's approach is flawed in the sense that she is trying too
+            hard to save the students from all possible problems they may
+            encounter in trying to understand their introductory language.
+            However, programming is hard to learn, and learning the first
+            language is always difficult. Creating a "flawless" language that
+            lacks any sex-appeal is not going to make it better, but much
+            worse as both the professors and programmers will detest it.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="sicp_approach"></a>The "Structure and Interpretation of Computer Programs" 
+            Approach</h3></div></div></div><p>
+            <a href="http://mitpress.mit.edu/sicp/" target="_top">"Structure and
+                Interpretation of Computer Programs"</a> (or SICP
+            for short) is a classic text and course material on
+            programming, taught at MIT and many other universities
+            around the world. SICP uses Scheme (a minimalistic dialect
+            of Lisp) as its exclusive language to cover many important
+            programming and meta-programming concepts.
+        </p><p>
+            I have read the book in my third semester of the Technion (without
+            doing the exercises) and later took both of the SICP courses that 
+            were given by my department. I learned a lot from the book, and
+            while the courses did not renew too much, I did like working on the
+            exercises.
+        </p><p>
+            However, there are several problems with teaching Scheme as an 
+            introductory language. The first is that it is too impractical.
+            Scheme does not have system primitives that more modern languages 
+            take for granted like ones for random file and directory I/O, 
+            sockets, graphics primitives, Graphical User Interface (GUI), 
+            etc. Moreover, the core language is limited and most
+            practical code tends to become very verbose in it. For example,
+            whereas in Perl one would write <code class="literal">$myarray[$i]++</code>
+            to increment an array element by one, in Scheme it would be: 
+            <code class="literal">(vector-set! myarray i (1+ (vector-ref myarray 
+                i)))</code>.
+        </p><p>
+            Most of the SICP exercises are about number theory, recursion,
+            and a lot of other relatively abstract stuff, and too few are
+            about real world and exciting tasks: writing games and other
+            demos, working with files, writing scripts and utilities, 
+            networking and working with the WWW, etc. In fact, the Scheme 
+            standards define too few useful things. Most of 
+            <a href="http://community.schemewiki.org/?scheme-faq-standards#implementations" target="_top">the 
+                dazzling number of different Scheme implementations</a> all
+            extend the language in several ways, but all have their own idea 
+            of how to do it. Compare it to Perl, Python and friends which have 
+            one main C-based implementation, or to C where the standard 
+            library is actually quite useful.
+        </p><p>
+            I believe an introductory language has to grow with you. When I 
+            studied BASIC, I was able to use it for programming games, 
+            graphical demonstrations and animations, scripts, and other uses.
+            I continued to use BASIC on DOS and Windows, until I learned the
+            much-superior Perl, which I'm using today.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="back_to_basics_approach"></a>The "Teach in C" Approach</h3></div></div></div><p>
+            In his <a href="http://www.joelonsoftware.com/articles/fog0000000319.html" target="_top">"Back to Basics" essay</a>,
+            Joel Spolsky gave a case for teaching ANSI C as an introductory
+            language instead of more high level languages. His argument is
+            that programmers will end up writing sub-optimal code because
+            some low-level elements of dealing with strings and arrays are
+            abstracted away in higher-level language.
+        </p><p>
+            ANSI C and C++ have been popular introductory languages for teaching
+            programming for many years now. While some schools have switched
+            to teaching Java or a different language, they are still very 
+            popular.
+        </p><p>
+            However, C has one major deficiency: it's too close to the
+            processor to be useful. In order to perform an operation on two
+            objects, one should allocate them first, perform the operation,
+            and then take care of freeing both objects and the result (to say
+            nothing of edge cases where allocating or freeing may fail.).
+        </p><p>
+            All this work to do something that in high level, garbage
+            collected, languages is as simple as
+            <code class="literal">$result = $object1 OP $object2;</code>. From my 
+            experience with Technion students, they are often get so bogged up
+            in the technicalities of working with C instead of getting quick,
+            dirty and useful code running.
+        </p><p>
+            A good introductory programming language should allow you to write
+            a lot of useful code quickly, and not slow you down with many
+            low-level constraints. Beginning programmers have a hard enough
+            time to learn how to translate algorithms into working code, and 
+            solving bugs and the last thing they need is to deal with too many
+            idiosyncrasies of the language only because it is too low-level.
+        </p><p>
+            Spolsky's argument about the efficiency of some operations is
+            wrong, because programmers who learn such languages won't often
+            notice the difference from such inefficient operations, due to
+            the incredible speed of contemporary computers and the fact that
+            their data sets are generally too small. Moreover, many instructors
+            and exercise checkers won't penalise for such problems.
+        </p><p>
+            While the efficiency of algorithms and the underlying
+            implementation of language primitives should be stressed at
+            a certian point, the first task of an introductory course is to
+            make sure a programmer can learn to write code, not necessarily the
+            most efficient one. (Not even according to asymptotic
+            complexity). Learning how to write quick and dirty code is a  
+            mental leap that is large enough as it is.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="programming_languages_make_you_write_good_code"></a>The "First Programming Language Should Make Sure You
+            Write Good Code" Fallacy</h3></div></div></div><p>
+            You many times hear people saying that beginning programmers
+            should be taught using a programming language that restricts them
+            and forces them to write good code. Languages like Pascal, Ada,
+            Java, and many others are trying to save programmers from
+            themselves. And indeed many people believe that programmers should
+            start learning from such a language.
+        </p><p>
+            What's wrong with this approach? Several things:
+        </p><div class="itemizedlist"><ul type="disc"><li><p>
+                    The more strict the language is, the less expressive it
+                    is. Programmers like to express themselves and be able to
+                    implement algorithms using the entire power of the 
+                    language. They don't want to declare a lot of type 
+                    definitions, many constraints, write a lot of syntax, or
+                    otherwise be encumbered in the way. 
+                </p><p>
+                    It may actually make them think programming is loathsome
+                    or otherwise a very strict process instead of a very
+                    creative process.
+                </p></li><li><p>
+                    Often, the trial and error will be good for them. Plus,
+                    even writing some disorganised, but functional code is
+                    better than the program taking them much more time to
+                    write (and more time to read and understand after
+                    writing).
+                </p><p>
+                    I don't expect them to become superb programming in a day.
+                    Becoming a better programmer is a process, and cannot be
+                    taught in a semester or a year of hard work.
+                </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="have_decent_ide"></a>The "It Should Have a Decent IDE" Fallacy</h3></div></div></div><p>
+            Many education institutions reject many languages as introductory
+            languages because they don't have a decent <a href="http://en.wikipedia.org/wiki/Integrated_development_environment" target="_top">integrated development
+                environment</a> (or IDE for short). An IDE as useful and 
+            convenient as it is, however, not an absolute requirement.
+        </p><p>
+            Programming does not happen in the IDE - it happens in the
+            mind. Programmers should learn to write code that does something.
+            By using the text editor (of the IDE or a standalone one) and
+            writing text that does something, they can best learn to program 
+            for the real world. 
+        </p><p>
+            There is a myth that programming using a text editor and a command 
+            line is too difficult for mortals. This is false as all personal
+            computers used a command-line interface (often a BASIC
+            interpreter or DOS), and required programming using non-graphical
+            editors, and it was still adequate for most people.
+        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="relations"></a>Some useful relations</h2></div></div></div><p>
+    This section will introduce some useful relations ("Language A should be
+    taught before Language B") to consider in teaching programming, and explain
+    them. By using these relations one can more easily reach a final verdict.
+    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="high_level_before_C"></a>A High Level Language should Come Before C</h3></div></div></div><p>
+        C should not be taught as a first programming language from the
+        reasons I mentioned. By all means, one should use a more high level
+        languages which supports Managed programming, and other nice high
+        level constructs. Languages like Perl, Python, Ruby and to a lesser
+        extent Java and .NET are much better than C as introductory languages.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="perl_or_python_before_php"></a>Perl/Python/etc. should Come before PHP</h3></div></div></div><p>
+        Some people believe that PHP is a suitable introductory language. 
+        However, PHP has several major problems: lack of good abstraction
+        mechanisms, many inconsistencies, many functions to do the same
+        thing, and many nuances to its use. People who learn PHP right away,
+        tend to write very bad (and sometimes very dangerous) code in it, and
+        are not well-aware of its pitfalls. 
+        </p><p>
+        PHP is a fine language for the web and for other uses,
+        especially because its implementation makes deployment of some
+        large-scale web applications easier. However, the other languages in
+        the so-called "dynamic", "agile", or "scripting" class of languages
+        are not harder to learn, and less problematic. So they should be
+        taught first instead.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="perl_or_python_before_shell"></a>Perl/Python/etc. should Come before Shell</h3></div></div></div><p>
+        Some people believe that the first language a UNIX user should learn
+        is a good shell (such as
+        <a href="http://www.gnu.org/software/bash/" target="_top">GNU Bash</a> or
+        <a href="http://www.zsh.org/" target="_top">zsh</a>). However, Shell has some
+        issues. The first is that the the mentality of the UNIX Shell 
+        is different from the mentality of conventional programming languages, 
+        and causes native shell programmers to be less capable of adapting
+        to a different language, as well as writing sub-optimal code in shell.
+        </p><p>
+        The second is that in traditional shell, some operations are not as
+        efficient as they should be. While more modern variants have
+        introduced arrays and string-wise dictionaries, they are still an
+        afterthought. For these reasons, shell is not recommended to learn
+        before a dynamic language.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="C_before_assembly"></a>C should Precede Assembly</h3></div></div></div><p>
+            It is <a href="http://www.onlamp.com/pub/a/onlamp/2004/05/06/writegreatcode.html" target="_top">certainly 
+            a good idea to learn Assembly language</a>, preferably of
+            several different processor architectures. However, C should be
+            learnt first.
+        </p><p>
+            The reason for that is that people who dive right into Assembly,
+            tend to write sub-optimal code because they don't understand well
+            how this code is executed by the processor and how to compile it.
+            This is while programmers who've learned C are better equipped
+            to understand how Assembly code works, because it is somewhat
+            more convenient yet still very close to Assembly.
+        </p><p>
+            A friend of mine reported that in his workplace, where they write
+            Assembly code for various Digital Signal Processors (DSPs) some
+            of the native Assembly programmers order their instructions in 
+            ways that are executed inefficiently because of the special
+            processor pipeline. He then told me that C programmers who learn
+            Assembly make better Assembly programmers.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="first_lang_should_be_practical"></a>The First Language should be Practical</h3></div></div></div><p>
+            A good first programming language should be practical and should 
+            grow up with you. I can tell from my experiences with the various
+            BASICs, which I learned at first that BASIC was fun because it was 
+            useful. Using BASIC on the old Intel-based computers, one could 
+            write games, graphical demos, text processing and command 
+            execution scripts, and even serious applications. While BASIC is
+            in today's standards a very limited language that should no longer
+            be taught as a first language, I still fondly remember it as being
+            a lot of fun. I even continued using BASIC after I learned ANSI C
+            and what was then C++, because it was quicker and more convenient.
+            (I no longer do, because I now feel that Perl is superior to BASIC
+            in every way, and that's what I'm using now.)
+        </p><p>
+            On the other hand, Scheme as in SICP is an awful choice for an
+            introductory programming language, because it feels very
+            impractical. Writing quick and dirty code to do a lot of things
+            in Scheme is very verbose, and plus, the core standard lacks many
+            primitives for common
+            <a href="http://en.wikipedia.org/wiki/POSIX" target="_top">POSIX</a>
+            operations (like random file I/O, directories, sockets, etc.)
+            much less useful APIs. While some Scheme implementations provide
+            extensions to the language, they do so in different incompatible
+            ways.
+        </p><p>
+            Different people I talked with agreed to me that "You cannot do
+            anything with Scheme". Compare it to languages such as C and C++, 
+            Perl/Python/Tcl/Ruby/PHP, Java/.NET, etc. that feel very
+            practical, and you'll see why hardly any industrial-strength
+            code is written in Scheme.
+        </p><p>
+            Teaching a language just for teaching programming with, is
+            sub-optimal because the students cannot take this language with
+            them and perform real-world tasks with it. They will have less 
+            motivation to experiment on their own, and to remember it for
+            long.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="localised_languages"></a>Localised Programming Languages should be Avoided</h3></div></div></div><p>
+            The Wikipedia has an (incomplete) <a href="http://en.wikipedia.org/wiki/Category:Non-English-based_programming_languages" target="_top">list of non-English 
+                based programming languages</a>, that were created at 
+            some time. What these languages try to do is make sure young
+            children or other people who did not master the English Alphabet
+            and vocabulary well can start learning programming without
+            knowing English first.
+        </p><p>
+            I see several problems with this approach. One is that it is
+            important that children will be taught English starting from an
+            early age - as early as possible. This is because English, being
+            the international language, is becoming more and more important
+            for every one to learn. Tender children who are talked to in 
+            severel languages, will quickly master them, without confusing
+            them. This will save them a lot of frustration later.
+        </p><p>
+            Knowledge of English is more important than knowing how to
+            program. So it is a good idea that when teaching programming to
+            teach English first as a necessary pre-requisite.
+        </p><p>
+            The other problem I see is that such localised programming
+            languages feel unnatural and wrong. English has the richest 
+            technical vocabulary of any other language, and some terms in
+            English are impossible to translate to other languages. And
+            yet another is that such languages tend to be very ad-hoc
+            and incomplete. Finally, code that is written in them cannot be
+            understood by programmers who don't know this language.
+        </p><p>
+            So, to sum up, instead of starting with a localised programming
+            language, teach your students some basic English first. It might 
+            take longer, but will save more time and frustation later on. Plus,
+            programming is a great way to expand one's mastery of English,
+            especially today when the Internet is so prevalent.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="java_should_be_taught_after_perl"></a>Java Should be Taught After Perl</h3></div></div></div><p>
+            Joel Spolsky wrote an esssay titled 
+            <a href="http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html" target="_top">"The 
+                Perils of JavaSchools"</a> where he argued that teaching
+            Java in Computer Science corriculums is inferior to teaching
+            ANSI C and Scheme, which was what he learned. The article is wrong
+            on many points, but it highlights some of the problems with Java.
+        </p><p>
+            Java is too verbose. Some people may argue that this can be
+            solved by using a proper IDE, but as 
+            <a href="http://www.paulgraham.com/popular.html" target="_top">Paul Graham 
+                explains</a>, verbose code also has the "the cost of
+            reading it, and the cost of the space it takes up on your
+            screen.".
+        </p><p>
+            Moreover, Java code tend to be very monotonous. Almost all
+            Java code looks the same, and feels boring.
+        </p><p>
+            <a href="http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html" target="_top">Steve 
+                Yegge's very funny article "Execution in the Kingdom of 
+                Nouns"</a> illustrates another problem with
+            Java. Everything has to be a noun, with no verbs or even 
+            the many keywords which Perl 5 is infamous for but which
+            Perl programmers love. And instead of having some Perl 5-like
+            operators  for converting between data structures, you have a 
+            hideously long casting lines. 
+        </p><p>
+            Java was supposed to be kept simple, and many important concepts
+            like closures, multiple-inheritance, defining methods at runtime (a
+            la Smalltalk), runtime code evalutation (the Lisp-derived "eval"
+            operator, which is now common in most dynamic languages), operator
+            overloading, and many other elements had been kept out of it. As
+            such it turned out to be very unusable. Java 1.5/5.0 introduced
+            many drastic enhancements, but not enough proper abstractions. As a
+            result, Java is now bloated, but talented programmers still
+            normally find writing code in Perl, Python and friends more
+            natural.
+        </p><p>
+            Paul Graham's essay 
+            <a href="http://www.paulgraham.com/javacover.html" target="_top">Java's 
+                Cover</a>, which he wrote to explain why he decided not
+            to learn Java is very instructive. I read it, some time after
+            it was written and felt it reflected my feelings. I ended up
+            learning Java to see what the hype was about. While having felt
+            that I have truly understood what the essence of references in 
+            Perl 5 was, only after learning Java, I still felt it was too
+            over-rated.
+        </p><p>
+            Perhaps I'm getting too carried away in criticising Java. My point 
+            is that, as Joel Spolsky indicated in his "JavaSchools" essay,
+            teaching Java as the first language, makes many of the people who
+            have learned it airheads, who cannot think outside the limited
+            constraints that it imposes on the programmer. Teaching an
+            expressive and rich
+            <a href="http://en.wikipedia.org/wiki/Dynamic_programming_language" target="_top">dynamic language</a>
+            such as Perl or Ruby instead, will not exhibit this problem, 
+            regardless of what Joel says, as these languages constantly require
+            a programmer to think outside the box, and introduce the programmer
+            to many different (often built-in) patterns and paradigms.
+        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="verdict"></a>My Verdict</h2></div></div></div><p>
+        According to these constraints one can conclude that one should
+        start learning how to program from a high-level, dynamic and
+        practical langauge such as Perl, Python or Ruby.
+    </p><p>
+        Eric Raymond recommends this in his excellent
+        <a href="http://catb.org/~esr/faqs/hacker-howto.html" target="_top">"How to
+            become a Hacker" document</a>. He suggests one should start
+        with XHTML, which while not being a programming language but rather
+        a formatting language will still intrduce many programming idioms
+        and disciplines as well as prove useful later on.
+    </p><p>
+        After XHTML, Raymond recommends one to learn Python. However, I'm
+        not sure whether Perl 5 or Ruby will not be as suitable as Python,
+        or more. Unfortunately, I cannot reach a conclusion here, but
+        rather give some of my thoughts on each three languages.
+    </p><p>
+        (If I need to teach programming, I'll start with Perl because I know
+        it very well, and like it a lot. However, programmers who are well
+        versed in Python, may wish to teach it instead.)
+    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="perl_python_or_ruby"></a>Perl, Python or Ruby</h3></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="perl"></a>Perl</h4></div></div></div><p>
+                The core Perl language is huge. That may be a good or a bad
+                thing for teaching programming in.
+            </p><p>
+                Perl is very expressive. I believe programmers will appreciate
+                its "There is more than one way to do it" philosophy. A
+                correspondant once told me he'd prefer to teach beginners
+                Perl instead of C, similarly to the fact that he'd prefer
+                to teach English over Esperanto, because beginners would prefer
+                a language that allows them to express themselves.
+            </p><p>
+                Historically, Perl had a lack of good online
+                documentation for beginners, and 
+                <a href="http://www.shlomifish.org/philosophy/perl-newcomers/" target="_top">other
+                    problems with the treatment of newcomers</a>, but
+                this has improved lately.
+            </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="python"></a>Python</h4></div></div></div><p>
+                Python has a small core language and it tries to be elegant.
+                It has an excellent online documentation, and many introductory
+                books for it are available online. The online Python community
+                has too much elitism, and tends to deprecate Perl a lot, for
+                some reason. I am not blaming anyone in particular, but this
+                tendency is present to some extent by some of the greatest 
+                names in the Python world, and by some Pythoneers I personally
+                know.
+            </p><p>
+                People who know Perl very well, can learn Python with fewer
+                mental blocks than the other way around. This is in due to
+                the fact Perl is richer, supports more paradigms. A Perl
+                programmer told me he was able to start working on a Python
+                program right after starting to edit it using his editor,
+                and it worked, after some research.
+            </p><p>
+                Python's philosophy is "There's one good way to do it.". It
+                doesn't mean that there aren't other ways, but there is one
+                commonly acceptable way to write most code. Whether this is
+                a good thing or not for an introductory language is
+                debatable.
+            </p><p>
+                If PHP is the new Visual Basic, and Java is the new COBOL,
+                then Python is the new Pascal. (Although, all these languages
+                are better than their previous ones). In a way teaching Python
+                as a first language like teaching Pascal, makes a programmer
+                used to limited paradigms and one strict way of doing things.
+                (like teaching Esperanto instead of English). As a result,
+                trying to learn other diverse languages is becoming more
+                difficult.
+            </p><p>
+                If you've learned Python as your mother language, you should
+                take the mental leap and learn Perl, which is the Tower of
+                Babel of languages, and also has many DWIMmeries 
+                ("Do-What-I-Mean"'s) and other expressiveness. (Of course, 
+                a Perl programmer should also learn Python due to its
+                elegenace, and the fact it is extensively used and useful.)
+            </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="ruby"></a>Ruby</h4></div></div></div><p>
+                Before I discuss Ruby a word of warning: I don't know it very
+                well. So far all the limited tasks I tried to accomplish using it
+                worked well after some trial and error, but I still did not take
+                the time to thoroughly study it.
+            </p><p>
+                Ruby was written after its creator was unhappy to some extent
+                with both Perl (possibly 4 at the time) and Python, and so he
+                created a language that tried to combine the best elements of
+                Smalltalk, Perl and Python. Ruby aims to be
+                elegant and consistent, yet still very expressive and shares
+                Perl's "There's more than one way to do it" philosophy.
+            </p><p>
+                As of version 1.x, Ruby does not support multi-threaded
+                programming, has poor support for Unicode, and is much slower
+                than Perl or Python. Some of these problems will be addressed in Ruby 2.x.
+            </p><p>
+                The worst problem with Ruby, however, is the lack of good 
+                documentation. Ruby has 
+                <a href="http://www.rubycentral.com/book/" target="_top">one old edition of
+                    the "Programming Ruby" book</a> available online,
+                and that's it. Furthermore, this book is intended for absolute
+                beginners and will be too slow paced for people with extensive
+                experience in similar languages. 
+            </p><p>
+                All the other books from the Pragmattic Programmer series
+                are not available online (including the new editions of the
+                "Programming Ruby" book). What many people end up doing is
+                downloading them from "warez" sites or from Peer-to-Peer 
+                networks, but I wouldn't encourage professors to do that.
+            </p><p>
+                I recall trying to find out how to tag methods in Ruby,
+                in a similar way to Perl's method or variable attributes.
+                Google was no help and no one on Freenode on #ruby-lang told 
+                me and I asked several times, and people tried to research it. 
+                Eventually, someone I knew on #perl was able to give me the
+                answer. He then claimed that many of the slightly more
+                unconventional, but useful, tricks in Ruby were completely
+                undocumented.
+            </p><p>
+                As such, one may still encounter problems teaching Ruby as
+                an introductory language. If these problems are remedied
+                by the Ruby community, with some amount of work and effort,
+                then this may be better.
+            </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="final_verdict"></a>Final Verdict</h3></div></div></div><p>
+            All things considered, I'd say that Perl is the best choice now,
+            as Python is too strict and unexpressive, and Ruby is documented
+            in an extremely inadequate way. Again, any of the three languages
+            would be a fine choice, and all of them should be learned by
+            any programmer who is worth his weight in salt.
+        </p><p>
+            Note that besides the main players in the dynamic language
+            arena, there is the new crop of such languages: 
+            <a href="http://www.lua.org/" target="_top">Lua</a>, 
+            <a href="http://www.iolanguage.com/" target="_top">Io</a>, 
+            <a href="http://www.digitalmars.com/d/" target="_top">The D Programming
+                Language</a>, and others. These languages may be more suitable
+            in some respects, but on the other hand, may not yet have the 
+            brain-share, comprehensiveness (especially as far as APIs are
+            concerned), usability, richness or 
+            "sex-appeal"
+            <sup>[<a id="id2807449" href="#ftn.id2807449">consistency</a>]</sup>.
+        </p></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id2807449" href="#id2807449">consistency</a>] </sup>
+                Some people 
+                assume that the more consistent a language is the better.
+                However, just as most people prefer expressive and inconsistent
+                natural human languages like English, many of them would prefer
+                their programming language to have some inconsistencies,
+                Do-what-I-mean-erries, gotchas, etc. In Perl 5's case it is well
+                known that these make the language more expressive and <a href="http://www.paulgraham.com/power.html" target="_top">succinct</a> in the hands of 
+                a competent programmer.
+                </p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="types_of_teaching"></a>Some Types of Teaching</h2></div></div></div><p>
+        There are several different types of teaching programming to laymen.
+        This section aims to cover the most important ones and what needs
+        to be considered when they are done. 
+    </p><p>
+        The first type I'll discuss is a self-teaching enthusiast who is 
+        trying to teach himself programming, perhaps with some help from 
+        his friends or people he is interacting with on the Internet. Such 
+        an enthusiast usually has a lot of motivation to learn, but on the
+        other hand, will probably not put up with a material that bores
+        him or seems trivial.
+    </p><p>
+        The second type is a programmer who tries to teach a child or a
+        teenager programming. Such youngsters are often mostly motivated
+        by things that seem fun to them: games, demos, drawing pretty
+        pictures programmatically, etc. They will have little nerve for
+        a tedious programming language such as ANSI C, in which every task
+        takes a bootload of code.
+    </p><p>
+        A different type of pedagogy altogether is introducing programming to
+        students in university. Such students are older, have more mathematical
+        background, and will find other things besides games enjoying. On the
+        other hand, they tend to have less willingness to experiment on their
+        own, or to play with the computer. They expect to learn programming so
+        they can either go on with their degree, or use it to learn the rest
+        of their degree.
+    </p><p>
+        When people teach programming in the so-called K-12 school (i.e. 
+        pre-college or university), then such students will have less
+        mathematical background than their college counterparts, and may
+        find learning programming (as they find learning most everything) a
+        burden. On the other hand, they tend to be brighter and more curious.
+    </p><p>
+        The final type of teaching is in training courses. It is known that
+        such people often have to be spoon-fed the material. Plus, they may
+        not be as bright as those who were accepted into high-class
+        universities or colleges.
+    </p><p>
+        How does this influence the choice of the introductory language? It 
+        probably doesn't. However, it influences the way the language should 
+        be taught and which parts of it should be taught first. 
+    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="conclusion"></a>Conclusion</h2></div></div></div><p>
+        I talked with a few people on the IRC about it and some of them
+        told me something along the lines of "What makes you think that you
+        know better than all the universities and colleges (and other schools)
+        that are now teaching Java?". Well, this is the majority must be right
+        fallacy:
+    </p><div class="orderedlist"><ol type="1"><li><p>
+                Everybody thinks that the Earth is flat (or 
+                the Sun revolves around it) so it must be true
+            </p></li><li><p>
+                Everybody thinks that 
+                <a href="http://www.shlomifish.org/philosophy/politics/drug-legalisation/" target="_top">drugs 
+                    should be illegal</a> so it must be true.
+            </p></li></ol></div><p>
+        Etc. I can think of many other cases where a common consensus, even
+        among experts turned out to be false. But I'll still explain a bit.
+    </p><p>
+        Universities have tended to teach the "hottest" language on the
+        market. They used to teach Assembler. They used to teach COBOL (an
+        awful language by all means, and one which proved to be a dead-end
+        in language design). They taught Fortran and PL/I. They taught Pascal.
+        They taught ANSI C and C++. And now they teach Java. I believe none 
+        of these languages were suitable as an introductory programming 
+        language, but they were taught because they were used in the industry.
+    </p><p>
+        During the course of IT education, several languages need to be 
+        studied - at least one dynamic language such as Perl, Python or Ruby
+        , ANSI C, an assembler, Lisp (Scheme or Common Lisp), Haskell, O'Caml
+        or SML, and probably some specialised languages when they are
+        appropriate. But the first language need not be what is the most
+        hyped language in the industry, or even what most the rest of the
+        studies will be conducted in.
+    </p><p>
+        From my <a href="http://www.shlomifish.org/philosophy/computers/education/opinion-on-the-technion/" target="_top">impression of the Technion</a>, the 
+        institute as a whole believes that students can effectively write all
+        their code in ANSI C. In some courses, the choice of C++ and Java are
+        given, but these languages are not effectively taught. Most students,
+        during their studies, had not been exposed to such advanced paradigms
+        as regular expressions, dynamic-typing, Perl 5-like nested data 
+        structures, run time evaluation, closures and dynamic functions, and
+        others that are considered common knowledge among developers of
+        dynamic languages, and any software development enthusiast who is
+        worth his weight in salt. 
+    </p><p>
+        So my opinion still remains: Perl, Python or Ruby are the best
+        languages for introducing non-programmers to programming, while Perl
+        is the best, and Python is probably still the worst of the three.
+        However, note that any decent programming training will introduce his
+        developers to more than one language, and a prospective programmer
+        should not worry if he started out with a language that I consider
+        sub-optimal. With good ambition and motivation and with the right
+        attitude ("I know that I do not know"), one can become a better and
+        better programmer regardless of his background.
+    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="other_good_food_for_thought"></a>Other Good Food for Thought about Teaching</h2></div></div></div><p>
+        This section will bring other good for thought about teaching.
+    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="live_learn"></a>"Live as if you were to die tomorrow. Learn as if you were to 
+            live forever."</h3></div></div></div><p>
+            This is a quote attributed to
+            <a href="http://en.wikipedia.org/wiki/Mahatma_Gandhi" target="_top">Gandhi</a>.
+            The "Learn like you were going to live forever" part is not widely
+            understood by many workers. Many programmers believe that their
+            knowledge of a few programming languages is enough, and that it is
+            not necessary that they learn completely different ones.
+        </p><p>
+            It is well known that learning a new and different programming
+            language will make you a better programmer also in the original
+            languages you know. Programmers who don't learn new programming 
+            languages eventually stagnate. They are bounded by their limited
+            knowledge, and cannot think outside their box. They deserve the
+            stagnation they receive due to this bad attitude, and mental
+            laziness.
+        </p><p>
+            If you want to grow as a programmer, make sure you keep studying
+            new languages and technologies. Not only they may turn out to be
+            useful, but they'll also make you think in completely ways.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="three_levels_of_learning"></a>Three Levels of Learning</h3></div></div></div><p>
+            Rabbi Hanina used to say "I learned a lot from my teachers,
+            and from my friends more than my teachers, and from my pupils the
+            most." I believe this means that there are in fact
+            three levels of learning: 
+        </p><div class="orderedlist"><ol type="1"><li><p>
+                    <span class="bold"><strong>Level 1 - Learning</strong></span> - 
+                    this is a passive learning of the
+                    material, where one inputs the material.
+                </p></li><li><p>
+                    <span class="bold"><strong>Level 2 - Experiencing</strong></span>
+                    - in this level you work with the material you learned,
+                    and try to implement what you've learned and integrate it.
+                    This requires more understanding, because you have to
+                    work with the material.
+                </p></li><li><p>
+                    <span class="bold"><strong>Level 3 - Teaching</strong></span>
+                    - in this level you teach the material to someone
+                    else. This requires the most understanding because
+                    you need to organise it properly and convey it to
+                    someone else.
+                </p></li></ol></div><p>
+            Perhaps there's a fourth level - 
+            <span class="bold"><strong>Science</strong></span> in which the knowledge
+            is expanded. However, this implies that to truly understand the
+            material, one needs to experiment with it (preferably in 
+            production) and better yet teach it to someone else.
+        </p><p>
+            The old adage "He who can - does. He who cannot - teaches." which
+            was
+            <a href="http://en.wikiquote.org/wiki/George_Bernard_Shaw" target="_top">said 
+                by George Bernard Shaw</a> is amusing, but simply not
+            true, as I've demonstrated here. Being a great teacher is much more
+            difficult than being a great doer, and is much more enlightening.
+            <sup>[<a id="id2807832" href="#ftn.id2807832">those_who_can</a>]</sup>
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="learn_many_languages"></a>Learn as Many Languages as Possible</h3></div></div></div><p>
+            Learning one computer language is not enough. Knowledge of only
+            one computer language or a few cripples the mind and causes the
+            brain to run in circles. Different programming languages introduce
+            different insights: various easier ways to do certain things,
+            different restrictions , different syntax, different APIs,
+            different ways of doing things, different high-level mechanisms 
+            (or lack of them). All of this give different understandings
+            of how to program in any language.
+        </p><p>
+            Many people believe that their limited knowledge is adequate.
+            Java programmers are especially notorious for being opposed to
+            the ideas of them having to learn different languages. The
+            <a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=nosim/shlomifishhom-20" target="_top">Pragmatic 
+                Programmer book</a> (which I have yet to read), says
+            a programmer should learn a new computer language every year,
+            and I tend to agree with it. I compiled <a href="http://www.shlomifish.org/philosophy/philosophy/advice-for-the-young/#technologies_to_learn" target="_top">a 
+                tenative list of the technologies I found the most 
+                enlightening</a>, and I recommend programmers to learn
+            at least all of them.
+        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="learning_to_read_and_enhance"></a>Learning How to Read Code and Enhance Existing Code</h3></div></div></div><p>
+            At present, universities and other spend most time teaching
+            programmers how to write code. However, most of what programmers
+            have to do for work or for pro-bono work (like open source
+            projects) is to read code, and to enhance existing code.
+        </p><p>
+            <a href="http://www.joelonsoftware.com/" target="_top">Joel Spolsky ("Joel on
+                Software")</a> gave the following 
+            "cardinal rule of programming" in his famous
+            <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" target="_top">"Things you must never do, part I" essay</a>:
+        </p><div class="blockquote"><blockquote class="blockquote"><p>
+                It's harder to read code than to write it.
+            </p></blockquote></div><p>
+            My friends and I later <a href="http://tech.groups.yahoo.com/group/hackers-il/message/3576" target="_top">discussed this topic in the Hackers-IL 
+                mailing list</a>. Even if code is given for reading in
+            university, it is usually extremely well-written, highly organised,
+            highly legible, code, rather than the real code that programmers are
+            likely to encounter in the wild.
+        </p><p>
+            It's a shame most of the code students write as part of their
+            corriculum is only for themselves, and ends up being of little
+            value to the world at large. Even if some code ends up as an open
+            source project, it is usually too incomplete and lacks essential
+            functionality or correctness to be of any use in the real world. 
+        </p><p>
+            As Joel points out in the article, most programmers end up saying
+            that the code they are working on is horrible and that they wish
+            to completely rewrite it if they have the chance, instead of
+            <a href="http://www.refactoring.com/" target="_top">refactoring</a> it
+            to make it better.
+        </p><p>
+            Furthermore, since reading code is harder than writing it, then
+            it makes sense that programmers who are good at reading (or
+            refactoring code or enhancing it) are much better programmers,
+            than programmers who are only good at writing new code. I wish
+            I had a dollar for everytime I heard of someone trying to rewrite
+            an existing functional and relativley bug-free codebase from
+            scratch, just because this codebase was deemed of too little 
+            quality, and that afterwards this rewrite ended up at nothing.
+            These case practically dwarf the number of successful rewrites
+            I recall.
+        </p><p>
+            To sum up, it will be a good idea to teach first-time programmers
+            how to read real-world code, or the code written by their
+            co-students, and how to enhance it by extending it, and cleaning
+            it up.
+        </p></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id2807832" href="#id2807832">those_who_can</a>] </sup>
+                What is true, in my opinion. is that "Those who can - do. 
+                Those who can't - complain." However, often people who can 
+                and do, still complain. I recall this quote being
+                attributed to 
+                <a href="http://en.wikipedia.org/wiki/Linus_Torvalds" target="_top">Linus
+                    Torvalds </a>, but it <a href="http://shlomif.livejournal.com/39215.html" target="_top">predates him</a>.
+                </p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="thanks"></a>Thanks</h2></div></div></div><p>
+        Thanks to Pete_I on Freenode, 
+        <a href="http://www.zak.co.il/" target="_top">Omer Zak</a>,
+        <a href="http://www.wgz.org/chromatic/" target="_top">chromatic</a>
+        Jonathan Scott Duff, Sagiv Barhoom and others for reviewing 
+        early drafts of this essay and giving some editorial assistance. 
+    </p></div></div></body></html>

lib/docbook/essays/introductory-language/intro-lang-all-in-one.html

-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Thoughts about the Best Introductory Language</title><meta name="generator" content="DocBook XSL Stylesheets V1.72.0" /><link rel="start" href="#index" title="Thoughts about the Best Introductory Language" /><link rel="next" href="#introduction" title="Introduction" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="index"></a>Thoughts about the Best Introductory Language</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Shlomi</span> <span class="surname">Fish</span></h3><div class="affiliation"><div class="address"><p><br />
-                        <code class="email">&lt;<a href="mailto:shlomif@iglu.org.il">shlomif@iglu.org.il</a>&gt;</code><br />
-                    </p></div></div></div></div></div><div><p class="copyright">Copyright © 2006 Shlomi Fish</p></div><div><div class="legalnotice"><a id="id2766735"></a><p>
-
-This work is licensed under the <a href="http://creativecommons.org/licenses/by/2.5/" target="_top">Creative Commons Attribution 2.5 License</a> (or at your option a greater version of it).
-		                
-            </p></div></div><div><div class="revhistory"><table border="1" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1562</td><td align="left">04 August 2006</td><td align="left">shlomif</td></tr><tr><td align="left" colspan="3">
-                    Forked the template from a previous work and working on 
-                    it.
-                </td></tr><tr><td align="left">Revision 1691</td><td align="left">10 April 2007</td><td align="left">shlomif</td></tr><tr><td align="left" colspan="3">
-                    Finished writing the document - about to release.
-                </td></tr></table></div></div></div><hr /></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="introduction"></a>Introduction</h2></div></div></div><p>
-        The purpose of this essay is to contemplate what is the best
-        introductory programming language to teach for beginning programmers,
-        or for them to teach themselves.
-    </p><p>
-        First, I will mention several approaches taken by other people who
-        discussed this issue before, and try to explain why I disagree with 
-        them. Then I will propose and explain some relations ("Language A
-        should be learned before Language B") that are good to follow. After
-        that, I will propose my verdict, and discuss some orthogonal 
-        alternatives. Finally, I will discuss some different types of
-        teaching and how each should be conducted differently.
-    </p><p>
-        As for how I started programming myself, I should note that I learned
-        BASIC at the age of 10 (back in 1987), and then learned C when I was 
-        15 years old (in 1992); 
-        I later learned 
-        <a href="http://en.wikipedia.org/wiki/Visual_Basic_for_Applications" target="_top">Visual 
-            Basic for Applications</a> and when I was 19 years old I was
-        introduced to Perl and UNIX at my workplace, which was a web site 
-        creation shop (back in 1996, when the Internet started to become 
-        popular). I have later learned other languages and
-        technologies and still do to a large extent.
-    </p><p>
-        One note that is in order is that you shouldn't feel bad about
-        having learned using a different programming language. By all means,
-        you can still learn things on your own otherwise.
-    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="various_approaches"></a>The Various (Wrong) Approaches to an Introductory 
-        Programming Languages</h2></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="linda_mciver_approach"></a>Linda McIver's Thesis Approach</h3></div></div></div><p>
-            <a href="http://www.csse.monash.edu.au/~lindap/" target="_top">Linda 
-                McIver</a> published along with Damian Conway
-            a <a href="http://www.csse.monash.edu.au/~lindap/papers/SevenDeadlySins.pdf" target="_top">paper 
-                titled "Seven Deadly Sins of Introductory Programming Language
-                Design"</a> that explains the problems they found with
-            most popular introductory programming languages. The article makes
-            a very good read.
-        </p><p>
-            Later on, <a href="http://www.csse.monash.edu.au/~lindap/papers/LindaMcIverThesis.pdf" target="_top">her
-                Ph.D. thesis</a> introduced her idea of a good
-            introductory programming language.
-        </p><p>
-            Now, if I had to summarise this language in one word it would be
-            this: sexless. It's incredibly limited, not flexible, and not fun.
-            It has no pointers or references and instead relies on nested
-            structures and arrays. There are two basic data types - a number
-            and a string. The language does not have functions
-            as first-order objects, closures, objects and classes in the 
-            Object Oriented Programming sense, and has very few ways for one 
-            to express oneself. As a result implementing many algorithms 
-            would be very difficult in it. 
-        </p><p>
-            When I program, I'm using every tool in my arsenal, and expect
-            the language to be powerful enough to be able to translate my
-            thoughts into code. McIver's language is too limited and limiting,
-            to be effective for programming in, and being planned exclusively
-            for beginners, lacks the richness and interesting idioms that
-            make programmers like or even love their languages.
-        </p><p>
-            This is a language that I won't enjoy programming in. And I 
-            don't believe a professor who doesn't enjoy programming in a 
-            certain language can effectively convey it to his students, while
-            lacking the enthusiasm and love for the tool he chose.
-        </p><p>
-            McIver's approach is flawed in the sense that she is trying too
-            hard to save the students from all possible problems they may
-            encounter in trying to understand their introductory language.
-            However, programming is hard to learn, and learning the first
-            language is always difficult. Creating a "flawless" language that
-            lacks any sex-appeal is not going to make it better, but much
-            worse as both the professors and programmers will detest it.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="sicp_approach"></a>The "Structure and Interpretation of Computer Programs" 
-            Approach</h3></div></div></div><p>
-            <a href="http://mitpress.mit.edu/sicp/" target="_top">"Structure and
-                Interpretation of Computer Programs"</a> (or SICP
-            for short) is a classic text and course material on
-            programming, taught at MIT and many other universities
-            around the world. SICP uses Scheme (a minimalistic dialect
-            of Lisp) as its exclusive language to cover many important
-            programming and meta-programming concepts.
-        </p><p>
-            I have read the book in my third semester of the Technion (without
-            doing the exercises) and later took both of the SICP courses that 
-            were given by my department. I learned a lot from the book, and
-            while the courses did not renew too much, I did like working on the
-            exercises.
-        </p><p>
-            However, there are several problems with teaching Scheme as an 
-            introductory language. The first is that it is too impractical.
-            Scheme does not have system primitives that more modern languages 
-            take for granted like ones for random file and directory I/O, 
-            sockets, graphics primitives, Graphical User Interface (GUI), 
-            etc. Moreover, the core language is limited and most
-            practical code tends to become very verbose in it. For example,
-            whereas in Perl one would write <code class="literal">$myarray[$i]++</code>
-            to increment an array element by one, in Scheme it would be: 
-            <code class="literal">(vector-set! myarray i (1+ (vector-ref myarray 
-                i)))</code>.
-        </p><p>
-            Most of the SICP exercises are about number theory, recursion,
-            and a lot of other relatively abstract stuff, and too few are
-            about real world and exciting tasks: writing games and other
-            demos, working with files, writing scripts and utilities, 
-            networking and working with the WWW, etc. In fact, the Scheme 
-            standards define too few useful things. Most of 
-            <a href="http://community.schemewiki.org/?scheme-faq-standards#implementations" target="_top">the 
-                dazzling number of different Scheme implementations</a> all
-            extend the language in several ways, but all have their own idea 
-            of how to do it. Compare it to Perl, Python and friends which have 
-            one main C-based implementation, or to C where the standard 
-            library is actually quite useful.
-        </p><p>
-            I believe an introductory language has to grow with you. When I 
-            studied BASIC, I was able to use it for programming games, 
-            graphical demonstrations and animations, scripts, and other uses.
-            I continued to use BASIC on DOS and Windows, until I learned the
-            much-superior Perl, which I'm using today.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="back_to_basics_approach"></a>The "Teach in C" Approach</h3></div></div></div><p>
-            In his <a href="http://www.joelonsoftware.com/articles/fog0000000319.html" target="_top">"Back to Basics" essay</a>,
-            Joel Spolsky gave a case for teaching ANSI C as an introductory
-            language instead of more high level languages. His argument is
-            that programmers will end up writing sub-optimal code because
-            some low-level elements of dealing with strings and arrays are
-            abstracted away in higher-level language.
-        </p><p>
-            ANSI C and C++ have been popular introductory languages for teaching
-            programming for many years now. While some schools have switched
-            to teaching Java or a different language, they are still very 
-            popular.
-        </p><p>
-            However, C has one major deficiency: it's too close to the
-            processor to be useful. In order to perform an operation on two
-            objects, one should allocate them first, perform the operation,
-            and then take care of freeing both objects and the result (to say
-            nothing of edge cases where allocating or freeing may fail.).
-        </p><p>
-            All this work to do something that in high level, garbage
-            collected, languages is as simple as
-            <code class="literal">$result = $object1 OP $object2;</code>. From my 
-            experience with Technion students, they are often get so bogged up
-            in the technicalities of working with C instead of getting quick,
-            dirty and useful code running.
-        </p><p>
-            A good introductory programming language should allow you to write
-            a lot of useful code quickly, and not slow you down with many
-            low-level constraints. Beginning programmers have a hard enough
-            time to learn how to translate algorithms into working code, and 
-            solving bugs and the last thing they need is to deal with too many
-            idiosyncrasies of the language only because it is too low-level.
-        </p><p>
-            Spolsky's argument about the efficiency of some operations is
-            wrong, because programmers who learn such languages won't often
-            notice the difference from such inefficient operations, due to
-            the incredible speed of contemporary computers and the fact that
-            their data sets are generally too small. Moreover, many instructors
-            and exercise checkers won't penalise for such problems.
-        </p><p>
-            While the efficiency of algorithms and the underlying
-            implementation of language primitives should be stressed at
-            a certian point, the first task of an introductory course is to
-            make sure a programmer can learn to write code, not necessarily the
-            most efficient one. (Not even according to asymptotic
-            complexity). Learning how to write quick and dirty code is a  
-            mental leap that is large enough as it is.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="programming_languages_make_you_write_good_code"></a>The "First Programming Language Should Make Sure You
-            Write Good Code" Fallacy</h3></div></div></div><p>
-            You many times hear people saying that beginning programmers
-            should be taught using a programming language that restricts them
-            and forces them to write good code. Languages like Pascal, Ada,
-            Java, and many others are trying to save programmers from
-            themselves. And indeed many people believe that programmers should
-            start learning from such a language.
-        </p><p>
-            What's wrong with this approach? Several things:
-        </p><div class="itemizedlist"><ul type="disc"><li><p>
-                    The more strict the language is, the less expressive it
-                    is. Programmers like to express themselves and be able to
-                    implement algorithms using the entire power of the 
-                    language. They don't want to declare a lot of type 
-                    definitions, many constraints, write a lot of syntax, or
-                    otherwise be encumbered in the way. 
-                </p><p>
-                    It may actually make them think programming is loathsome
-                    or otherwise a very strict process instead of a very
-                    creative process.
-                </p></li><li><p>
-                    Often, the trial and error will be good for them. Plus,
-                    even writing some disorganised, but functional code is
-                    better than the program taking them much more time to
-                    write (and more time to read and understand after
-                    writing).
-                </p><p>
-                    I don't expect them to become superb programming in a day.
-                    Becoming a better programmer is a process, and cannot be
-                    taught in a semester or a year of hard work.
-                </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="have_decent_ide"></a>The "It Should Have a Decent IDE" Fallacy</h3></div></div></div><p>
-            Many education institutions reject many languages as introductory
-            languages because they don't have a decent <a href="http://en.wikipedia.org/wiki/Integrated_development_environment" target="_top">integrated development
-                environment</a> (or IDE for short). An IDE as useful and 
-            convenient as it is, however, not an absolute requirement.
-        </p><p>
-            Programming does not happen in the IDE - it happens in the
-            mind. Programmers should learn to write code that does something.
-            By using the text editor (of the IDE or a standalone one) and
-            writing text that does something, they can best learn to program 
-            for the real world. 
-        </p><p>
-            There is a myth that programming using a text editor and a command 
-            line is too difficult for mortals. This is false as all personal
-            computers used a command-line interface (often a BASIC
-            interpreter or DOS), and required programming using non-graphical
-            editors, and it was still adequate for most people.
-        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="relations"></a>Some useful relations</h2></div></div></div><p>
-    This section will introduce some useful relations ("Language A should be
-    taught before Language B") to consider in teaching programming, and explain
-    them. By using these relations one can more easily reach a final verdict.
-    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="high_level_before_C"></a>A High Level Language should Come Before C</h3></div></div></div><p>
-        C should not be taught as a first programming language from the
-        reasons I mentioned. By all means, one should use a more high level
-        languages which supports Managed programming, and other nice high
-        level constructs. Languages like Perl, Python, Ruby and to a lesser
-        extent Java and .NET are much better than C as introductory languages.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="perl_or_python_before_php"></a>Perl/Python/etc. should Come before PHP</h3></div></div></div><p>
-        Some people believe that PHP is a suitable introductory language. 
-        However, PHP has several major problems: lack of good abstraction
-        mechanisms, many inconsistencies, many functions to do the same
-        thing, and many nuances to its use. People who learn PHP right away,
-        tend to write very bad (and sometimes very dangerous) code in it, and
-        are not well-aware of its pitfalls. 
-        </p><p>
-        PHP is a fine language for the web and for other uses,
-        especially because its implementation makes deployment of some
-        large-scale web applications easier. However, the other languages in
-        the so-called "dynamic", "agile", or "scripting" class of languages
-        are not harder to learn, and less problematic. So they should be
-        taught first instead.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="perl_or_python_before_shell"></a>Perl/Python/etc. should Come before Shell</h3></div></div></div><p>
-        Some people believe that the first language a UNIX user should learn
-        is a good shell (such as
-        <a href="http://www.gnu.org/software/bash/" target="_top">GNU Bash</a> or
-        <a href="http://www.zsh.org/" target="_top">zsh</a>). However, Shell has some
-        issues. The first is that the the mentality of the UNIX Shell 
-        is different from the mentality of conventional programming languages, 
-        and causes native shell programmers to be less capable of adapting
-        to a different language, as well as writing sub-optimal code in shell.
-        </p><p>
-        The second is that in traditional shell, some operations are not as
-        efficient as they should be. While more modern variants have
-        introduced arrays and string-wise dictionaries, they are still an
-        afterthought. For these reasons, shell is not recommended to learn
-        before a dynamic language.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="C_before_assembly"></a>C should Precede Assembly</h3></div></div></div><p>
-            It is <a href="http://www.onlamp.com/pub/a/onlamp/2004/05/06/writegreatcode.html" target="_top">certainly 
-            a good idea to learn Assembly language</a>, preferably of
-            several different processor architectures. However, C should be
-            learnt first.
-        </p><p>
-            The reason for that is that people who dive right into Assembly,
-            tend to write sub-optimal code because they don't understand well
-            how this code is executed by the processor and how to compile it.
-            This is while programmers who've learned C are better equipped
-            to understand how Assembly code works, because it is somewhat
-            more convenient yet still very close to Assembly.
-        </p><p>
-            A friend of mine reported that in his workplace, where they write
-            Assembly code for various Digital Signal Processors (DSPs) some
-            of the native Assembly programmers order their instructions in 
-            ways that are executed inefficiently because of the special
-            processor pipeline. He then told me that C programmers who learn
-            Assembly make better Assembly programmers.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="first_lang_should_be_practical"></a>The First Language should be Practical</h3></div></div></div><p>
-            A good first programming language should be practical and should 
-            grow up with you. I can tell from my experiences with the various
-            BASICs, which I learned at first that BASIC was fun because it was 
-            useful. Using BASIC on the old Intel-based computers, one could 
-            write games, graphical demos, text processing and command 
-            execution scripts, and even serious applications. While BASIC is
-            in today's standards a very limited language that should no longer
-            be taught as a first language, I still fondly remember it as being
-            a lot of fun. I even continued using BASIC after I learned ANSI C
-            and what was then C++, because it was quicker and more convenient.
-            (I no longer do, because I now feel that Perl is superior to BASIC
-            in every way, and that's what I'm using now.)
-        </p><p>
-            On the other hand, Scheme as in SICP is an awful choice for an
-            introductory programming language, because it feels very
-            impractical. Writing quick and dirty code to do a lot of things
-            in Scheme is very verbose, and plus, the core standard lacks many
-            primitives for common
-            <a href="http://en.wikipedia.org/wiki/POSIX" target="_top">POSIX</a>
-            operations (like random file I/O, directories, sockets, etc.)
-            much less useful APIs. While some Scheme implementations provide
-            extensions to the language, they do so in different incompatible
-            ways.
-        </p><p>
-            Different people I talked with agreed to me that "You cannot do
-            anything with Scheme". Compare it to languages such as C and C++, 
-            Perl/Python/Tcl/Ruby/PHP, Java/.NET, etc. that feel very
-            practical, and you'll see why hardly any industrial-strength
-            code is written in Scheme.
-        </p><p>
-            Teaching a language just for teaching programming with, is
-            sub-optimal because the students cannot take this language with
-            them and perform real-world tasks with it. They will have less 
-            motivation to experiment on their own, and to remember it for
-            long.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="localised_languages"></a>Localised Programming Languages should be Avoided</h3></div></div></div><p>
-            The Wikipedia has an (incomplete) <a href="http://en.wikipedia.org/wiki/Category:Non-English-based_programming_languages" target="_top">list of non-English 
-                based programming languages</a>, that were created at 
-            some time. What these languages try to do is make sure young
-            children or other people who did not master the English Alphabet
-            and vocabulary well can start learning programming without
-            knowing English first.
-        </p><p>
-            I see several problems with this approach. One is that it is
-            important that children will be taught English starting from an
-            early age - as early as possible. This is because English, being
-            the international language, is becoming more and more important
-            for every one to learn. Tender children who are talked to in 
-            severel languages, will quickly master them, without confusing
-            them. This will save them a lot of frustration later.
-        </p><p>
-            Knowledge of English is more important than knowing how to
-            program. So it is a good idea that when teaching programming to
-            teach English first as a necessary pre-requisite.
-        </p><p>
-            The other problem I see is that such localised programming
-            languages feel unnatural and wrong. English has the richest 
-            technical vocabulary of any other language, and some terms in
-            English are impossible to translate to other languages. And
-            yet another is that such languages tend to be very ad-hoc
-            and incomplete. Finally, code that is written in them cannot be
-            understood by programmers who don't know this language.
-        </p><p>
-            So, to sum up, instead of starting with a localised programming
-            language, teach your students some basic English first. It might 
-            take longer, but will save more time and frustation later on. Plus,
-            programming is a great way to expand one's mastery of English,
-            especially today when the Internet is so prevalent.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="java_should_be_taught_after_perl"></a>Java Should be Taught After Perl</h3></div></div></div><p>
-            Joel Spolsky wrote an esssay titled 
-            <a href="http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html" target="_top">"The 
-                Perils of JavaSchools"</a> where he argued that teaching
-            Java in Computer Science corriculums is inferior to teaching
-            ANSI C and Scheme, which was what he learned. The article is wrong
-            on many points, but it highlights some of the problems with Java.
-        </p><p>
-            Java is too verbose. Some people may argue that this can be
-            solved by using a proper IDE, but as 
-            <a href="http://www.paulgraham.com/popular.html" target="_top">Paul Graham 
-                explains</a>, verbose code also has the "the cost of
-            reading it, and the cost of the space it takes up on your
-            screen.".
-        </p><p>
-            Moreover, Java code tend to be very monotonous. Almost all
-            Java code looks the same, and feels boring.
-        </p><p>
-            <a href="http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html" target="_top">Steve 
-                Yegge's very funny article "Execution in the Kingdom of 
-                Nouns"</a> illustrates another problem with
-            Java. Everything has to be a noun, with no verbs or even 
-            the many keywords which Perl 5 is infamous for but which
-            Perl programmers love. And instead of having some Perl 5-like
-            operators  for converting between data structures, you have a 
-            hideously long casting lines. 
-        </p><p>
-            Java was supposed to be kept simple, and many important concepts
-            like closures, multiple-inheritance, defining methods at runtime (a
-            la Smalltalk), runtime code evalutation (the Lisp-derived "eval"
-            operator, which is now common in most dynamic languages), operator
-            overloading, and many other elements had been kept out of it. As
-            such it turned out to be very unusable. Java 1.5/5.0 introduced
-            many drastic enhancements, but not enough proper abstractions. As a
-            result, Java is now bloated, but talented programmers still
-            normally find writing code in Perl, Python and friends more
-            natural.
-        </p><p>
-            Paul Graham's essay 
-            <a href="http://www.paulgraham.com/javacover.html" target="_top">Java's 
-                Cover</a>, which he wrote to explain why he decided not
-            to learn Java is very instructive. I read it, some time after
-            it was written and felt it reflected my feelings. I ended up
-            learning Java to see what the hype was about. While having felt
-            that I have truly understood what the essence of references in 
-            Perl 5 was, only after learning Java, I still felt it was too
-            over-rated.
-        </p><p>
-            Perhaps I'm getting too carried away in criticising Java. My point 
-            is that, as Joel Spolsky indicated in his "JavaSchools" essay,
-            teaching Java as the first language, makes many of the people who
-            have learned it airheads, who cannot think outside the limited
-            constraints that it imposes on the programmer. Teaching an
-            expressive and rich
-            <a href="http://en.wikipedia.org/wiki/Dynamic_programming_language" target="_top">dynamic language</a>
-            such as Perl or Ruby instead, will not exhibit this problem, 
-            regardless of what Joel says, as these languages constantly require
-            a programmer to think outside the box, and introduce the programmer
-            to many different (often built-in) patterns and paradigms.
-        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="verdict"></a>My Verdict</h2></div></div></div><p>
-        According to these constraints one can conclude that one should
-        start learning how to program from a high-level, dynamic and
-        practical langauge such as Perl, Python or Ruby.
-    </p><p>
-        Eric Raymond recommends this in his excellent
-        <a href="http://catb.org/~esr/faqs/hacker-howto.html" target="_top">"How to
-            become a Hacker" document</a>. He suggests one should start
-        with XHTML, which while not being a programming language but rather
-        a formatting language will still intrduce many programming idioms
-        and disciplines as well as prove useful later on.
-    </p><p>
-        After XHTML, Raymond recommends one to learn Python. However, I'm
-        not sure whether Perl 5 or Ruby will not be as suitable as Python,
-        or more. Unfortunately, I cannot reach a conclusion here, but
-        rather give some of my thoughts on each three languages.
-    </p><p>
-        (If I need to teach programming, I'll start with Perl because I know
-        it very well, and like it a lot. However, programmers who are well
-        versed in Python, may wish to teach it instead.)
-    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="perl_python_or_ruby"></a>Perl, Python or Ruby</h3></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="perl"></a>Perl</h4></div></div></div><p>
-                The core Perl language is huge. That may be a good or a bad
-                thing for teaching programming in.
-            </p><p>
-                Perl is very expressive. I believe programmers will appreciate
-                its "There is more than one way to do it" philosophy. A
-                correspondant once told me he'd prefer to teach beginners
-                Perl instead of C, similarly to the fact that he'd prefer
-                to teach English over Esperanto, because beginners would prefer
-                a language that allows them to express themselves.
-            </p><p>
-                Historically, Perl had a lack of good online
-                documentation for beginners, and 
-                <a href="http://www.shlomifish.org/philosophy/perl-newcomers/" target="_top">other
-                    problems with the treatment of newcomers</a>, but
-                this has improved lately.
-            </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="python"></a>Python</h4></div></div></div><p>
-                Python has a small core language and it tries to be elegant.
-                It has an excellent online documentation, and many introductory
-                books for it are available online. The online Python community
-                has too much elitism, and tends to deprecate Perl a lot, for
-                some reason. I am not blaming anyone in particular, but this
-                tendency is present to some extent by some of the greatest 
-                names in the Python world, and by some Pythoneers I personally
-                know.
-            </p><p>
-                People who know Perl very well, can learn Python with fewer
-                mental blocks than the other way around. This is in due to
-                the fact Perl is richer, supports more paradigms. A Perl
-                programmer told me he was able to start working on a Python
-                program right after starting to edit it using his editor,
-                and it worked, after some research.
-            </p><p>
-                Python's philosophy is "There's one good way to do it.". It
-                doesn't mean that there aren't other ways, but there is one
-                commonly acceptable way to write most code. Whether this is
-                a good thing or not for an introductory language is
-                debatable.
-            </p><p>
-                If PHP is the new Visual Basic, and Java is the new COBOL,
-                then Python is the new Pascal. (Although, all these languages
-                are better than their previous ones). In a way teaching Python
-                as a first language like teaching Pascal, makes a programmer
-                used to limited paradigms and one strict way of doing things.
-                (like teaching Esperanto instead of English). As a result,
-                trying to learn other diverse languages is becoming more
-                difficult.
-            </p><p>
-                If you've learned Python as your mother language, you should
-                take the mental leap and learn Perl, which is the Tower of
-                Babel of languages, and also has many DWIMmeries 
-                ("Do-What-I-Mean"'s) and other expressiveness. (Of course, 
-                a Perl programmer should also learn Python due to its
-                elegenace, and the fact it is extensively used and useful.)
-            </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="ruby"></a>Ruby</h4></div></div></div><p>
-                Before I discuss Ruby a word of warning: I don't know it very
-                well. So far all the limited tasks I tried to accomplish using it
-                worked well after some trial and error, but I still did not take
-                the time to thoroughly study it.
-            </p><p>
-                Ruby was written after its creator was unhappy to some extent
-                with both Perl (possibly 4 at the time) and Python, and so he
-                created a language that tried to combine the best elements of
-                Smalltalk, Perl and Python. Ruby aims to be
-                elegant and consistent, yet still very expressive and shares
-                Perl's "There's more than one way to do it" philosophy.
-            </p><p>
-                As of version 1.x, Ruby does not support multi-threaded
-                programming, has poor support for Unicode, and is much slower
-                than Perl or Python. Some of these problems will be addressed in Ruby 2.x.
-            </p><p>
-                The worst problem with Ruby, however, is the lack of good 
-                documentation. Ruby has 
-                <a href="http://www.rubycentral.com/book/" target="_top">one old edition of
-                    the "Programming Ruby" book</a> available online,
-                and that's it. Furthermore, this book is intended for absolute
-                beginners and will be too slow paced for people with extensive
-                experience in similar languages. 
-            </p><p>
-                All the other books from the Pragmattic Programmer series
-                are not available online (including the new editions of the
-                "Programming Ruby" book). What many people end up doing is
-                downloading them from "warez" sites or from Peer-to-Peer 
-                networks, but I wouldn't encourage professors to do that.
-            </p><p>
-                I recall trying to find out how to tag methods in Ruby,
-                in a similar way to Perl's method or variable attributes.
-                Google was no help and no one on Freenode on #ruby-lang told 
-                me and I asked several times, and people tried to research it. 
-                Eventually, someone I knew on #perl was able to give me the
-                answer. He then claimed that many of the slightly more
-                unconventional, but useful, tricks in Ruby were completely
-                undocumented.
-            </p><p>
-                As such, one may still encounter problems teaching Ruby as
-                an introductory language. If these problems are remedied
-                by the Ruby community, with some amount of work and effort,
-                then this may be better.
-            </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="final_verdict"></a>Final Verdict</h3></div></div></div><p>
-            All things considered, I'd say that Perl is the best choice now,
-            as Python is too strict and unexpressive, and Ruby is documented
-            in an extremely inadequate way. Again, any of the three languages
-            would be a fine choice, and all of them should be learned by
-            any programmer who is worth his weight in salt.
-        </p><p>
-            Note that besides the main players in the dynamic language
-            arena, there is the new crop of such languages: 
-            <a href="http://www.lua.org/" target="_top">Lua</a>, 
-            <a href="http://www.iolanguage.com/" target="_top">Io</a>, 
-            <a href="http://www.digitalmars.com/d/" target="_top">The D Programming
-                Language</a>, and others. These languages may be more suitable
-            in some respects, but on the other hand, may not yet have the 
-            brain-share, comprehensiveness (especially as far as APIs are
-            concerned), usability, richness or 
-            "sex-appeal"
-            <sup>[<a id="id2807449" href="#ftn.id2807449">consistency</a>]</sup>.
-        </p></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id2807449" href="#id2807449">consistency</a>] </sup>
-                Some people 
-                assume that the more consistent a language is the better.
-                However, just as most people prefer expressive and inconsistent
-                natural human languages like English, many of them would prefer
-                their programming language to have some inconsistencies,
-                Do-what-I-mean-erries, gotchas, etc. In Perl 5's case it is well
-                known that these make the language more expressive and <a href="http://www.paulgraham.com/power.html" target="_top">succinct</a> in the hands of 
-                a competent programmer.
-                </p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="types_of_teaching"></a>Some Types of Teaching</h2></div></div></div><p>
-        There are several different types of teaching programming to laymen.
-        This section aims to cover the most important ones and what needs
-        to be considered when they are done. 
-    </p><p>
-        The first type I'll discuss is a self-teaching enthusiast who is 
-        trying to teach himself programming, perhaps with some help from 
-        his friends or people he is interacting with on the Internet. Such 
-        an enthusiast usually has a lot of motivation to learn, but on the
-        other hand, will probably not put up with a material that bores
-        him or seems trivial.
-    </p><p>
-        The second type is a programmer who tries to teach a child or a
-        teenager programming. Such youngsters are often mostly motivated
-        by things that seem fun to them: games, demos, drawing pretty
-        pictures programmatically, etc. They will have little nerve for
-        a tedious programming language such as ANSI C, in which every task
-        takes a bootload of code.
-    </p><p>
-        A different type of pedagogy altogether is introducing programming to
-        students in university. Such students are older, have more mathematical
-        background, and will find other things besides games enjoying. On the
-        other hand, they tend to have less willingness to experiment on their
-        own, or to play with the computer. They expect to learn programming so
-        they can either go on with their degree, or use it to learn the rest
-        of their degree.
-    </p><p>
-        When people teach programming in the so-called K-12 school (i.e. 
-        pre-college or university), then such students will have less
-        mathematical background than their college counterparts, and may
-        find learning programming (as they find learning most everything) a
-        burden. On the other hand, they tend to be brighter and more curious.
-    </p><p>
-        The final type of teaching is in training courses. It is known that
-        such people often have to be spoon-fed the material. Plus, they may
-        not be as bright as those who were accepted into high-class
-        universities or colleges.
-    </p><p>
-        How does this influence the choice of the introductory language? It 
-        probably doesn't. However, it influences the way the language should 
-        be taught and which parts of it should be taught first. 
-    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="conclusion"></a>Conclusion</h2></div></div></div><p>
-        I talked with a few people on the IRC about it and some of them
-        told me something along the lines of "What makes you think that you
-        know better than all the universities and colleges (and other schools)
-        that are now teaching Java?". Well, this is the majority must be right
-        fallacy:
-    </p><div class="orderedlist"><ol type="1"><li><p>
-                Everybody thinks that the Earth is flat (or 
-                the Sun revolves around it) so it must be true
-            </p></li><li><p>
-                Everybody thinks that 
-                <a href="http://www.shlomifish.org/philosophy/politics/drug-legalisation/" target="_top">drugs 
-                    should be illegal</a> so it must be true.
-            </p></li></ol></div><p>
-        Etc. I can think of many other cases where a common consensus, even
-        among experts turned out to be false. But I'll still explain a bit.
-    </p><p>
-        Universities have tended to teach the "hottest" language on the
-        market. They used to teach Assembler. They used to teach COBOL (an
-        awful language by all means, and one which proved to be a dead-end
-        in language design). They taught Fortran and PL/I. They taught Pascal.
-        They taught ANSI C and C++. And now they teach Java. I believe none 
-        of these languages were suitable as an introductory programming 
-        language, but they were taught because they were used in the industry.
-    </p><p>
-        During the course of IT education, several languages need to be 
-        studied - at least one dynamic language such as Perl, Python or Ruby
-        , ANSI C, an assembler, Lisp (Scheme or Common Lisp), Haskell, O'Caml
-        or SML, and probably some specialised languages when they are
-        appropriate. But the first language need not be what is the most
-        hyped language in the industry, or even what most the rest of the
-        studies will be conducted in.
-    </p><p>
-        From my <a href="http://www.shlomifish.org/philosophy/computers/education/opinion-on-the-technion/" target="_top">impression of the Technion</a>, the 
-        institute as a whole believes that students can effectively write all
-        their code in ANSI C. In some courses, the choice of C++ and Java are
-        given, but these languages are not effectively taught. Most students,
-        during their studies, had not been exposed to such advanced paradigms
-        as regular expressions, dynamic-typing, Perl 5-like nested data 
-        structures, run time evaluation, closures and dynamic functions, and
-        others that are considered common knowledge among developers of
-        dynamic languages, and any software development enthusiast who is
-        worth his weight in salt. 
-    </p><p>
-        So my opinion still remains: Perl, Python or Ruby are the best
-        languages for introducing non-programmers to programming, while Perl
-        is the best, and Python is probably still the worst of the three.
-        However, note that any decent programming training will introduce his
-        developers to more than one language, and a prospective programmer
-        should not worry if he started out with a language that I consider
-        sub-optimal. With good ambition and motivation and with the right
-        attitude ("I know that I do not know"), one can become a better and
-        better programmer regardless of his background.
-    </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="other_good_food_for_thought"></a>Other Good Food for Thought about Teaching</h2></div></div></div><p>
-        This section will bring other good for thought about teaching.
-    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="live_learn"></a>"Live as if you were to die tomorrow. Learn as if you were to 
-            live forever."</h3></div></div></div><p>
-            This is a quote attributed to
-            <a href="http://en.wikipedia.org/wiki/Mahatma_Gandhi" target="_top">Gandhi</a>.
-            The "Learn like you were going to live forever" part is not widely
-            understood by many workers. Many programmers believe that their
-            knowledge of a few programming languages is enough, and that it is
-            not necessary that they learn completely different ones.
-        </p><p>
-            It is well known that learning a new and different programming
-            language will make you a better programmer also in the original
-            languages you know. Programmers who don't learn new programming 
-            languages eventually stagnate. They are bounded by their limited
-            knowledge, and cannot think outside their box. They deserve the
-            stagnation they receive due to this bad attitude, and mental
-            laziness.
-        </p><p>
-            If you want to grow as a programmer, make sure you keep studying
-            new languages and technologies. Not only they may turn out to be
-            useful, but they'll also make you think in completely ways.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="three_levels_of_learning"></a>Three Levels of Learning</h3></div></div></div><p>
-            Rabbi Hanina used to say "I learned a lot from my teachers,
-            and from my friends more than my teachers, and from my pupils the
-            most." I believe this means that there are in fact
-            three levels of learning: 
-        </p><div class="orderedlist"><ol type="1"><li><p>
-                    <span class="bold"><strong>Level 1 - Learning</strong></span> - 
-                    this is a passive learning of the
-                    material, where one inputs the material.
-                </p></li><li><p>
-                    <span class="bold"><strong>Level 2 - Experiencing</strong></span>
-                    - in this level you work with the material you learned,
-                    and try to implement what you've learned and integrate it.
-                    This requires more understanding, because you have to
-                    work with the material.
-                </p></li><li><p>
-                    <span class="bold"><strong>Level 3 - Teaching</strong></span>
-                    - in this level you teach the material to someone
-                    else. This requires the most understanding because
-                    you need to organise it properly and convey it to
-                    someone else.
-                </p></li></ol></div><p>
-            Perhaps there's a fourth level - 
-            <span class="bold"><strong>Science</strong></span> in which the knowledge
-            is expanded. However, this implies that to truly understand the
-            material, one needs to experiment with it (preferably in 
-            production) and better yet teach it to someone else.
-        </p><p>
-            The old adage "He who can - does. He who cannot - teaches." which
-            was
-            <a href="http://en.wikiquote.org/wiki/George_Bernard_Shaw" target="_top">said 
-                by George Bernard Shaw</a> is amusing, but simply not
-            true, as I've demonstrated here. Being a great teacher is much more
-            difficult than being a great doer, and is much more enlightening.
-            <sup>[<a id="id2807832" href="#ftn.id2807832">those_who_can</a>]</sup>
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="learn_many_languages"></a>Learn as Many Languages as Possible</h3></div></div></div><p>
-            Learning one computer language is not enough. Knowledge of only
-            one computer language or a few cripples the mind and causes the
-            brain to run in circles. Different programming languages introduce
-            different insights: various easier ways to do certain things,
-            different restrictions , different syntax, different APIs,
-            different ways of doing things, different high-level mechanisms 
-            (or lack of them). All of this give different understandings
-            of how to program in any language.
-        </p><p>
-            Many people believe that their limited knowledge is adequate.
-            Java programmers are especially notorious for being opposed to
-            the ideas of them having to learn different languages. The
-            <a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=nosim/shlomifishhom-20" target="_top">Pragmatic 
-                Programmer book</a> (which I have yet to read), says
-            a programmer should learn a new computer language every year,
-            and I tend to agree with it. I compiled <a href="http://www.shlomifish.org/philosophy/philosophy/advice-for-the-young/#technologies_to_learn" target="_top">a 
-                tenative list of the technologies I found the most 
-                enlightening</a>, and I recommend programmers to learn
-            at least all of them.
-        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="learning_to_read_and_enhance"></a>Learning How to Read Code and Enhance Existing Code</h3></div></div></div><p>
-            At present, universities and other spend most time teaching
-            programmers how to write code. However, most of what programmers
-            have to do for work or for pro-bono work (like open source
-            projects) is to read code, and to enhance existing code.
-        </p><p>
-            <a href="http://www.joelonsoftware.com/" target="_top">Joel Spolsky ("Joel on
-                Software")</a> gave the following 
-            "cardinal rule of programming" in his famous
-            <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" target="_top">"Things you must never do, part I" essay</a>:
-        </p><div class="blockquote"><blockquote class="blockquote"><p>
-                It's harder to read code than to write it.
-            </p></blockquote></div><p>
-            My friends and I later <a href="http://tech.groups.yahoo.com/group/hackers-il/message/3576" target="_top">discussed this topic in the Hackers-IL 
-                mailing list</a>. Even if code is given for reading in
-            university, it is usually extremely well-written, highly organised,
-            highly legible, code, rather than the real code that programmers are
-            likely to encounter in the wild.
-        </p><p>
-            It's a shame most of the code students write as part of their
-            corriculum is only for themselves, and ends up being of little
-            value to the world at large. Even if some code ends up as an open
-            source project, it is usually too incomplete and lacks essential
-            functionality or correctness to be of any use in the real world. 
-        </p><p>
-            As Joel points out in the article, most programmers end up saying
-            that the code they are working on is horrible and that they wish
-            to completely rewrite it if they have the chance, instead of
-            <a href="http://www.refactoring.com/" target="_top">refactoring</a> it
-            to make it better.
-        </p><p>
-            Furthermore, since reading code is harder than writing it, then
-            it makes sense that programmers who are good at reading (or
-            refactoring code or enhancing it) are much better programmers,
-            than programmers who are only good at writing new code. I wish
-            I had a dollar for everytime I heard of someone trying to rewrite
-            an existing functional and relativley bug-free codebase from
-            scratch, just because this codebase was deemed of too little 
-            quality, and that afterwards this rewrite ended up at nothing.
-            These case practically dwarf the number of successful rewrites
-            I recall.
-        </p><p>
-            To sum up, it will be a good idea to teach first-time programmers
-            how to read real-world code, or the code written by their
-            co-students, and how to enhance it by extending it, and cleaning
-            it up.
-        </p></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.id2807832" href="#id2807832">those_who_can</a>] </sup>
-                What is true, in my opinion. is that "Those who can - do. 
-                Those who can't - complain." However, often people who can 
-                and do, still complain. I recall this quote being
-                attributed to 
-                <a href="http://en.wikipedia.org/wiki/Linus_Torvalds" target="_top">Linus
-                    Torvalds </a>, but it <a href="http://shlomif.livejournal.com/39215.html" target="_top">predates him</a>.
-                </p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="thanks"></a>Thanks</h2></div></div></div><p>
-        Thanks to Pete_I on Freenode, 
-        <a href="http://www.zak.co.il/" target="_top">Omer Zak</a>,
-        <a href="http://www.wgz.org/chromatic/" target="_top">chromatic</a>
-        Jonathan Scott Duff, Sagiv Barhoom and others for reviewing 
-        early drafts of this essay and giving some editorial assistance. 
-    </p></div></div></body></html>

t2/open-source/anti/qmail/index.html.wml

 
 <ul>
 <li>
-<a href="http://www.mail-archive.com/linux-il@cs.huji.ac.il/msg42279.html">Linux
--IL mailing list</a></li>
+<a href="http://www.mail-archive.com/linux-il@cs.huji.ac.il/msg42279.html">Linux-IL 
+mailing list</a></li>
 <li>
 <a href="http://zgp.org/pipermail/linux-elitists/2005-November/011333.html">Linux-elitists</a>
 </li>

t2/philosophy/computers/education/introductory-language/index.html.wml

 
 <h2 id="itself" style="clear:right;">The Article Itself</h2>
 
-#include "../lib/docbook/rendered/intro-prog-lang.html"
+#include "../lib/docbook/rendered/introductory-language.html"
 
 <h2 id="other_formats">Other Formats</h2>
 

t2/philosophy/computers/software-management/end-of-it-slavery/index.html.wml

+#include '../template.wml'
+#include "xhtml/1.x/std/toc.wml"
+#include <utils.wml>
+
+<latemp_subject "The End of Info-Tech Slavery" />
+
+<h2 id="main_intro">Introduction</h2>
+
+<p>
+Do you want to find good software developers? Do you have a problem finding
+ones? Have you been unhappy with your latest jobs? Read this and understand 
+why.
+</p>
+
+<h2*>Table of Contents</h2*>
+
+<toc />
+
+<h2 id="itself" style="clear:right;">The Article Itself</h2>
+
+#include "../lib/docbook/rendered/end-of-it-slavery.html"
+
+<h2 id="other_formats">Other Formats</h2>
+
+<ul>
+<li>
+<a href="./end-of-it-slavery.pdf">Acrobat Reader (PDF) Format</a>.
+</li>
+<li>
+<a href="./end-of-it-slavery.xml">Original DocBook/XML</a>.
+</li>
+</ul>
+
+<h2 id="coverage">Coverage</h2>
+
+<p>
+None yet.
+</p>
+