[comp.sys.mac] Easy to Learn Mac Programming Environment

siegman@SIERRA.BERKELEY.EDU ("Anthony E. Siegman") (05/24/88)

This is one of those messages that will get me laughed at by ``real
programmers'', but what the hell . . .

There's continuing discussion of the best programming environment for
developing Macintosh applications, with MPW among the most widely favored for
obvious reasons.

What I want to point out here are the substantial, and largely unrecognized,
advantages in terms of
     --utility
     --simplicity
     --and most especially, speed of learning
of using Microsoft BASIC (!) as a programming environment for developing real
and genuinely ``Mac-ish'' (though maybe not too complex) applications for the
Macintosh.

To start with, for those of you who haven't looked at a modern BASIC lately,
MS BASIC has
  --no line numbers
  --unlimited length variable names and labels (at no cost in speed)
  --all the standard structured programming constructs
  --interpreter or compiler from the same source
  --subprograms with local variables and parameter lists (in and out) 
  --pretty nice built-in editor
  --easy screen graphics
and so on.  You still have to be careful about variable types, and remember
that all variables are global in the main program;  but your program design
can be as structured as you want to it to be (and a lot easier to read than
any other language).

Beyond that, all of the following Macintosh interface capabilities are
directly and easily available as built-in commands from within basic BASIC:
  --Windows     (4 types, 4 levels)
  --Menus         (full capabilities)
  --Mouse         (full capabilities)
  --Buttons      (all types)
  --Edit fields
  --SFGetFile     (for opening or saving files)
  --A very large fraction of QuickDraw capabilities 
  --Numerous Mac ROM routines
  --Clipboard access, in and out, text or pictures
  --Event driven programming (using trapping or polling), for Timer, 
      Mouse, Menu, or Dialog events.
In brief, you can make a BASIC program that looks every bit as Mac-ish as you
like -- and compile it immediately into a free-standing clickable
application.  

Beyond this, once you learn a little about resources and how to duplicate or
create them using REdit or ResEdit, by calling  a set of very easy to use and
syntactically very readable ``ToolLib'' library calls, which come packaged
with BASIC, you can very simply create, access and use a very large set of
Mac resources and Toolbox capabilities, including
    Arrays   Clipping    Alerts   Modal Dialogs   Graphics   Icons   
    Menus   Mouse commands   Patterns   Pictures   Points   Polygons   
    Regions   Resource Files   Scrolling   Strings   Text   Windows
In each of these cases, the Toollib calls look very much like the
corresponding Toolbox calls in ``Inside Macintosh'', but most of these
capabilities can simply be used;  nearly all of the initialization and clean
up hassles are largely avoided.  Essentially every aspect of the official Mac
interface is available in this way, along with callable library interfaces to
VideoWorks and other programs.

And again, when you're finished you can have a self-contained clickable
application, with its own resources, icon, ``About'' box, and so on.

The canonical statement heard from real Mac programmers seems to be something
like , ``I spent 9 months reading all 5 volumes of Inside Macintosh, and
struggling with MPW;  finally I got the picture and could start doing
things.''  My experience with a class I'm teaching right now is that
interested undergrads with ``high-school BASIC'' backgrounds can start
producing simple but real Mac applications within a few _weeks_ of beginning
programming on the Mac.

I'm not saying that I or anyone else would want to write a multi-featured
paint program or text editor or something similarly sophisticated in MS
BASIC.  But if you're a scientist,  or engineer, or high-school teacher or an
amateur prgrammer in any field, who has other responsibilities in life
besides Mac programming; and if you'd like to write a real Mac application
with a real Macintosh interface for your class or your job or your personal
use, doing it in MS BASIC is the only sensible choice I'm aware of.  You can
spend months to become capable in MPW -- or weeks with BASIC.

Finally, might just note that it's our experience -- don't want to push this
claim too hard, however -- that a compiled BASIC number crunching program (a
big simplex program, for example, or an FFT) runs every bit as fast in
compiled BASIC as the same program in any of the standard Pascals.

dorourke@polyslo.UUCP (David O'Rourke) (05/25/88)

In article <8805240408.AA01675@ucbvax.Berkeley.EDU> siegman@SIERRA.BERKELEY.EDU ("Anthony E. Siegman") writes:
>What I want to point out here are the substantial, and largely unrecognized,
>advantages in terms of
>     --utility
>     --simplicity
>     --and most especially, speed of learning

   First off you're assuming that you already know BASIC.  What if you don't
know anything.  Then LightSpeed Pascal, or Basic, LightSpeed C might be just
as good a
starter enviroment.  Although I agree with your unstated premise, that you
need a simple enviroment first, and then you should move up to a more complex
enviroment such as MPW.

>To start with, for those of you who haven't looked at a modern BASIC lately,
>MS BASIC has:

    NO Data Sturctures:  Where are the records, pointers, and composite
data types.  Although modern basic's have made an improvement, there is
still some problems with the way that Basic handles data structures.  Although
I've found Basic to be one of the best languages for string handeling.
    Also where are the Pascal Units?  Or the C header files.  No separate
compilations, or anything similar to a Unit.  So everything has to be in the
same source file.  No very good for large projects.

>can be as structured as you want to it to be (and a lot easier to read than
>any other language).

   What if you don't know the constructs for the way that your Basic interfaces
with the ToolBox, then is it easier to read than Pascal?  I know the toolbox
interface, not the One that MicroSoft implemented, the one that Apple
implemented.  So all I have to do is look in Inside Mac to find out what
a Pascal Call does.  Most mac programmer have this manual, so given a piece of
code I can look up the way they are doing things with standard reference
materials, I can't do that unless I have the Basic Manual.
   Here again it's only eaiser to read if you already know Basic, but I know
both and would prefer a Pascal, or C, Listing over Basic any day of the week.


>Beyond that, all of the following Macintosh interface capabilities are
>directly and easily available as built-in commands from within basic BASIC:

  But in your list you say there are limits imposed on how much you can do
from this Basic.  If you truely had access to the toolbox there would be no
limit.  So although Basic allows some calles, unless you can have access to
all the calls then you can't make a program as macish as you like.  What if you
want to use a custom window def, or control def, menu def, ect..
  Basic allows a significant sub set of calls to the toolbox, but the ones
missiing are also crucial to working with the Macintosh.

>And again, when you're finished you can have a self-contained clickable
>application, with its own resources, icon, ``About'' box, and so on.

>The canonical statement heard from real Mac programmers seems to be something
>like , ``I spent 9 months reading all 5 volumes of Inside Macintosh, and
>struggling with MPW;  finally I got the picture and could start doing
>things.''  My experience with a class I'm teaching right now is that
>interested undergrads with ``high-school BASIC'' backgrounds can start
>producing simple but real Mac applications within a few _weeks_ of beginning
>programming on the Mac.

   Have you tried Macintosh Pascal.  Wonderful enviroment!!  And you can move
your code to LightSpeed Pascal, and have it compiled.  How about Turbo?
Or even HyperCard!  With HyperCard it wouldn't take weeks, it would take
days.  There are easy to learn alternatives to MS Basic that provide more
functionality than Basic.

>with a real Macintosh interface for your class or your job or your personal
>use, doing it in MS BASIC is the only sensible choice I'm aware of.  You can
>spend months to become capable in MPW -- or weeks with BASIC.

   Or days with HyperCard.  Or even weeks with Turbo Pascal, or LightSpeed
Pascal, or Macintosh Pascal.  Even LightSpeed C would be good since a lot
of code ported from Unix systems is written in C.

   I agree that in some cases Basic is a good choice.  However you appear to
be un aware of other alternative that are just as easy to use.  Macintosh
Pascal in particular is the easiest programming enviroment I've ever seen.
Are there are several good books on using it for "text book" application that
involve graphics, and text.

-- 
David M. O'Rourke

Disclaimer: I don't represent the school.  All opinions are mine!

awd@dbase.UUCP (Alastair Dallas) (05/26/88)

MS_BASIC sounds like it has evolved into a good quick-and-dirty Mac
language with a good deal of power.  However, I have to take exception
to the comments to the effect that 1) "BASIC is a good first language
to learn," and 2) "BASIC includes all the structured constructs of 
other languages."  Because there is no data hiding (all variables
and labels have global scope), BASIC makes a terrible first language,
only a little worse than starting with assembly language.  The reason
is that someone who is used to having access to everything at all times
can usually find a way to bend an otherwise structured language (like C)
to maintain this same (wrong) world view.  Thus, BASIC-as-first-language
really does warp a programmer's attitude, making it difficult for him
to understand how to use a good language.  Second, BASIC may include
structured constructs like WHILE..WEND so that you can avoid the GOTO,
it still supports only scalars and arrays of scalars.  This is another
fine reason that BASIC is a bad first language: records or structs are
one of the most useful tools a programmer has for intelligent data
representation and for information hiding.  

By the way, my first language was BASIC.  I converted to C in 1983.

/alastair/

ee154aby@sdcc3.ucsd.EDU (Grobbins) (05/26/88)

In article <2843@polyslo.UUCP> dorourke@polyslo.UUCP (David O'Rourke) writes:
>   I agree that in some cases Basic is a good choice.  

Let's be a little more specific about what Basic is useful for on
the Mac.  David had some hits and misses in his assessment, at least
as far as the basic compiler I use, ZBasic, is concerned.

Simply put, Basic really is the easiest way to get a fairly Mac-like
application written.  With canned statements handling windows,
controls, text edit, and menus, it does free you from having to
worry about the details of the toolbox.  For people who haven't
learned the toolbox and really don't care to, but who also want to
create a respectable Mac application, it's the only choice.  And
the modern basics do allow for sufficient structure and breaking
up of source into separate files.

Yes, most Basic compilers are still relatively primitive in their
data handling compared with Pascal and C.  Yet Basic has proved
sufficient for thousands of tasks -- and once you quit the macho
posturing about the power of C or the convenience and cleanliness
of Pascal, getting programs written is what it's all about.

As for the litmus test of Mac languages, toolbox support, it's true
that Basic's provisions are rather pathetic.  Yet the calls that
ZBasic allows (most of the important ones) are sufficient to handle
an enormous number of situations in which the canned features of
the language don't cut it, like keyboard scanning, file system
access, and resource use.

If someone wants to become a Mac programmer, his best bets are
certainly Lightspeed C or Pascal or Turbo Pascal, and for large
projects, MPW.  But just like HyperCard is a construction kit which
allows non-programmers to solve simple problems, Basic is a good
choice of language for _real_ programmers interested in creating
a small to mid-size application of near-commercial quality.  And
it doesn't require any study of Inside Mac.

Grobbins     grobbins@ucsd.edu

jnp@calmasd.GE.COM (John Pantone) (05/28/88)

Anthony E. Siegman writes:

   This is one of those messages that will get me laughed at by ``real
   programmers'', but what the hell . . .

If you mean "language chauvanists" - so be it.  I still haven't seen
the language which is ALL THINGS TO ALL PEOPLE. (if we do - can we
name it PANACEA ? :-)

   ... omitted: a very well written description of Microsoft BASIC as a
   programming environment ...

   The canonical statement heard from real Mac programmers seems to be
   something like , ``I spent 9 months reading all 5 volumes of Inside
   Macintosh, and struggling with MPW;  finally I got the picture and
   could start doing things.''  My experience with a class I'm
   teaching right now is that interested undergrads with ``high-school
   BASIC'' backgrounds can start producing simple but real Mac
   applications within a few _weeks_ of beginning programming on the Mac.

Excellent point.  I have, for the record, seen much the same sort of
effect when using TransSkel (a Mac/Lightspeed C skeleton run-time
library). 

   ... more omitted ...

   Finally, might just note that it's our experience -- don't want to push this
   claim too hard, however -- that a compiled BASIC number crunching program (a
   big simplex program, for example, or an FFT) runs every bit as fast in
   compiled BASIC as the same program in any of the standard Pascals.

Why not?  A number crunching segment of code, by its very nature, is
well suited for optimizing compilers - and the speed is far and away
mostly limited by the CPU and/or math processor - not the code.

Thank you - I intend to investigate Microsoft BASIC.
-- 
These opinions are solely mine and in no way reflect those of my employer.  
John M. Pantone @ GE/Calma R&D, 9805 Scranton Rd., San Diego, CA 92121
...{ucbvax|decvax}!sdcsvax!calmasd!jnp   jnp@calmasd.GE.COM   GEnie: J.PANTONE

dorourke@polyslo.UUCP (David O'Rourke) (05/28/88)

In article <4200@sdcc3.ucsd.EDU> grobbins@ucsd.edu writes:
>Let's be a little more specific about what Basic is useful for on
>the Mac.  David had some hits and misses in his assessment, at least
>as far as the basic compiler I use, ZBasic, is concerned.
>
>Simply put, Basic really is the easiest way to get a fairly Mac-like
>application written.

   What about Macintosh Pascal?  Or V.I.P.?  There are other alternatives.

>the modern basics do allow for sufficient structure and breaking
>up of source into separate files.

   I'll have to look into this ZBasic.  I've only used MS-Basic.

>sufficient for thousands of tasks -- and once you quit the macho
>posturing about the power of C or the convenience and cleanliness
>of Pascal, getting programs written is what it's all about.

   Macho posturing has nothing to do with it.  It the power of Data
abstration that allows a programmer to concentrate on the job at had.
The purpose of abstration is not to be vague, but to produce a new
semantic level in which one can be absolutly precise  --- Misc. C.S. quote.

   Abstration also allows you to get programs written.  I can whip out a
pascal program just as fast as any basic programmer, but then we'll start to
make changes and additions, let's see the Basic handle that.

>allows non-programmers to solve simple problems, Basic is a good
>choice of language for _real_ programmers interested in creating
>a small to mid-size application of near-commercial quality.  And
>it doesn't require any study of Inside Mac.

  Oh boy I'd love to see some of these applications.  You mean the _real_
programmers at Ann Arbor should've used Basic and forgotten about the
toolbox.  for x := 1 to 1000000
             print ":-)"
          next x

-- 
David M. O'Rourke

Disclaimer: I don't represent the school.  All opinions are mine!

benjamin_kuo@pedro.UUCP (Benjamin Kuo) (05/29/88)

   
  I agree with your comments.  I have worked extensively with Basic, and 
Lightspeed Pascal, and I really think that Pascal is easier.  If you have 
every tried to truly monitor the BASIC toolbox calls (buttons, windows, etc.) 
you will find that you will have many more hassles than using a more 
structured code in Pascal.  In fact, the BASIC toolbox commands, esp. the 
Rect, Region, and other commands take alot of extra command space and are 
much slower than the slowest Pascal compiler. 

phil@mit-amt.MEDIA.MIT.EDU (Phil Sohn) (05/29/88)

In article <2788@calmasd.GE.COM> jnp@calmasd.GE.COM (John Pantone) writes:
>        A number crunching segment of code, by its very nature, is
>well suited for optimizing compilers - and the speed is far and away
>mostly limited by the CPU and/or math processor - not the code.

	A change of CPU or math processor will produce a increase in
speed of maybe 100% if you are lucky, but a really good optimizing
compiler will create a speed increase of 1000%.


		phil@ems.media.mit.edu

singer@endor.harvard.edu (Rich Siegel) (05/31/88)

In article <2948@polyslo.UUCP> dorourke@polyslo.UUCP (David O'Rourke) writes:
>   What about Macintosh Pascal?  Or V.I.P.?  There are other alternatives.

	Macintosh Pascal is not an alternative. Because there's no real runtime
system, you'd have to distribute source to whatever you write. If you're
going to get Mac Pascal, you might as well get Lightspeed Pascal, which
is nearly identical from the programmer's point of view, and offers
all of the advantages inherent to a compiled language.

>>the modern basics do allow for sufficient structure and breaking
>>up of source into separate files.

	This is sort of the argument used to justify why Pascal can be used
for serious work. Standard Pascal is nearly useless, because it doesn't provide
for handy things like separate compilation (the UNIT construct)), among other
thinks. It's only until Pascal is extended all to hell that it can be used 
for anything.

	And so it is with BASIC. To use the Mac Toolbox from BASIC, you
need special keywords (as in MS-BASIC)). This is even worse, because the
language implementor is forced to add what really should be subroutine
calls (which BASIC has no cleean mechanism for anyway) at the compiler
level.

	(I am a Pascal programmer, by the way)

>>allows non-programmers to solve simple problems, Basic is a good
>>choice of language for _real_ programmers interested in creating
>>a small to mid-size application of near-commercial quality.  And
>>it doesn't require any study of Inside Mac.

	Pascal allows programmers to solve simple problems as well. Or 
C. Or Fortran. Or APL. Or SNOBOL. It simply a question of how thoroughly
you're willing to abstract your data (as previously) described. The
more thoroughly a language allows you to exercise your data abstractions,
the more useful it is for solving the simple problems.

	I'd really hate to try and rewrite the 20,000 lines of Pascal code
in my current project in BASIC. 


		--Rich

Rich Siegel
THINK Technologies

dorourke@polyslo.UUCP (06/02/88)

In article <4685@husc6.harvard.edu> singer@endor.UUCP (Rich Siegel) writes:
>	Macintosh Pascal is not an alternative. Because there's no real runtime

   There is a runtime enviroment so that you don't have to distribute source
code.  Although I agree LSP is better and you should get that instead.

-- 
David M. O'Rourke

Disclaimer: I don't represent the school.  All opinions are mine!