Learning to programme

I've been reading the contributions to this topic with interest and
have given some thought to the best approach to learning to programme.

As with many of the contributors here, I've found myself learning a
number of different languages over the years, ranging from those that
are referred to as 'scripting' languages to those that are considered
'real' or 'serious' languages.

I can remember the difficulties I had getting certain key concepts
clear in my head when I first started to learn programming. These
'key concepts' are common to all programming languages that you are
likely to want to learn.

If you pick up a book on almost any language you will usually find a
chapter devoted to each of these concepts. They are Syntax,
Variables, Constants, Operators, Control Flow, Functions and
Structures or Classes.

Syntax: refers to the 'grammar' of the language. For example all
languages allow you to declare a variable, which is a space in memory
that may have a value assigned to it. Each language differs in how a
variable must be declared. It may be that in a particular language
all variables must begin with a particular character, such as a '$'
sign. Additionally certain characters are prohibited from being used
in variable names. Another example would be that each statement in a
language has to end with a certain character. In languages derived
from 'C' this would be a semi-colon.

Variables: As mentioned above a Variable is a place in memory which
may hold a value. Each Variable must be of a particular type. Each
programming language will have a limited set of 'types' to choose
from. e.g. 'int' to hold a number, 'char' to hold a non-numeric
character, 'string' to hold a sequence of these characters. They are
called 'variables' because the value may be changed by the program
while it is running. An 'Array' is an important kind of Variable. It
provides a sequence of placeholders in memory, each of which can hold
a different Variable. Each of these Variables held in an Array needs
to be of the same type (e.g. int).

Constants: As the name implies a Constant is used to hold a value
that will not change throughout a programs execution. e.g. MY_COUNTRY
= FRANCE;

Operators: These are used to alter a value by manipulating it in some
way. For example the common arithmetic operators for adding,
subtracting, multiplying, etc. are available in all languages. If
Variable ' a' currently holds the value '2' and Variable 'b'
currently holds the value '3' and you want Variable 'c' to hold the
value of multiplying a and b together, in accordance with the Syntax
of the language you might write: c = a *b; Here you would be using
the assignment operator to assign a value to 'c' and that value would
be obtained from using the multiplication operator '*' between 'a'
and 'b'.

Control Flow: All languages have the means to determine whether a
particular action (or actions) should be taken based on a test for a
particular condition (or set of conditions). Such a condition is
commonly a test to determine whether or not a variable holds a
particular value. This is where you could say the 'intelligence' of
your program resides. For example 'if' statements are Control Flow
statements: if (c == 3){ print "hello world!";} Note the double
equals sign here. In C and C derived languages this Syntax is used to
test what value c currently holds. If only a single equals sign were
used it would have the effect of assigning the value of '3' to 'c'
whereas here we want to find out if 'c' currently holds '3' or some
other value. When a test needs to be performed repeatedly the test is
performed within a loop. For example 'while' is another Control flow
statement: while(c==3){print "hello world!";} Be careful! You'll need
some way of jumping out of this loop or your program will print
"hello world!" forever :-(

Functions: Programs are broken down into Functions for efficiency and
ease of understanding. Each Function contains programming code
designed to do a particular job. A function may contain Control
flows, Variables, Constants and other programming statements which
make use of operators for variable assignment. They may also contain
programming statements which are calls to other Functions within your
program or other Functions provided to you which you have not written
yourself. This last point is very important. Most programming
language environments contain large libraries of particular Functions
for various tasks provided to you for free :-) If you want to make
use of a particular library of Functions within your program you may
have to 'import' that library using an 'import' statement at the top
of your file. e.g. <import maths>
Always check what's available in these Function libraries before you
attempt to write a Function for a particular task. It might already
have been written for you. In fact you may even want to make use of a
particular programming language for a certain job because you know it
contains a library of useful Functions for that task. In time you may
also build up your own library or libraries of useful Functions which
you've written yourself and may wish to make use of in new programs
you write. You might also make these available to other people. When
it comes to object oriented programming languages you can replace the
term Function with Methods (or in Objective C, Messages) These
'Methods' are part of 'Classes'. An Object Oriented language will
typically contain whole libraries of useful Classes. Finally, a
Function may or may not return a value to wherever it was called from.
For a simple program all your Functions may exist within one program
file, or your program may even consist of just one Function. More
complex programs are best organized into files of related Functions.
In Object Oriented programming each of these files would usually
correspond to a Class.

Structures or Classes: You may often find that Variables within your
program logically belong together and, therefore, it becomes useful
to group them together into a single entity. For example an Employee
usually has a name (string) age (int) salary (float), address
(string). C introduced the 'struct' entity so you could keep these
variables together under a single entity that you may call 'Employee'
in this case. The 'Employee' struct then becomes a new Type of
Variable which you can use in your program to refer to each Employee.
If you had an employee named 'Fred' and you wanted to give him a
$1000 raise, you might write: Fred.salary = Fred.salary + $1000;
Object Oriented programming takes this a step further by adding
Methods (the equivalent of Functions) inside this entity and refers
to the entity as a Class. In the case of an Object Oriented language
'Fred' would be an instance of the Employee class and you may ask an
adjustSalary method of the Employee class to increase Freds' Salary
by $1000.

I hope this brief introduction to what can be a confusing field will
help to break it down for you. Clearly people have their favorite
languages. When I first started programming on the Mac, Pascal
dominated; but I put my money on C because I felt it would dominate.
I bet right, since C is dominant now, in that so many languages are
derived from it and share its basic Syntax.

For that reason my advice would be to start with a relatively simple
'scripting' language which is derived from C, such as PHP and then,
if you wish, graduate to one of the 'rea'l C languages such as
Objective C (Cocoa).

geoff

On Sat, 9 Sep 2006 21:23:24 +0200, Nik wrote
(in message <91B2E108-2E4F-410B-8074-92092F490874inik.net>):

> Then there's scriping with a GUI, which is our half a language. Ruby,
> Python and Perl can all interface with a windowing system like GTK,
> which runs under X11 on the Mac.

While GTK runs on the Mac, I wouldn't recommend it as it doesn't allow to
build something that works and looks like a native MacOS X application.

With Python, you have a really large choice of GUI frameworks:

- If you don't need a cross-platform GUI, use Cocoa.
- If you need a cross-platform GUI, use either wxwidgets or Qt.

Hopefully some day someone will make PyObjC work with GNUstep, and then
Python applications with a Cocoa GUI will become easily portable.

> Okay, next level of complexity up is web development. This would be,
> most likely, PHP or Ruby on Rails since you're on a Mac, but also
> includes ASP, ASP .NET (Windows), ColdFusion, WebObjects, etc... Of
> all of these, PHP or Ruby on Rails will be the shortest learning
> curve and are free and well supported on the Mac.

Python is commonly known as the language that offers "more web frameworks
than keywords" to choose from.

From such trivially simple things like rest2web up to the mighty Zope3.

> Lastly, there's "real" programming languages. That's the C's of the
> world (C++, C#, Objective C -- a.k.a. Cocoa), Java, Lisp, etc.

Lisp and Java aren't any more "real" programming languages than Python or
Ruby are.

For GUI applications, Java is a non-starter, I haven't seen a single Swing
application yet that doesn't look and feel absolutely horrible on _any_
platform and that doesn't leak memory like a barrel without a bottom. And the
only SWT application I know of, Exclipse, is a monstrous resource hog.

Python is as fast as Java for nearly any kind of application, although much
more lightweight. And where it still isn't fast enough, all you have to do to
make your application as fast as compiled C code is to "import pyrex", add
static type declaration for your variables and run the module through
distutils. Not to mention that Python solves the same problem with a _lot_
less lines of code than Java. For example, TinyERp has eomthing like 25.000
lines of Python code, while Compiere counts over 450.000 for roughly the same
functionality (Compiere doesn't even have MRP).

Any kind of C dialect is definitely not a beginner language.

And you forgot one good choice for a beginner: Eiffel, which integrates well
with Xcode and Cocoa, and also has a cross-platform development environment
available.

Unfortunately, Freepascal has no support for Cocoa, so your only choice for a
GUI on MacOS X is Qt.

> C++ is kind of dying on the Mac, however, with Metrowerks pulling out
> of the game,

Afaik the GNU C compiler used by Xcode happily compiles mixed Objective-C++
code, even if you mix it within one and the same sourcecode file.

> Java, on the other hand, is well supported on the Mac,

It is a dead end for desktop applications, Apple themselves does no longer
develop the Cocoa bindings for Java.

Sincerely,

Wolfgang Keller

--
My email-address is correct.
Do NOT remove ".nospam" to reply.

>> Perl, which is excellent for really tiny scripts for text
>> processing, but if one day you happen to find out that you need something
>> for
>> implementing actually non-trivial applications
>
> Flapdoodle. Some very non-trivial huge important widely-used stuff is
> written in Perl,

Yes, and entire ERP suites have afaik been written in Assembler - in the
70's, for IBM mainframes.

While such things are possible (and I didn't claim they weren't), in the real
world some criteria like efficiency, maintainability etc. also happen to be
actually relevant besides pure feasibility.

> such as Bugzilla:
> <http://www.bugzilla.org/>
>
> Having said that, though, there are an awful lot of users who wish it had
> been written in anything *but* Perl. m.

Probably for the same reasons why it gets more and more replaced with Trac.

And no, I won't mention which language Trac is implemented in.

Sincerely,

Wolfgang Keller

--
My email-address is correct.
Do NOT remove ".nospam" to reply.

On 9/10/06 22:59, "Wolfgang Keller" <wolfgang.keller.nospamgmx.de> wrote:

>>> Perl, which is excellent for really tiny scripts for text
>>> processing, but if one day you happen to find out that you need something
>>> for
>>> implementing actually non-trivial applications
>>
>> Flapdoodle. Some very non-trivial huge important widely-used stuff is
>> written in Perl,
>
> Yes, and entire ERP suites have afaik been written in Assembler - in the
> 70's, for IBM mainframes.
>
> While such things are possible (and I didn't claim they weren't), in the real
> world some criteria like efficiency, maintainability etc. also happen to be
> actually relevant besides pure feasibility.

I know this is a silly question, but how does the start of yet another
endless argument of "which programming language is teh kewlness" actually
help with figuring out the best way to program?

Honestly, the idea that we still type in code for stuff as high level as
perl/python/every other scripting language shows just how little real
improvement there's been in programming over the last decade or more.
Considering that in *1994* I was building IVR systems that interfaced with
multiple database types and host platforms, and doing so in a 4GL that
required *zero* code typing, I'd have to say that programming hasn't really
improved that much in that time, if at all, and that to be blunt, we've not
improved, we've actually backpedaled.

I was quite amused at how many people thought Automator was somehow new
and/or innovative, when the truth is, it was neither. it just has better PR.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 20:59 09/10/06 -0700, Geoffrey Armstrong wrote:
>For example an Employee
>usually has a name (string) age (int) salary (float)

Just one quibble in a good summary of the elements of programming. I'd
ignore it completely except that it's such a common misconception and error.

Amounts of money (such as salary) should almost never be stored in a float,
because the fractions are not represented exactly, and round-off errors can
result in incorrect results. As simple an amount as $0.20 cannot be
represented exactly in a binary float. Amounts of money should be stored as
integers, scaled as necessary to the smallest unit of the currency in use.
For example, dollar amounts should be stored with a scale factor of 100 --
basically storing cents rather than dollars.

Edward
Art works by Melynda Reid: http://paleo.org

Good afternoon,

On 9/9/06 at 12:23 PM -0700, Nik <gerberinik.net> wrote:

>Okay, next level of complexity up is web development. This would be,
>most likely, PHP or Ruby on Rails since you're on a Mac, but also
>includes ASP, ASP .NET (Windows), ColdFusion, WebObjects, etc... Of
>all of these, PHP or Ruby on Rails will be the shortest learning
>curve and are free and well supported on the Mac.

You really need to include Perl in that list, especially when developing web
applications using Catalyst. It is the 'Rails' for Perl. And I don't know any
scripting language other than Perl which lets you control all aspects of Apache
(& not just the request phase).

<http://www.catalystframework.org/>
<http://perl.apache.org/>


Charlie

--
   Charlie Garrison <garrisonzeta.org.au>
   PO Box 141, Windsor, NSW 2756, Australia

On 2006-09-06, at 08:52, David Ross wrote:

> Have you considered something like SAS? It's a package that will
> analyze things 6 ways to Sunday and beyond. Plus it does have a
> programming language.

I've made a career out of SAS, and while it would make the
programming for this straight-forward, it does have a major stumbling
block: you have to rent the software, starting in the thousands of
dollars per year.

And John, I'm sure it wasn't after your time--it's been around since
the '70s!

On Sep 10, 2006, at 11:59 PM, Wolfgang Keller wrote:

>
>> C++ is kind of dying on the Mac, however, with Metrowerks pulling out
>> of the game,
>
> Afaik the GNU C compiler used by Xcode happily compiles mixed
> Objective-C++
> code, even if you mix it within one and the same sourcecode file.
>

C++ is alive and well. GCC (and XCode) support C++ very well. In fact
IOKit is based on C++ objects.

While I have been enjoying this thread I think one major consideration is being overlooked. Personally, I don't think it really matters which language you decide to start with. The most important thing might be the material with which you tackle that language. No matter what language you choose, if you pick a book that is rough going, boring or has you working on exercises you don't find interesting your chances of sticking it out to the point of understanding are lessened. On the other hand, if you start with the right book, you'll stay motivated, interested and probably come to have a reasonable ability with it.

With this in mind I would probably recommend one of the following...

Learn C on the Macintos http://www.spiderworks.com/books/learncmac.php

I haven't read this but I have read one of Dave Marks previous books and found his style very engaging and easy to follow. He has an ability to balance the details with simple examples that reinforce the material and make it easier to grasp. It's a PDF and you can download a free preview on that page.

Learn Objective-C on the Macintosh http://www.spiderworks.com/books/learnobjc.php

This looks like more of a follow on from the book above rather a place to start.

Learn to Program http://www.pragmaticprogrammer.com/titles/fr_ltp/index.html

This one uses Ruby. Again, I haven't read this but the few books I have read from the Pragmatic Bookshelf have been relatively well written/edited, relevant and easy to follow. Available as a PDF or a printed book.

There are most definitely similar books available for any language that grabs your interest so the best thing to do might be to hit Amazon and check out the reader reviews. I would recommend starting with a book (PDF is OK) though. While there is a ton of useful stuff online a book will deliver a more focused experience. Then when you're feeling somewhat comfortable with the material it will be easier to continue your studies on the web.

Anyway, here's hoping another perspective is helpful and good luck!

Kevin LaCoste

I would like to add one more thing to this discussion: The best book
series for beginning programmers is the Head Rush/Head First series from
O'Reilly:

<http://www.oreilly.com/store/series/headfirst.csp>
<http://www.oreilly.com/catalog/headra/index.html>

The best thing about these books is that they're funny and engaging to
read. You don't need to force yourself to read them, you *want* to read
them. And of course, the content is up to the usual O'Reilly standards.

lucas

--
The Fifth Law of Thermodynamics: Things Get Worse Under Pressure

Since you already know BASIC, the procedural FutureBasic language (www.stazsoftware.com) is definitely worth a look. MacCompanion recently wrote an article comparing BASICs that might be of some use too. That link is: http://www.maccompanion.com/archives/June2006/Columns/AccordingtoHoyle.htm

Good Luck,

Brian Stevens

This comes from left field, but you can learn about the structure of programs -- as in diagrams -- while actually programming using Marten. It is an implementation of the Prograph programming language which is entirely visual, entirely interactive, and allows you to modify a running program and then continue. You draw the data flow diagram and run it.

It's a commercial product, maybe not the thing to ultimately implement your problem area, but a blast to play with and come to understand objects, flow of data, ideas related to inheritance and more.

A few nice links:

An enthusiastic description of using (playing with?) Prograph:

http://www.theotherblog.com/Articles/2005/03/04/QcKrlOSavI/

A product release announcement:

http://www.macnn.com/articles/06/02/01/marten.ide.13.released/

and the obligatory:

http://en.wikipedia.org/wiki/Prograph

My son, Andy, now 18, and I played with Prograph when he was about 7 or 8 and remembers it fondly as where he learned a lot about programming (and we really could work together on things programs with him on my lap, pointing at objects and wiring up connections :-)

A similar but definitely kid-oriented environment was available in Widgets Workshop from Maxis (no longer available).



-Dick

I'm starting work on my PhD in linguistics, and I want to be able to write and run some custom corpus-analysis software that will count particular types of character in Japanese text, and give me information about the frequency of these characters.

From Wikipedia:

"Larry Wall [the creator of Perl] was trained as a linguist, and the design of Perl is very much informed by linguistic principles. Examples include Huffman coding (common constructions should be short), good end-weighting (the important information should come first), and a large collection of language primitives. Perl favors language constructs that are natural for humans to read and write, even where they complicate the Perl interpreter."

Ergo, Perl should be very, very easy for you to pick up and understand.

Perl also has good support for Unicode characters right now, with great — core — support slated for the next major release. If you plan on crunching Japanese characters, you NEED good Unicode support.

So, I'd suggest you use Perl to do the initial analysis and then throw the results into Excel (or whatever) for further processing and the production of histograms and so-on.

On Sep 11, 2006, at 11:55 PM, Lucas K. Mathis wrote:

> I would like to add one more thing to this discussion: The best book
> series for beginning programmers is the Head Rush/Head First series
> from
> O'Reilly:
>
> <http://www.oreilly.com/store/series/headfirst.csp>
> <http://www.oreilly.com/catalog/headra/index.html>
>
> The best thing about these books is that they're funny and engaging to
> read. You don't need to force yourself to read them, you *want* to
> read
> them. And of course, the content is up to the usual O'Reilly
> standards.

My reaction was exactly the opposite: if I want to be
overstimulated, I'll watch MTV. O'Reilly do put out some excellent
books, some aimed at beginners, but I wouldn't include the Head Rush/
Head First line in that category.

On the other hand, I'm not exactly the target market.

Charlton


--
Charlton Wilbur
cwilburchromatico.net

On Sep 11, 2006, at 8:55 PM, Edward Reid wrote:

> Amounts of money should be stored as
> integers, scaled as necessary to the smallest unit of the currency
> in use.
> For example, dollar amounts should be stored with a scale factor of
> 100 --
> basically storing cents rather than dollars.

Or decimal-based floating point (as Microsoft provided in the "dollar-
sign" icon version of Basic for Mac, as just one example). But the
thing one is programming in or storing data with may well not provide
that.

But, as you say, certainly not "float" in the current IEEE-standard,
C-standard meaning of the word.

   --John

John C. Welch <jwelchbynkii.com> wrote:

> I was quite amused at how many people thought Automator was somehow new
> and/or innovative, when the truth is, it was neither. it just has better PR.

;-)

As for Automator, there is a terrible need for a "Take Control of
Automator"
[please don't flame on me if such a title really exists ;-)]

Believe it or no, I dont' catch it...
Maybe, I am too deformed by years of HyperCard (next MetaCard, next
Revolution!) and a little of AppleScript... I do prefer to "see" the
action "written" in lieu of confusing "actions" ;-)

On 12 Sep 2006, at 06:27 , Timo Pasanen wrote:
> Ergo, Perl should be very, very easy for you to pick up and
> understand.

#!/usr/bin/perl -w
# 531-byte qrpff-fast, Keith Winstein and Marc Horowitz <sipb-iap-
dvdmit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or
$t^=$c^=(
$m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,
$a^=12*($_%16
-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]
&48){$h
=5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/
1$&/;$
d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^
$d>>4^
$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t
[$_]^
(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval

even with adding LFs it's not easy to understand.

$t ^= (72, z= (64,72,$a^=12* ($_%16 -2 ? 0:$m&17)), $b ^= $_%64 ?
12:0,z) [$_%8]

is especially lovely.

--
Like the moment when the brakes lock/And you slide towards the big
truck/You stretch the frozen moments with your fear

On Thu, Sep 14, 2006 at 12:48:02PM -0700, Google Kreme wrote:
> On 12 Sep 2006, at 06:27 , Timo Pasanen wrote:
> >Ergo, Perl should be very, very easy for you to pick up and
> >understand.
>
> #!/usr/bin/perl -w
> # 531-byte qrpff-fast, Keith Winstein and Marc Horowitz <sipb-iap-
> dvdmit.edu>
> # MPEG 2 PS VOB file on stdin -> descrambled output on stdout
> # arguments: title key bytes in least to most-significant order
> $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or
> $t^=$c^=(
> $m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72,@z=(64,72,
> $a^=12*($_%16
> -2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]
> &48){$h
> =5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/
> 1$&/;$
> d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d>>12^
> $d>>4^
> $d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9,$_=$t
> [$_]^
> (($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
>
> even with adding LFs it's not easy to understand.
>
> $t ^= (72, z= (64,72,$a^=12* ($_%16 -2 ? 0:$m&17)), $b ^= $_%64 ?
> 12:0,z) [$_%8]
>
> is especially lovely.
>

Okay. You posted an intentionally compacted, obscured block of Perl code.
Is that supposed to prove something?

The authors of that code had a goal, which was to create a short, fast
DeCSS script. They accomplished that goal in Perl. If they had wanted to
create a very readable DeCSS script, they could have accomplished that goal
in Perl too.

Did you know that there's an annual International Obfuscated C Code
Contest? I could grab some winning entry from that and post it to the
list, and it wouldn't prove that C is difficult to understand or that
people shouldn't use it.

If you want to advocate for or against a particular language, please do so
honestly. We can do without the FUD.

Ronald

On Thu, 14 Sep 2006, Google Kreme wrote:

> On 12 Sep 2006, at 06:27 , Timo Pasanen wrote:
> > Ergo, Perl should be very, very easy for you to pick up and
> > understand.
>
> #!/usr/bin/perl -w
> # 531-byte qrpff-fast, Keith Winstein and Marc Horowitz <sipb-iap-
> dvdmit.edu>

If you're going for reduction to absurdity, you might as well go nuclear
and cite Damian Conway's SelfGOL:

  [...] an obfuscated, self-aware, viral quine that can:

    * self-replicate,
    * rewrite other Perl programs to allow them to self- replicate,
    * detect un-rewritable Perl programs,
    * execute itself or other Perl programs as cellular automata of
      arbitrary size (to play Conway's "Game of Life"),
    * animate any short text as a cycling marquee banner.

  SelfGOL accomplishes these feats in under 1000 bytes of standard Perl,
  without importing any modules, and without using a single if, unless,
  while, until, for, foreach, goto, next, last, redo, map, or grep.

#!/usr/local/bin/perl -sw
$;=$/;seek+DATA,!++$/,!$s;$_=<DATA>;$s&&print||$g&&do{$y=($x||=20)*($y||8);sub
i{sleep&f}sub'p{print$;x$=,join$;,$b=~/.{$x}/g}$j=$j;sub'f{pop}sub
n{substr($b,&f%$y,3)=~tr,O,O,}sub'g{$f=&f-1;($w,$w,substr($b,&f,1),O)[n($f-$x)+
n($x+$f)-(substr($b,&f,1)eq+O)+n$f]||$w}$w="\40";$b=join'',@ARGV?<>:$_,$w
x$y;$b=~s).)$&=~/\w/?O:$w)ge;substr($b,$y)=q++;$g='$i=0;$i?$b:$c=$b;
substr+$c,$i,1,g$i;$g=~s?\d+?($&+1)%$y?e;$i-$y+1?eval$g:do{$i=-1;$b=$c;p;i
1}';sub'e{eval$g;&e}e}||eval||die+No.$;
__DATA__
if($j){{$^W=$|;*_=sub{$=+s=#([A-z])(.*)#=#$+$1#=g}}
s=(q[$_=sprintf+pop@s,@s],q[
if($j){{$^W=$|;*_=sub{$=+s=#([A-z])(.*)#=#$+$1#=g}} #_The_Perl_Journal_#
s=(q[%s],q[%s])x2;%s;print"\n"x&_,$_;i$j;eval}
])x2;$_=sprintf+pop@s,@s;print"\n"x&_,$_;i$j;eval}$/=$y;$"=",";print
q<#!/usr/local/bin/perl -sw
if(!$s){>.($_=<>).q<}else{@s=(q[printf+pop@s,@s],q[#!/usr/local/bin/perl -sw
if(!$s){>.(s$%$%%$g,tr=[=[===tr=]=]=||&d,$_).q<}else{@s=(q[%s],q[%s])x2;%s}
])x2;printf+pops,s}
>

Citations:

    http://damian.conway.org/Seminars//Extreme.html
    http://libarynth.f0.am/cgi-bin/view/Libarynth/SelfGOL
    http://everything2.com/index.pl?node_id=1143566
    http://www.selectorweb.com/SelfGOL.tar.gz

But programs like this are being willfully (and playfully) obscure, and
one could write them in any language [1] -- there has been Obfuscated C
contests for almost 20 years now:

    http://www1.us.ioccc.org/years-spoiler.html
    http://www1.us.ioccc.org/winners.html

The ability to abuse a tool doesn't make it any less useful in the hands
of someone who isn't being malicious with it.


--
Chris Devers

[1] Yes, even Python: http://p-nand-q.com/python/obfuscated_python.html

On 15 Sep 2006, at 20:05 , Ronald J Kimball wrote:
> Okay. You posted an intentionally compacted, obscured block of
> Perl code.
> Is that supposed to prove something?

Since I see blocks of perl code like that (well, with line breaks and
spaces) on a daily basis, I would say yes, it is trying to prove
something.

perl is difficult for a human to parse under the best of
circumstances. With much complexity and lack of comments it quickly
becomes nearly invulnerable to any meaningful penetration.

In fact, perl is rather famous for it inscrutability, which is at
least part of the reason some people choose to use it.

At one place I worked there was one senior engineer whose only job
was maintaining a particular bit of perl code that he'd written a
decade or more before. He was the only one who could make heads or
tails of the source, so he had permanent job security.


--
Critics look at actresses one of two ways: you're either bankable or
boinkable.