[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: PIERCE@AT-MAIL-SERVER.VITRO.COM, INFO-MCL@CAMBRIDGE.APPLE.COM
- Subject: Re: Dylan
- From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,BDV)
- Date: 29 May 92 22:33 GMT
- Cc: DYLAN-COMMENTS@CAMBRIDGE.APPLE.COM
Whilst I do not yet have the Dylan documentation, putting US and UK press
releases together reveals a bit more about one likely (alright, announced)
application of Dylan - US announcements about the Newton PDAs have stated that
Dylan is to be used in them; UK announcements have stated that the Newton PDAs
will be powered by the Advanced RISC Machines, Ltd. (ARM) RISC processor,
claimed to give "Newton products the equivalent power of leading desktop
computers, yet consumes less battery power than a small flashlight".
That invalidates one of your key assumptions, that they "may have relatively
slow hardware". I would also take issue with your concept of applications
development, as whatever else PDAs may be used for, I doubt if they will run
the sort of apps which do on our current desktop systems.
Terminology and naming are always difficult. As someone who has come to MCL
relatively recently, I applaud a break from Common Lisp's current terms, not
because I dislike them, but because they are idiosyncratic and steeped in the
history of Lisp. If Dylan is to be used by those who have never used Lisp
before, and in consumer market products, then I think a cleaning up of naming
is vital, or it will appear as just another Lisp variant instead of a language
in its own right. The only good reason for sticking with Lisp terms would be
if Dylan developers were to be largely ex-Lisp programmers, which would seem
unlikely given that most Lisp is currently in 'academic' use, and not too much
in consumer products.
>The third limitation which dynamic languages such as Dylan need to address for
>delivery is the ability to integrate pre-existing code developed in other
>languages. This is especially important so that Dylan applications can take
>full advantage of optimized user interface code.
Well, how many products with optimised user interface code would you see being
ported to a PDA, which by description already has a pen-based interface and
quite clearly is a very different product (with a different interface) from the
desktop Macs which we use now? Surely, such a new product for new markets is
not going to require porting large amounts of old code across (fancy using
WordPerfect or Excel on a PDA? No, writing and calculating apps are surely
going to be totally different - at least it might stop Microsoft using their
awful p-code system for once :-)).
>In particular, I'd like to see a Dylan based MACAPP implementation.
... and I'd like to see Dylan MacApp even run a basic editing app on a PDA.
MacApp is a massive class library designed to provide ready and very flexible
access to a very substantial (thousands of pages of docs) human interface on
desktop and laptop machines with 4 megs of memory upwards (commonly now 8 megs
of memory). Surely, a PDA is going to have rather less memory, a totally
different human interface, and trying to port MacApp to it would be grossly
inefficient, if not pointless. On the other hand, the much smaller and simpler
approach in the current implementation of MCL (suitably adapted to the PDA's
abilities and System) is much more likely to be practical. For example, MacApp
permits rich complex and large dialogs, which I would suspect would be far
simpler and sleeker on a PDA; MacApp lacks any intrinsic networking capability,
which the PDAs have as an essential - what about support for distributed
groupware on a number of PDAs?
>A portable Dylan implementation could easily be coded entirely in Common Lisp.
Whilst I would not volunteer to do it, I am already forming a queue right
behind you for the first beta :-).