[Edu-sig] recent curriculum writing (Urner)

Edward Cherlin echerlin at gmail.com
Thu Oct 15 09:51:23 CEST 2009


Computer languages in use can be as different as FORTH, APL, LISP,
Smalltalk, C++, Python...In principle, any symbolic system that is
Turing-complete can serve as a general-purpose computer programming
language with a suitable compiler or interpreter.

Jean Sammet wrote a summary of all computer languages up to the
mid-1960s, called Programming Languages: History and Fundamentals. She
wanted to do a new version later, but found that she couldn't possibly
keep up with them all any more. A fairly recent compendium listed more
than 8500.

See also The Next 700 Programming Languages, by P. J. Landin,

http://www.scribd.com/doc/12878059/The-Next-700-Programming-Languages

the Parrot languages page,

http://www.parrot.org/languages

and the Esoteric Languages page

http://esoteric.sange.fi/orphaned/obslang.html

Sadly, the Random Languages/Obfuscated Languages page is no longer
online, but you can still see it through the Internet Archive's
Wayback Machine.

http://web.archive.org/web/*/http://esoteric.sange.fi/orphaned/obslang.html
http://web.archive.org/web/20080417042236/http://esoteric.sange.fi/orphaned/obslang.html

These last are where you find the weird languages, such as Fromage,
Intercal, Befunge, Unlambda, Malbolge, and many more, some designed to
be fun, some just to prove it could be done, and some to be evil.

On Thu, Oct 8, 2009 at 13:36, kirby urner <kirby.urner at gmail.com> wrote:
> What do we mean by "computer language"?

What do we mean by "computer"?

> One could answer in terms of
> using text to control electronics, and that would be accurate.
> However there's also the goal of a philosophical logic:  to express
> situations in the world, to mirror them for the purposes of
> simulation.
>
> The veteran programmer of the late 1900s experienced a number of
> twists and turns in the art of computer programming.  This field has
> evolved quickly.  Early machines had to be programmed "close to the
> metal" meaning a deep understanding of hardware internals was needed
> to even begin to write code.
>
> Today's computer languages haven't completely divorced themselves from
> hardware concerns,

although Virtual Machines are increasingly common, including the Java
VM, the I-APL 8-bit VM, the Smalltalk VM, Parrot, and so on.

> but the higher level ones are freer to concentrate
> on what we sometimes call "knowledge domains" such as cellular
> automata, molecular biology, zoology, telescopy etc.
>
> When talking about human languages, we have something we call grammar.

See also the Chomsky hierarchy of languages and the corresponding
hierarchy of machine types.

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

> It helps to know the difference between a verb and an adjective, an
> adjective and a noun.  In many of today's computer languages, nouns
> name objects

More often pronouns that name different things at different times.
Nouns would be constants.

> which have attributes (like adjectives) and behaviors
> (like verbs).

And APL/J and some functional programming languages have adverbs to
make new verbs from old!

> Here's an idea of what computer code might look like:
>
> anAnt = Ant()
>
> critter = AntEater()
> critter.color = 'brown'
> critter.walk(paces=10)
> critter.eat(anAnt)

Or possibly

   mean =. +/ % #
   i. 10
0 1 2 3 4 5 6 7 8 9
   +/ i. 10
45
   # i. 10
10
   mean i. 10
4.5

or

The following Unlambda program calculates and prints the Fibonacci
numbers (as lines of asterisks)

```s``s``sii`ki
  `k.*``s``s`ks
 ``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk
  `k``s`ksk


> If you've studied some mathematics, you may be used to reading "=" as
> "equals".  You're free to keep doing that, but add the thought that
> "=" is an "assignment operator" and what it does is bind a name to an
> object.

In languages where = is assignment, equality is usually ==. Other
conventions are used.

> In the above segment of code, the Ant and AntEater types are
> instantiated and assigned to names.  These names are then operated
> upon using "dot notation" such that attributes get set and behaviors
> such as eating invoked.
>
> Notice that we already have a tendency to think in terms of things (a
> very generic statement).  Think of an airport.  What "things" do you
> suppose it would have?  Runways and taxiways would define paths for
> the airplanes.  There might be a control tower.  Lots of things have
> come to mind already.
>
> A single airplane has many attributes and behaviors.
>
> pdx = Airport()
> nw  = Runway()
> pdx.add(nw)
> myplane = Gulfstream()
> myplane.takeoff(nw)
> myplane.land(nw)
>
> We also have an engrained concept of the more general versus the more
> specific.  There's the generic idea of a house, animal, airport.  Then
> we get more specific, getting to some individual instance of example
> of any of these types of object.
>
> A computer language might have this same idea:  there's a type of
> thing called a Number, and then we have individual instances of
> Number, such as 3, -1 or 2.12 or whatever.
>
> Suppose you had a generic blueprint for a robot dog.  You could create
> an instance of this blueprint at any time, and then modify the
> specifics to give yourself an individual dog.  Each "instance" would
> take up its own place in memory, even though the blueprint is shared
> among all these instances.
>
> Imagine a snake named Selma, maybe a cute cartoon snake.  She has a
> sister named Bella.  Creating these two snakes from the Snake template
> might look like this:
>
> selma = Snake()
> bella = Snake()
>
> At this point, all that differentiates these two snakes are their
> names.  Two snake objects have been born, and assigned to names.  Now
> we might modify each snake separately:
>
> selma.color = 'red and brown stripes'
> bella.color = 'various shades of gray'
>
> One might eat a mouse, the other might eat a cupcake:
>
> selma.eat('mouse')
> bella.eat('cupcake')
>
> Notice our "dot notation" has so far mostly followed these grammatical patterns:
>
> noun = Type()
> noun.adjective = value
> noun.verb()
>
> It maybe help to think of open-close parentheses as a "mouth".  Think
> of emoticons like :-) or :-().  The () is clearly a mouth.  A mouth
> eats or takes in.  We call often call the things a mouth eats its
> "arguments".
>
> An event such as noun = Type() is akin to the birth of a creature or
> instance from its generic type.
>
> Then we make our noun do things or define its attributes, with
> noun.verb(arguments) or noun.adjective = value.  Also, we don't just
> set attributes (store them), but we also get them (retrieve them).
>
> What's important to realize about the above quick run through is we've
> nowhere had to discuss the internals of a computer or how it works.
> Writing scripts will require naming our actors and defining their
> behaviors, their interactions.  Writing a program is a lot like
> scripting for theater.
>
> We need to know how to express ourselves grammatically in a computer
> language.  But that's the same with ordinary human languages, so this
> need shouldn't seem too alien or unfamiliar.
>
> Now, the grammar suggested above is characteristic of several computer
> languages, but certainly not all of them.  Given we're heading into a
> study of the Python computer language, all of the above is apropos
> (relevant).
>
> This way of thinking, using dot notation, will also serve you when
> learning JavaScript, Java, C#, Ruby and several other languages,
> should you choose to develop your skills in any of these directions.
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>



-- 
Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://earthtreasury.org/


More information about the Edu-sig mailing list