[PLUG] Re: new guy with questions

Rogan Creswick creswick at gmail.com
Tue Jun 13 22:32:02 UTC 2006


On 6/13/06, Eric Biggs <eric.biggs at hotmail.com> wrote:
> My understanding of computer languages is not that extensive.  I kind of
> thought that in computer languages there were "high", "assemby" and
> "mechanical," where a compiler was necessary to *interpret* from a
> high-level language to a mechanical one enabling the computer to understand
> the human.  Therefore, I was under the impression that most of the
> programming that was done would have to utilize an High-level language.  I
> also thought that assembly languages were one step removed from a mechanical
> one, again not being utilized as often.

Your understanding is correct, but amongst the "high-level" languages
(by which I mean anything less intense than Assembly, and say, more
intense than Excel or Hypercard) there are also many differences in
how much attention to you must pay to low-level details.  Generally,
the most obvious distinction between these languages is in memory
management.

In C, you must manage all the memory you use on your own -- if you
need storage for a bunch of numbers, first you have to figure out how
many numbers you will have, then you must figure out how much space
each number needs (this can differ depending on what computer the
program is run on, by the way), then you can make a call to a memory
allocation routine.  That allocation routine may or may not allocate
enough space, so you need to check for that before you use the memory.
 Finally, you can store your numbers.   If you've heard the term
"buffer overflow" in the context of security patches, or viriuses,
this is where they happen.  If you make a mistake with the memory
allocation in C, you may never notice -- everything *might* work just
fine, but one day somone may find out that under certain circumstances
your program allows anyone to overwrite the administrator password (or
something like that) because you didn't allocate memory correctly.
This is a very real problem, although it is much less of a problem
with Linux than it is with windows (because user space programs just
don't have access to things like the admin password).

The current hot Object-Oriented (OO) languages, such as Java and C#,
prevent problems like this by doing the memory management stuff for
you.  Generally speaking they do a very good job, but you might be
able to get a faster program by doing it yourself. (Emphasis on
might--it depends on many, many factors, especially since I'm not
talking about specific languages.)  C++ provides a bit of a mix
between the two -- I don't know c++ that well, but in my limited
experience with it I've found that at times I need to manage memory on
my own, and at other times it's done for me--while this is due in
large part to my ignorance of c++, both situations *are* possible,
which means that sooner or later you will have to deal with them both
if you use C++.

Having said that, regardless of the language you use, if you program
very much you will eventually need to know how memory management
works, even if you don't want to do it yourself.  (A good essay on
this can be found here:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html)

> >If you are interested in the theory of computer languages, then a
> >functional language may be more to your liking...
>
> Again, my knowledge (which can easily be incorrect) only recognizes the
> three categories....What is implied with a "functional language?"

There are many different programming paradigms, so far this thread has
mentioned three of them: Object-oriented, procedural and functional.
There are many more, contraint-based, data-flow, event-based,
logic-based, constraint-logic... etc.  The three mentioned are by far
the most common, although it is extremely difficult to classify any
single language into one paradigm.  Java is generally regarded as OO,
c is considered procedural, lisp and haskell are considered
functional.  OCaml claims to be OO/functional+some other stuff. (I say
claims only because I don't know from personal experience.)

Procedural languages are like recipies in a standard cookbook, a bunch
of instructions are listed in order.  A more complex program will
break things up -- like cooking a 7-course meal, each course might be
one recipe, but in the end it's just a list of instructions.  (Ok, ok,
in the end, *every* language is just a list of instructions, but since
we're talking about programming languages, I'm ignoring the
assembly-level details.)

Object-Oriented languages provide mechanisims for combining data and
logic in a way that can be more easily re-used.  With a procedural
language there generally aren't a lot of ties between the data and the
logic that manages that data, so you have to pass around the data and
the logic separately.  OO offers a solution to that by letting you
combine data and logic into reusable objects.  If procedures in
procedural languages are like recipes, Objects are like frozen dinners
-- the recipe and the food is combined.

Functional programs are more like mathematical proofs.  The core ideal
in a functional language is that everything is a function, and data is
never changed.  Therefore, if you want the some bit of data (say the
date) you call a function that returns the date, rather than accessing
a variable that already has the date stored in it.  This means that
you never need to worry about storage, or updating variables, or a
bunch of other things.  As long as every function knows exactly how to
do what it does, at any time, then things will work.  (As an aside,
this is a good thing to aim for in *any* language.)  One of the most
amazing things about functional languages is that functions are
treated as first-class citizens -- that is, they can be passed around
just like varibales and values in a procedural language!

So, if you need a function that does a very specific thing, you can
write another function that *creates* that function when the program
is run, and then you can run the created function later.  You can do
some of this with Object oriented languages, but functional languages
generally make it easier.

Finally, you can program in any paradigm in pretty much any language.
It's possible to write functional C, and you can write procedural
lisp.  Many paradigms aren't mutually exclusive either --
Object-Oriented languages involve lots of procedural elements, and as
I eluded to above, they have some functional aspects as well.
Regardless of the language, if you do any work with interfaces you
will need to use some sort of event-based paradigm.


--Rogan



More information about the PLUG mailing list