From: jdunning@phoenix.Princeton.EDU (John Alan Dunning)
Subject: Re: Simple programming language for Mac
Originator: news@nimaster
Organization: Princeton University
Date: Tue, 12 Jan 1993 01:58:59 GMT

In article <1993Jan11.231917.25419@ultb.isc.rit.edu> sjk6119@ritvax.isc.rit.edu writes:
>In article <1993Jan11.045343.7138@Princeton.EDU>, jdunning@phoenix.Princeton.EDU (John Alan Dunning) writes:
>I thought the whole idea here was how to get kids interested in programming the
>easiest and most beneficial way. If they don't like code, then guess what? They
>wouldn't like programming. It's better to find out now! Primitive or not, code-
>compile-debug is what's gotta be done. Actually, some BASIC implementations
>don't need to be compiled, you can just say i=i+1 and it does! Newer compilers
>like Think's wonderful environments, will help with the misplaced semi-colons.
>Such compilers are good for beginners, yet powerful enough for experts.

The history of programming is one of increasing abstraction away from
the circuits which are doing the computing itself.  The earliest
vacuum-tube computers, like ENIAC, were programmed by actually
rewiring the hardware.  That's pretty low-level.  Then came machine
language and assembly, which is basically a higher-level form of
machine language.  Then we got even higher-level languages, like BASIC
and C.  The next step is object-oriented programming, in which you can
link together objects without really worrying about what's going on
inside the individual objects, abstracting even further away from the 
underlying code. 

So I don't think we're stuck with the code-compile-debug cycle for
much longer.  The software industry wants to drastically cut down the
time it takes to produce an application.  OOP is one way of doing
this, through reusing code and upgrading the functionality of a
program by changing a single object instead of rewriting the whole
thing.  "Rapid-prototyping tools" will also let you quickly
cobble together a prototype of an application to test its interface
and overall design on real users.  The only way we really have
right now of creating a good interface is through continuous testing
and revision.  So you take the time you used to spend
debugging code and spend it on a prototype-test-redesign cycle which
lets quickly produce a usable interface before you've committed lots
of resources to writing the code.

>True. I'm contradicting myself, I'm sure. It's a two-ended topic. Ease of
>use vs. actual programming. I think the big problem, though, is that many
>couldn't learn HyperCard or BASIC even if they wanted to, and most don't
>even know what they are. For example, there's a kid in my English class 
>who wants to be a computer programmer. Why? I don't know. How many languages
>does he know? zip. It's tough to start learning.
>
>My first reason for wanting to program was games. AFter that it was because
>there'd be something I wanted to do, and a little utility to do it was $50.
>The point I'm at right now is just learning things as I want to learn them.
>Sure programming is tough, but I'd rather be up til 4AM writing a program
>then looking around a BBS trying to find a utility to do what I wanted.

There are a lot of different specialties rolled up into the word
"programmer," and I think they are going to become increasingly
fragmented.  There are the people who do the actual coding.  There are
human interface designers who may not be able to write code, but who
do the testing and design necessary to ensure that the application is
usable.  On large software teams there are also marketers, manual writers, 
graphic designers, cognitive scientists, and so on.  For the most part, gone 
are the days of the lone programmer working late into the night, who
creates everything form the code to the interface to the packaging.  I
think in general that's a good development for commercial software, because 
you have a larger and more diverse pool of talent from which you can draw to
create an application.  

So I don't think we should limit our notion of "programmer" to simply
"those who write code."  Obviously we'll always need people who can
write code.  But I don't think there's any need to force everyone who
wants to create programs to be able to code.  The kid in your English
class might make a great interface designer.  Why make him suffer
through learning Pascal or C if that's not what he's interested in?
Sure, if a kid doesn't like code, they're not going to like coding.
But that doesn't mean they might not be interested in and talented at
the process of designing a program, which has become very
team-oriented.  Clearly everyone on the team has to be able to speak
some sort of common language.  So the HI designers have to know
something about how a program works, and the programmers must have
an understanding of basic interface design principles.

My point is that I don't think we should overemphasize the coding
aspects of software engineering, which is what I think happens now.
It turns off a lot of people to programming specifically and to computers
in general.  A better approach would be to offer kids a range of
software tools which they can learn to use to create new programs.
Some kids will love writing code.  Some will love using higher-level
prototyping tools, maybe something like HyperTalk, to create custom
programs to help them do their long-division homework, for instance.  And 
some will be content to simply use the computer to word-process their papers.
The goal should be to show kids that there are many approaches you can
take to writing software, all of which are valuable in the design of
today's software.

>AppleScript looks like something good, though I have the CD right here and
>haven't even opened it.
>
>-Scott J. Kleper
>"Sgt. Kleper"

What CD is that?  I've seen beta versions of AppleScript, but has it
been released in final form yet?

John


Newsgroups: comp.sys.mac.games