[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is it too hard to program for the Apple?
- Subject: Re: Is it too hard to program for the Apple?
- From: DaveSchmenk <dschmenk@gmail.com>
- Date: Thu, 18 Feb 2010 16:46:28 -0800 (PST)
- Complaints-to: groups-abuse@google.com
- Injection-info: b1g2000prc.googlegroups.com; posting-host=71.139.164.176; posting-account=BEcBJwoAAADnWuRoZDUhMSNKNGG-dTV7
- Newsgroups: comp.sys.apple2
- Organization: http://groups.google.com
- References: <dog_cow-1266518551@macgui.com>
- User-agent: G2/1.0
- Xref: g2news1.google.com comp.sys.apple2:14092
On Feb 18, 10:42 am, dog_...@macgui.com (D Finnigan) wrote:
> I think (I've probably been doing too much of that lately) that maybe one of
> the reasons why there aren't loads of "exciting" projects coming out for the
> Apple is that it's too hard to program on the Apple, especially compared to
> programming on today's Mac or PC.
>
> Let's take a look at some reasons why I have this suspicion:
>
> a.) The Apple's screen is small, and there's no mouse.
>
> This naturally makes program editing difficult when today, we're used to all
> sorts of fancy editors on big screens, with macros, easy cursor control and
> all sorts of extras. I don't even use the fanciest line editor for Mac, I
> just use TextEdit which doesn't even number lines, and I still find it
> easier to enter new code and make corrections than on the Apple. And of
> course, it's easy to pull up old files and save new ones. We've got huge,
> fast hard drives.
>
> Note to self: I need to take a look at what editors are out there for the
> IIgs.
>
> b.) Aside from Applesoft, there's no easily-accessible high-level language
>
> Applesoft is easy to use. I've written tons of silly games and trivial
> experiments in Applesoft. But I haven't written anything substantial or
> non-trivial. There's also the speed problem.
>
> Now, of course there is Pascal and K&R C for the Apple (and ANSI C if you've
> got a IIGS and ORCA), which I'm still exploring, but just off the bat I've
> found them to be slow, and the lack of documentation isn't helping (but I
> might not be looking hard enough for docs). There's still the editor
> problem.
>
> c.) It's hard to get data in and out of the Apple.
>
> This is a big problem too, especially if someone is using a cross-compiler
> to avoid problems a and b as listed above. There's still no comprehensive
> solution which works for everyone. So if you program entirely on the Apple,
> you need to figure out how to get it onto a disk or out a serial wire. No
> matter which way the data is going, you need to get a machine with serial
> ports, or an Ethernet card for the Apple, use an emulator to make disk
> images, or get an old Mac which can write ProDOS floppy disks.... To me,
> there must be a better solution out there, but what we've got now isn't the
> worst, either.
>
> Am I right in any of this? Anyone else agree/disagree or have more to say?
Hmm. Interesting points to argue, but 30 years has brought new
perspective on what a development platform consists of. An 8 bit
microcomputer with 64K/128K of memory isn't a lot for a full blown
development platform. Not that there aren't any available, but those
that are had significant constraints to contend with. There just
wasn't anything else available at the time unless you worked for a
corporation or school with a minicomputer or mainframe. Even Woz
cross-assembled the Apple II monitor ROM.
Now, for my own development, I treat the Apple II as an embedded
target and use tools running on PCs to edit/compile/test. Finally I
send the image to real hardware by way of a IIGS running appletalk
connected to my Linux server and sneaker net to the rest of my Apple
IIs. ADTPro is my other choice when I don't feel like walking
upstairs to my IIGS. I say this because I have written a 1st person
raycaster game and am finishing up a Java VM for the Apple II.
Neither of which could be developed solely on the Apple II without a
ridiculous amount of effort. I spend way too much time writing code
for a 30 year old computer, but even that is limited and I need to get
the most productivity out of the time I do have. I treat my projects
more as research into what can really be done on an 8 bit, 1MHz, 64K
computer.
One of the reasons I think so many geeks still hold a special place in
their heart for the Apple II is the way it interactively allowed one
to tinker and work out small programming tasks. A different concept
from the way things were done, or are done now. If you were to start
a project for the Apple II today, look at the issues you brought up.
Instead of a unix-alike OS, what about an interactive development
environment that can work effectively in a 40 or 80 column screen.
Look at some of the computer languages that have been popular in the
past 20 years. I took Java on as an experiment in just how much could
fit in 64K. Honestly, Java is a little too much to self-host. I keep
looking at simplified Python as a good match to a small interpreted
editor/execution environment. If your environment is meant solely for
the Apple II, there won't be as much need to get data to and from the
Apple in the first place, except to share it or back it up.
Dave...
P.S. Take a look at Instant Pascal if you can find any on-line copies
of it's manuals. An interesting environment with much promise, but
crippled at birth to avoid competing with other tools.