NewtonScript = Esperanto??
Satan - The Evil 1
It seems that NewtonScript is a major factor contributing
to the sluggish uptake (and near-death) of the Newton.
NewtonScript seems to be like Esperanto; a custom
language with some nice features but not really
that popular because everyone wants to speak
something else. A small (decreasing) elite claim
it is fantastic.
C/C++ is more like English; a bit of a hodge-podge
but spoken by a huge percentage of the world's
population.
Why the Newton should have had, from the start,
a cross-platform (yes guys, Windows *is* popular),
standard C/C++ development environment;
- There is a massive C/C++ skillbase in the developer
community that could have been leveredged to develop
Newton apps.
- There is a huge amount of C/C++ source code as well
as algorithms and libraries implemented in this
language.
- C++ is *exciting* to many people who would have
been very interested in seeing their work implemented
on a portable device such as a Newton. Even better
would be a simple C/C++ development environment on
the Newt itself so that people could play and
experiment with their C++ code while on the road,
at uni, etc...
- One acronym: GNU
Hell, even Scheme or Lisp would have been better than
NewtonScript. The amount of source code in these languages
is immense.
It is sad to see a promising and visionary device
such as the Newton brought down by such a poor decision
by the language "purists". Language elitism does not
benefit anyone but a few with their own barrow to push.
- Peter.
Alan Drogin
In article <5taq2b$7ie$1...@cdn-news.telecom.com.au>,
sa...@vus002.telecom.com.au (Satan - The Evil 1) wrote:
> It seems that NewtonScript is a major factor contributing
> to the sluggish uptake (and near-death) of the Newton.
>
> NewtonScript seems to be like Esperanto; a custom
> language with some nice features but not really
> that popular because everyone wants to speak
> something else. A small (decreasing) elite claim
> it is fantastic.
>
> C/C++ is more like English; a bit of a hodge-podge
> but spoken by a huge percentage of the world's
> population.
Yes, C++ is a hodge-podge alright (^;. If I had my druthers, Pascal would
rule the world, but where were you 20 years ago? You sound like my old
boss talking about COBOL when C started to pick up steam.
No, Newtonscript may not win the popularity contest, but thinking C++ is
like English and will rule the world forever is plain silly. Let's face
it, COBOL was just verbose overkill for a single user-PC, that's why there
was plenty of room for improved languages in the 80s. And can you
remember when OOPS was "the thing!" Nearing the turn of the century and
already Java is showing up C++ for it's 80s insistence on verbose handles
and memory management.
Anyway, as PCs have done to COBOL, handhelds may do to C++. The one
reason why Newtonscript is far better for handhelds than most languages
can be summed up in one word "protos". Just see the problems being
discussed about porting JAVA, and what was supposed to be meant for
handhelds. And clean portability has been the Holy Grail of programming
for 40 years. I'd sooner buy the Brooklyn Bridge.
And besides, there is already, albeit limited, C++ compiler for Newtons
anyway. And then there's NSBasic and Newt, too.
I'm sorry, what do you expect when you come to this group and call us all
language "purists"? I know about 8 or so languages. Newtonscript is just
better and gets the job done quicker and nicely. I expect better
languages will become more popular in the near future and I'll be praising
and using them, too. If you think C++ has "won" and you won't have
another 8 or so languages to learn before you type your last line of code,
you might have a harder time looking for work sooner than you think. In
fact, if you want to talk popularity, aren't there more lines of BASIC
code in the world?
--
Sincerely,
Alan Drogin
Above e-mail is phoney (die spammers!) Use drogin "at-sign" panix.com
pURL for Digital Objectives - Newton Bookmark Manager for the digerati
http://members.aol.com/DigObj/pURL.html
NYC
Rainer Joswig
In article <5taq2b$7ie$1...@cdn-news.telecom.com.au>,
sa...@vus002.telecom.com.au (Satan - The Evil 1) wrote:
> It seems that NewtonScript is a major factor contributing
> to the sluggish uptake (and near-death) of the Newton.
This is a major false decision by Apple! There are even more:
- the use of an object-oriented OS. Nowbody needs that.
- the use of a pen and not a keyboard. Everybody else uses a keyboard.
- another GUI. Everybody else uses Windows.
- lack of a file system. This soup thing is crazy.
- running on the ARM processor. Everybody else is using Pentiums.
- No support for Emacs. Does not even run GCC.
- No shell/command line. Familiar commands like "ls" and "tar"
don't work.
- No Corba support. They claim it has objects. But it
even doesn't support CORBA.
- Netscape Navigator could have run on it from day one. But it didn't.
> It is sad to see a promising and visionary device
> such as the Newton brought down by such a poor decision
> by the language "purists". Language elitism does not
> benefit anyone but a few with their own barrow to push.
There are many more poor decisions by the Newton group.
Rainer Joswig
In article <5taq2b$7ie$1...@cdn-news.telecom.com.au>,
sa...@vus002.telecom.com.au (Satan - The Evil 1) wrote:
> It seems that NewtonScript is a major factor contributing
> to the sluggish uptake (and near-death) of the Newton.
It seems that NewtonScript is a reason for
the elegance of the Software on the Newton.
Bloat is not known. Apps are small and
are tightly integrated into the OS.
Seems like Apple/Newton Inc. is way beyond the competion.
> C/C++ is more like English; a bit of a hodge-podge
> but spoken by a huge percentage of the world's
> population.
Languages which are almost useless for application development
on small devices. C++ will be forgotten soon.
> - There is a massive C/C++ skillbase in the developer
> community that could have been leveredged to develop
> Newton apps.
They won't be Newton apps. Just another incarnation
of Windows apps for the Desktop.
> - There is a huge amount of C/C++ source code as well
> as algorithms and libraries implemented in this
> language.
Most of them are not designed for a portable device
with an integrated object-oriented OS.
> - C++ is *exciting* to many people who would have
> been very interested in seeing their work implemented
> on a portable device such as a Newton. Even better
> would be a simple C/C++ development environment on
> the Newt itself so that people could play and
> experiment with their C++ code while on the road,
> at uni, etc...
Better get a Windows CE device. It might fit your needs.
Otherwise this is old thinking. I would say from
the stone age where people were carving algorithms
in C++ files.
> - One acronym: GNU
Bloat.
> Hell, even Scheme or Lisp would have been better than
> NewtonScript. The amount of source code in these languages
> is immense.
Immense and useless for the Newton.
> It is sad to see a promising and visionary device
> such as the Newton brought down by such a poor decision
> by the language "purists". Language elitism does not
> benefit anyone but a few with their own barrow to push.
The Newton simply stands out by its elegant design.
You want wo add features that may change its
face to be something completely different.
I would say, you haven't got the Newton nature. What is it?
Tell me. Quick.
Satan - The Evil 1
Alan Drogin (dev-...@panix.com) wrote:
: In article <5taq2b$7ie$1...@cdn-news.telecom.com.au>,
[...]
:
: I'm sorry, what do you expect when you come to this group and call us all
: language "purists"? I know about 8 or so languages. Newtonscript is just
: better and gets the job done quicker and nicely. I expect better
: languages will become more popular in the near future and I'll be praising
: and using them, too. If you think C++ has "won" and you won't have
: another 8 or so languages to learn before you type your last line of code,
: you might have a harder time looking for work sooner than you think. In
: fact, if you want to talk popularity, aren't there more lines of BASIC
: code in the world?
You are entirely missing the point. Take a look at the following post;
+>In order to get my feet wet with the C++ WindowsCE cross dev kit, I
+>ported XLisp v1.6 over to the WindowsCE/HPC platform. The port, in
+>source code, and precompiled SH3/MIPS binary form is available at
+>
+> http://tigar.ucdmc.ucdavis.edu/pub/PocketLisp
+>
+>It is based on XLisp v1.6, a free Lisp Interpreter. Versions are
+>available on tigar for SH3, MIPS, and Windows95/NT to facilitate
+>development on all platforms (the source can be recompiled under
+>Linux, or just about anywhere else as well, if you should fancy it..).
+>
+>There are no licensing restrictions, except those from David Betz,
+>the orignal author of XLisp for Unix.
Now *how long* has it taken to get a lisp compiler on the
Newton (is there one)??!?? There is so much stuff out there
written in C/C++ and so many developers eager to work with
this language that supporting it is a definate advantage.
I am not so arrogant as to say that C++ is the world's greatest
language (as you are saying about NewtonScript). I'm am just
saying that the Newton would be far more popular and widely
used if you could create applications for it in C/C++ rather
than NewtonScript. And despite your prophecies of doom, I am
quite certain C/C++ will be around for a long, long time
to come.
It is this arrogant, elitist attitude that almost killed
the Newton, and I'm not just talking about NewtonScript;
many of us PC/Windows owners had to suffer through years
of poor Newt-PC connectivity. Developers had to use a
Mac or nothing and it was left to third-party developers
to supply non-Mac development tools.
Get off your high-horse. Maybe you think to Newt is just
a yuppy toy for you "country-club" boys, but I believe it
could have been (and could still be) so much more!
Regards,
- Peter.
: --
David Arnold
sa...@vus002.telecom.com.au (Satan - The Evil 1) writes:
> You are entirely missing the point.
i'd suggest that *you* are missing the point.
NewtonScript was designed specifically to cater for the limitations of
handheld platforms:
- the use of bytecode, rather than ARM machine code, saves
significant amounts of storage as anyone who has converted their
apps to native code will tell you.
- the use of proto inheritance means that a feature-rich (you could
even say bloated) application takes up 300k storage and less than
that in heap space.
C++ (or C) programmers expect to have megabytes of storage and heap
available. it's all very well to say that "so much stuff" could be
ported to the newton with a C/C++ compiler, but it is simply not true:
there is not enough RAM to support anything more than trivial C/C++
applications developed for other platforms.
repeat after me: a newton is not a small PC!
> I am not so arrogant as to say that C++ is the world's greatest
> language (as you are saying about NewtonScript).
no, we're saying that NewtonScript is the most appropriate given the
limitations of the hardware ...
> I'm am just saying that the Newton would be far more popular and
> widely used if you could create applications for it in C/C++ rather
> than NewtonScript.
*if* you *could* ... but that would require completely different
hardware. which is not "the newton".
> Get off your high-horse. Maybe you think to Newt is just
> a yuppy toy for you "country-club" boys, but I believe it
> could have been (and could still be) so much more!
so make it so. stop your ill-informed abuse of people who know far
more about the topic than you. investigate the real issues and set
about taking advantage of the strengths that the newton has to offer.
d
Serg Koren
In article <joswig-ya0231800...@news.lavielle.com>,
jos...@lavielle.com (Rainer Joswig) wrote:
In article <5taq2b$7ie$1...@cdn-news.telecom.com.au>,
sa...@vus002.telecom.com.au (Satan - The Evil 1) wrote:
> C/C++ is more like English; a bit of a hodge-podge
> but spoken by a huge percentage of the world's
> population.
Uhhuh...and if everyone jumps off the cliff I'm sure you will too lol. ;-)
And who says English is an efficient language...far from it. It's just the
easy way out because we all know it.
> - There is a massive C/C++ skillbase in the developer
> community that could have been leveredged to develop
> Newton apps.
Maybe so, but why propogate bad programming and coding? And you gain back
a LOT of productivity by using NS...c (it's not "C" people) and C++ are NOT
very productive languages to the programmer...they require a LOT of up
front work and a LOT of care just to manage memory leaks and all the 'c'
programmers who learned C++ tended to carry forward a lot of bad habits.
And C++ is far from object-oriented. It's McDonald's for the programming
masses...pretty much the least common denominator if you don't count 'c'
itself.
They won't be Newton apps. Just another incarnation
of Windows apps for the Desktop.
> - There is a huge amount of C/C++ source code as well
> as algorithms and libraries implemented in this
> language.
Most of it badly written...evolved (or worse PORTED) from original 'c' code.
C++ is ok as a language....but it's inherited a TON of badly written code
that people would just LOVE to port onto another platform. How many
companies have a zero tolerance QC department when it comes to their C++
development...just because you're a big corporation using/creating tons of
C++ code doesn't mean you produce good code; quite the contrary.
The one thing that hasn't been mentioned (as far as I know) is that the NTK
is a MUCH MUCH MUCH more stable product than any C++ compiler I've used
(and I've used a lot of them.) I've never had the NTK crash out from under
me or crash the Mac. I've had the Newton reset and crash due to what I was
doing in the NTK; but the environment itself is a wonder of stability.
> - C++ is *exciting* to many people who would have
> been very interested in seeing their work implemented
> on a portable device such as a Newton. Even better
> would be a simple C/C++ development environment on
> the Newt itself so that people could play and
> experiment with their C++ code while on the road,
> at uni, etc...
Ah yes the greed factor.... They want to do it quickly instead of doing it
right. You can develop NewtonScript on the road ON your Newton using
either Steve Weyer's NDE (Newt) or my own VisualNewt (which is in VERY
early beta).
Also, when was the last time you ran the Small-C compiler on any
incarnation of pc? did you like it? Where you really impressed with the
power of the programs you were able to create? That's pretty much the
quality of C++ you could expect. Not very powerful, minimally useful but
mildly amusing.
Actually, FWIW a Micro-COBOL implementation on the Newton would be a more
logical choice *IF* you wanted a more standard language. It's structured;
has database support, requires a minimal footprint, AND you can develop
meaningful apps...AND libraries...of course you'd have to bind it to the
proto system somehow.
My personal choice would be something on the order of Mops (a
structured/object-oriented FORTH). But that's another can of worms.
> - One acronym: GNU
Buggy...as most programs written by committee tend to be ;-)
> Hell, even Scheme or Lisp would have been better than
> NewtonScript. The amount of source code in these languages
> is immense.
So what's keeping you or anyone from writing a compiler/environment for ANY
of these languages...basically it comes down to the fact you (maybe not
personally but globally you) don't want to learn NewtonScript...you're
taking the easy way out. You *can* write other compilers and stuff for the
Newton....I'm sure Newton, Inc. will even give you internals and help if
you are serious. But do it using the tools at hand...NewtonScript and the
C++ tools.
> It is sad to see a promising and visionary device
> such as the Newton brought down by such a poor decision
> by the language "purists". Language elitism does not
> benefit anyone but a few with their own barrow to push.
Ah you've already made up your mind I see..."Newton brought down.."
It hasn't been brought down. Who says it has? Actually the return rate on
WindowsCE machines is about 50%. So much for a supposedly state-of-the-art
mass appeal GUI and C++ environment. And it has little to do with
hardware, and more to do with the user experience.
When it comes right down to it people like to take the easy way out.
They'd rather stay with something they know and get warm fuzzies from (C++)
rather than learn something better. It has nothing to do with language
purism. Rather it a decision based on pragmatic reasons and for the
productivity it provides. It's like arguing...wow I'd never buy a
Ferrari...that's a snob's car...I'd rather stay with my nice Taurus.
I'd rather drive the Ferrari ;-)
S
--
====================================================================
Se...@VisualNewt.com
http://www.VisualNewt.com/
--------------------------------------------------------------------
"...suddenly the ship ran aground on a deserted island, and they all
turned purple...yes they were marooned!" -- ISIRTA
--------------------------------------------------------------------
Newt'sPaper(tm) the premiere Newton(R) MessagePad(tm) NNTP News Reader
http://www.VisualNewt.com/NewtsPaper.html
Newt'sWeather(tm) the Newton(R) MessagePad(tm) NIE Weather Solution
http://www.VisualNewt.com/NewtsWeather.html
VisualNewt(tm) a visual development environment for the MessagePad(tm)
http://www.VisualNewt.com/VisualNewt.html
Newt'sBrot(tm) the Newton(R) MessagePad(tm) Mandelbrot fractal explorer
http://www.VisualNewt.com/NewtsBrot.html
====================================================================
Unknown
While I think NewtonScript is great (it could have been Self?), I have
to agree that the use of a proprietary language hurts the Newton's
support for existing product.
The Squeak group has been talking about porting Smalltalk to PDA's for
a while. The Windows CE port is already up and running (creating the
original DynaPad? (only with keyboard :-( )) (yes, I can use Lisp,
too) but the Newton port will be a (probably long) while.
It might have been considerably harder to create a C++ environment
that provides the advantages NewtonScript has in producing small
packages - but I think it would have been worth the result. (Don't
mind me, I still think C++ is the greatest language so far - I just
don't program in it.)
Pete M. Wilson
Starlight Computer Wizardry http://www3.gamewood.net/scw
Newton & Windows 95 Software mailto:s...@gamewood.net
Don Vollum
In article <5taq2b$7ie$1...@cdn-news.telecom.com.au>,
sa...@vus002.telecom.com.au (Satan - The Evil 1) wrote:
> It seems that NewtonScript is a major factor contributing
> to the sluggish uptake (and near-death) of the Newton.
Actually, I'd have to completely disagree here. There are hundreds (maybe
thousands) of Newton apps. I'd wouldn't be surprised if there are more
Newton apps than apps for all other non-DOS handhelds combined.
I really don't think you can attribute Newton's market standing to lack of
applications (and hence to NewtonScript). If anything, Newton's survival
is due to the huge number of apps, and the productivity allowed by
NewtonScript!
Don
Paul Fernhout
I agree that NewtonScript is a stumbling block to widespread Newton
acceptance.
As someone who has been working on the Squeak->Newton port on and off
for the past nine months, I can say: what a pain to do complex low level
things on the Newton for a Newton programming newbee! It took months to
get the C++ tools from Apple (now they're free!), and even now the tools
are difficult to work with (e.g. no debugger for the eMate or MP2000);
tools are all cross-compilers without local emulators (like co-pilot for
the pilot); documentation is hard to access. As another post points out,
someone could port Lisp to Win CE in a short while. The Squeak
Smalltalk port to windows CE took very little time.
Now there are a few things that affect my judgement: one is that I use a
Quadra 630 on the mac side with only a 17" monitor - and so the online
documentation is especially slow to use and needs to be scrolled. Also,
I have never sat down and spent a month learning NewtonScript; I've
always had only a few hours here or there (at most, a couple of days in
a row). So, I have never had a chance to learn NewtonScript well or in
a relaxed way. Also, since my goal is to offer an alternative to
NewtonScript and C++ on the Newton, my attitude is "the less time spent
on them the better", and I don't feel any time invested in those tools
will offer any return (other than to maintain Smalltalk on the Newton).
Yet, there is no question that the Newton is still the superior hardware
(limited DRAM aside) over current Win CE. I much prefer the form factor
and pen interface of the MP2000 over chicklet keys. That is why I am
working with it. Also, if I was going to develop a typical Newton app,
I would probably be very happy with NewtonScript and would use it for
its small footprint, protos, and easy of interoperability with other
NewtonScript apps.
The biggest problem I have with NewtonScript (and Newt, which is a great
system otherwise) is that in order to do programming on the Newton, you
need to carry around the NewtonScript documentation (or have it
memorized)! Right now, that comes as thousands of pages of online
documentation. You can't learn to program the Newton using Newt as a
stand alone tool (without referring to printed or mac-bound
documentation). Steve Weyer has been adressing this with online
documentation books, so things are getting better.
Squeak has all its documentation built in - in a potential total memory
footprint of under a megabyte. And even with Newt, there is not the
equivalent of Smalltalk's integrated debugger.
In my opinion, the innovations of the Newton - hand writing recognition,
soups, protos could have been served by a small library of C++ code,
perhaps layer over a multitasking Forth kernel (or even QNX). Even now,
if the Newton is to be used in vertical markets, an ability to
completely take over the hardware with an C++ application would be
desireable.
Don't get me wrong - I detest C and C++ as ugly and complex and fraught
with pitfalls. But for low level OS development, they are still good;
even Squeak is implemented in C. For fast code using minimum resources
they are still good. For porting existing code, they are still good.
Yet, I do see the point to a safe language like NewtonScript -
especially if you are developing on a PDA that also has valuable
information you don't want to lose.
The issue I see is that Lisp, Forth, and Smalltalk have been around for
a very long time and are all capable of incremental development and OO
development (with extensions for Lisp and Forth). Their existence makes
NewtonScript an unneeded language. (With QNX around for years, the
Newton OS was probably unneeded too.) That doesn't mean NewtonScript
isn't a good language, or useful, or neat. That just means it is yet
another language; yet another fragementation of development efforts; yet
another thing to learn. It addresses primarily one issue: limited DRAM
and slow to change FLASH RAM, by using protos. While I think it likely
that limited DRAM issue could have been approached differently when the
Newton was first released years ago (use Forth or put in more memory),
it certainly is a non-issue now (where the MP2000 could easily have 4MB
DRAM for very little cost). In that regard, NewtonScript is obsolete,
since limited memory is no longer an issue, and even if it was, there
are other standard alternatives (C++ or Forth). Certainly the success
of the Pilot shows that you can have small programs written in C++ that
run on a PDA platform.
What the language arguement may miss is that there is more to
development than a language. Forth, Lisp, and Smalltalk all can have
integrated debuggers on the target machine. They all have developers
with years of experience and existing code libraries.
NewtonScript could have had a chance to become an important language if
it was made available on Windows, Mac, and UNIX as a stand alone
cross-platform development environment with integerated debugger (and
ideallly, web browser support). But it is probably too late for all
that.
In my opinion, to make the Newton even more succesful, I would
recommend:
* 4MB DRAM machines standard
* Forth, Lisp, Smalltalk, and Python availability for the Newton.
* An ability to compile to the metal with C++ with GUI classes (and
limited or no OS support).
* A Newton emulator for Mac and Windows, with a built in debugger.
I don't think these are going to happen anytime soon, which pretty much
makes NewtonScript the only game in town for the forseeable future.
Even if they were, NewtonScript will probably always be the most
efficient thing to program the Newton in because of the 8MB of ROM
functions that support it. Even Squeak Smalltalk on the Newton will only
run on an expanded eMate if and when I or someone else finishes it.
Hopefully after it runs there, some innovations might allow it to run on
the MP2000, but that will require yet more rework and may cause it to
run slowly (say by keeping an image on an SRAM card to make up for lack
of DRAM).
-Paul Fernhout
Kurtz-Fernhout Software
===========================================================
Developers of custom software and educational simulations
Download version 1.0 of our Garden Simulator for Windows from:
http://www.gardenwithinsight.com
Jason Kaczor
On Tue, 19 Aug 1997 14:35:47 GMT, (Pete M. Wilson) wrote:
>While I think NewtonScript is great (it could have been Self?), I have
>to agree that the use of a proprietary language hurts the Newton's
>support for existing product.
It's not that different form C++/Pascal. Frankly I can't see how it
can hurt to have NewtonScript now that the tools are free. I do agree
that having only NewtonScript available from only Apple/Steve Weyer
(thanks steve) was bad... But not that it's free...
ttyl
Jason
Alan Drogin
In article <5tbdjj$j0n$1...@cdn-news.telecom.com.au>,
sa...@vus002.telecom.com.au (Satan - The Evil 1) wrote:
> +>In order to get my feet wet with the C++ WindowsCE cross dev kit, I
> +>ported XLisp v1.6 over to the WindowsCE/HPC platform. The port, in
> +>source code, and precompiled SH3/MIPS binary form is available at
> +>
> +> http://tigar.ucdmc.ucdavis.edu/pub/PocketLisp
> +>
> +>It is based on XLisp v1.6, a free Lisp Interpreter. Versions are
> +>available on tigar for SH3, MIPS, and Windows95/NT to facilitate
> +>development on all platforms (the source can be recompiled under
> +>Linux, or just about anywhere else as well, if you should fancy it..).
> +>
> +>There are no licensing restrictions, except those from David Betz,
> +>the orignal author of XLisp for Unix.
And I'll be waiting for the explosion of useful WinCE commercial products
because of this wonderful LISP port...NOT!
> Now *how long* has it taken to get a lisp compiler on the
> Newton (is there one)??!?? There is so much stuff out there
> written in C/C++ and so many developers eager to work with
> this language that supporting it is a definate advantage.
> I am not so arrogant as to say that C++ is the world's greatest
> language (as you are saying about NewtonScript).
I did NOT say Newtonscript was the greatest language, I said it was better
than C++ for the handheld..
> I know about 8 or so languages. Newtonscript is just
> : better and gets the job done quicker and nicely. I expect better
> : languages will become more popular in the near future and I'll be praising
> : and using them, too.
> I'm am just
> saying that the Newton would be far more popular and widely
> used if you could create applications for it in C/C++ rather
> than NewtonScript.
It didn't happen, it'd be difficult to change that, lets move on. Your
argument is purely based on popularity, not on any knowledge of
Newtonscript, and surely not with any thought that perhaps there's room
for improvement in the future. What you don't see are programmers around
here saying, "oh I learned Newtonscript and it sucks". Sure in the ideal
world you could learn one language, port it anywhere, and just sit back
and let your code re-use itself forever.
> And despite your prophecies of doom, I am
> quite certain C/C++ will be around for a long, long time
> to come.
I have friends who still program in assembler for a living, so what? It's
you who have already prophecied the doom of the Newton. C++ will fade.
Computer languages are not like spoken languages, they're like
generations. And the next generation of schooled programmers will be
laughing at coding handles and memory management. Newtonscript will fade,
too, but it hasn't reached it's generational mark yet.
> many of us PC/Windows owners had to suffer through years
> of poor Newt-PC connectivity.
Ah, I agree, connectivity is poor, but that seems to be more based upon
the filing and data structure than on Newtonscript itself. I think this
is just one area that Apple Newton just didn't throw enough resources at
solving.
>Developers had to use a
> Mac or nothing and it was left to third-party developers
> to supply non-Mac development tools.
Point number 2. Yes, it was a shame WinNTK took so long to get out of
beta. Funny thing was, one of the reasons was the shaky PC serial
connectivitiy.
> Get off your high-horse. Maybe you think to Newt is just
> a yuppy toy for you "country-club" boys,
Quite the opposite. I used to be a desktop programmer for almost 20
years, but it was just getting too expensive to buy all the upgraded
manuals (MacApp alone takes up an entire bookshelf), debuggers, resource
managers, and keep track of these huge bloated application frameworks and
still remain a personal programmer (the PC world was beginning to look
like the Mainframe world I had left almost 20 years ago). When NTK came
out, it had one manual, and one developer toolkit. It was simple and
elegant. And now it's free. I think there's some other underlying angst
going on for you to use the term "yuppy toy". Did some young kid with a
cellular phone and not the faintest idea of what an opcode is just put you
out of job?
As I said, the C++ thing didn't happen for the Newton, too bad, now crack
open that Newtonscript ref manual and learn something new.
Brian Zawistowski
David Arnold <arn...@foxtail.dstc.edu.au> wrote in article
<o43eo6y...@foxtail.dstc.edu.au>...
> sa...@vus002.telecom.com.au (Satan - The Evil 1) writes:
>
> > You are entirely missing the point.
>
> i'd suggest that *you* are missing the point.
>
> NewtonScript was designed specifically to cater for the limitations of
> handheld platforms:
>
I think that your assertion that C or C++ is not suited to the handheld
platform is disputable. An obvious case is the PalmPilot. Here we have a
handheld unit that not only allows applications to be devloped in C, but
has an OO operating system written in C. Somehow this unit manages to have
roughly the same memory footprint as a Newton Furthermore, this unit has
been commended for its speed despite its "bloated" operating system. I
think that if we compared the amount of third-party software, shareware,
freeware available for the Newton at the same age as the PalmPilot, it
would be obvious that the PalmPilot has benefitted from its development
environment. I am not saying that I don't like NewtonScript, however I'm
quite sure that its complexity and the lack of low cost development tools
(up until recently) has discouraged more than on would-be developer.
Brian Z.
John King
: - the use of bytecode, rather than ARM machine code, saves
: significant amounts of storage as anyone who has converted their
: apps to native code will tell you.
: - the use of proto inheritance means that a feature-rich (you could
: even say bloated) application takes up 300k storage and less than
: that in heap space.
As a lay user I would say NewtonScript on the Newton has some "wonderful"
consequences -- like mixing a pinch of NS in with NSbasic or QFPro. I love
the idea of a poweful scripting language next door, just in case. However,
producing compact programs on Newton sized devices is, in some real ways,
an old idea. Newton sized devices of tomorrow will have 16megs or more of
memory, more speed etc. The need for small code at the price of
performance is an idea which the development community needs to rethink. I
suppose for many really really small devices of tomorrow there will always
be the speed, power, & memory constraints of early Message Pads. But,
again, for the larger devices there's gonna be a lot of memory and speed
so we'd better know how to use it.
For example, a StrongArmed based Wince device is comming around the bend
soon. I believe, if I am right, it's going to be several times faster.
It's time to think fast first then compact. Features too -- need class
libraries from third parties etc.
How? Dunno. C++ or Java plus NS maybe. NS has to be there, of course. I
still believe Java isn't. Java will get assimilated by the Borgs from
Redmond anyway.
--
+-- Telephone HEADSETS - corded, cellular, wireless. ----------------------+
| Plantronics, Unex, ACS, GN Netcom, VXI, and more. Repairs too. |
| Commercial, small office home office. All nations, almost all phones. |
+-- Increase productivity, ease neck pain. (253) 845-4088 jo...@eskimo.com -+
Mark Watson
On 19 Aug 1997 00:40:43 GMT, sa...@vus002.telecom.com.au (Satan - The
Evil 1) wrote:
>NewtonScript seems to be like Esperanto; a custom
>language with some nice features but not really
>that popular because everyone wants to speak
>something else. A small (decreasing) elite claim
>it is fantastic.
I would suggest that Java would be a good substitute,
**IF** the core language does not suffer from too
much bloat: a case in point: new JFC classes should
(probably) not be part of the core API, and the
"Personal Java" api is still a little too fat.
Java with a really slimmed down "standard" class
library seems perfect for Newton-like devices.
(BTW, I bought a Newton when they first came out,
and I did not particularly care for the NewtonScript
language -- although it served a need at the time).
-- Mark
+ Mark Watson, author and Java consultant.
+ Java products: http://www.markwatson.com
+ Buy direct from the developer and save!!
Jim Bailey
On Tue, Aug 19, 1997 12:35 PM, Paul Fernhout <mailto:kfs...@netins.net>
wrote:
->Don't get me wrong - I detest C and C++ as ugly and complex and fraught
->with pitfalls. But for low level OS development, they are still good;
->even Squeak is implemented in C. For fast code using minimum resources
->they are still good. For porting existing code, they are still good.
->
->Yet, I do see the point to a safe language like NewtonScript -
->especially if you are developing on a PDA that also has valuable
->
->The issue I see is that Lisp, Forth, and Smalltalk have been around for
->a very long time and are all capable of incremental development and OO
->development (with extensions for Lisp and Forth). Their existence makes
->NewtonScript an unneeded language.
I'm afraid that I can't see much point to doing Lisp, Forth and Smalltalk
for the Newton as alternatives to NewtonScript (though I think there
already is a small Lisp interpreter.) Compared to the more popular
languages like Basic and C/C++ the sizes of their developer bases are are
all down in the noise. Forth seems to be effectively dead--It isn't even
used much in the embedded market anymore as far as I can tell. Smalltalk
has a small but strong following but it doesn't have much chance anymore
with the onslaught of Java and Visual Basic. I think even the Smalltalk
stronghold at IBM is moving to Java now.
NewtonScript is a highly appropriate language and runtime environment for
its intended target. Until something can reasonably replace it this
argument is not very interesting. Eventually, the cost of hardware may
make it a moot point, but that time is not here yet. The argument that
NewtonScript is preventing a rush of applications is debatable based on the
large number of Newton applications available. The whole argument is a
strawman, created to start a flame-war, just ignore it.
--
Jim Bailey <mailto:j...@shore.net>
<http://www.tiac.net/users/jdb>
Andrew Maier
In article <dev-null-190...@drogin.dialup.access.net>,
Alan Drogin <dev-...@panix.com> wrote:
>you might have a harder time looking for work sooner than you think. In
>fact, if you want to talk popularity, aren't there more lines of BASIC
>code in the world?
>
Don't forget FORTRAN 77. No matter how limited the language is it
is still the most common language in science.
Andrew
--
Andrew Maier Tel: +41-22-76-77907
CERN/PPE FAX: +41-22-782-3084
CH-1211 Geneva 23, Switzerland e-mail: Andrew...@cern.ch
God is real, unless declared integer
Jason Dufair
> C/C++ is more like English; a bit of a hodge-podge
> but spoken by a huge percentage of the world's
> population.
"Huge?" This may be true if the boundaries of your world include only
the U.S. & Europe.
Este mundo tiene muchas lenguas (hablar y computadoras) y es necessario
por cambio.
--
Jason Dufair
fu...@n.o.s.p.a.m.iquest.net (remove n.o.s.p.a.m. to reply)
http://www.iquest.net/~funne/
PGP key @ http://www.iquest.net/~funne/jdufair.asc or keyservers
Erik Naggum
* Don Vollum
| I really don't think you can attribute Newton's market standing to lack
| of applications (and hence to NewtonScript). If anything, Newton's
| survival is due to the huge number of apps, and the productivity allowed
| by NewtonScript!
but don't you see? if programmers are more productive, users are happier,
and there won't be much bitching and moaning about crappy software in the
trade rags, dimwits won't find things to "fix" and boost their ego with,
there won't be millions and millions of below-average programmers who write
junk software, and the Newton will die. if you want to succeed, use an
unproductive language that attracts stupid people, write buggy software
that gets lots of press (make sure to write it so badly that you open a
door for viruses in _each_ of your applications!), and get unhappy users
who crave the next version like you're pushing dope on them. make sure you
offer your customers a belief in a better _tomorrow_. don't give them any
good stuff today -- nobody believes in things they can _see_. you need to
create _illusions_ to get people to buy from you again and again, and you
just can't create illusions when people actually get what they dreamed of
right away. nono, leave them craving, and you got them by the balls.
actually, I hope that the Newton will show people that they don't _have_ to
be forever unhappy sufferers of Microcrud. I'm glad they chose a new
language for the Newton. it's the only way we can hope for progress.
(that's right, that's "a better _tomorrow_" all over again. see how
fundamental it is to inspire with the future?)
#\Erik
--
man who cooks while hacking eats food that has died twice.
David Arnold
"Brian Zawistowski" <bri...@ici.net> writes:
> > NewtonScript was designed specifically to cater for the limitations of
> > handheld platforms:
> I think that your assertion that C or C++ is not suited to the handheld
> platform is disputable.
i didn't say that C/C++ was unsuitable for handhelds.
i *did* say that NewtonScript was designed to address the limitations
of handhelds. that doesn't mean that C/C++ is unsuitable, just that
NewtonScript *is* suitable.
an assertion had been made that C/C++ was *more* suitable for the
Newton than NewtonScript. i don't believe that is so.
-- David Arnold ,=================================================
=================' +617 33654310 (voice)
CRC for Distributed Systems Technology +617 33654311 (fax)
University of Queensland dav...@pobox.com (email)
Australia <http://www.pobox.com/~davida> (web)
C++ compilers rarely optimize for the joy of programming - lwall
John Schettino
On 20 Aug 1997 09:41:38 +1000, David Arnold
<arn...@foxtail.dstc.edu.au> wrote:
>"Brian Zawistowski" <bri...@ici.net> writes:
>
>> > NewtonScript was designed specifically to cater for the limitations of
>> > handheld platforms:
>
>> I think that your assertion that C or C++ is not suited to the handheld
>> platform is disputable.
>
>i didn't say that C/C++ was unsuitable for handhelds.
>
>i *did* say that NewtonScript was designed to address the limitations
>of handhelds. that doesn't mean that C/C++ is unsuitable, just that
>NewtonScript *is* suitable.
>
>an assertion had been made that C/C++ was *more* suitable for the
>Newton than NewtonScript. i don't believe that is so.
As someone who's been doing NewtonScript, C, C++ and now C/C++ under
WinCE, I can tell you that NewtonScript is nicer by a long shot.
Faster during execution, no - nicer during design and implementation,
yes. Of course the poor debugging tools (still no source level
debugger) and lack of a desktop emulation environment in the NTK
somewhat negate that.
-=====
John Schettino
js...@biteme.gte.com
(you know not to use the biteme part, right?)
http://members.aol.com/pdcjohns
Unknown
"Brian Zawistowski" <bri...@ici.net> wrote:
>Furthermore, this unit has
>been commended for its speed despite its "bloated" operating system.
Speed it produces on a 68k processor, too!
(P.S. I love my MP2k - I don't have a Pilot.)
Rob Warnock
Rainer Joswig <jos...@lavielle.com> wrote:
+---------------
| - the use of a pen and not a keyboard. Everybody else uses a keyboard.
Gee, somebody ought to tell the USR\\\ 3Com "Pilot" developers (over 3000!)
and users (several million!). ;-} ;-} They seem to do o.k. without one.
+---------------
| - another GUI. Everybody else uses Windows.
+---------------
Ditto above.
+---------------
| - running on the ARM processor. Everybody else is using Pentiums.
+---------------
Pilot uses a 68k.
-Rob
-----
Rob Warnock, 7L-551 rp...@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673 [New area code!]
2011 N. Shoreline Blvd. FAX: 650-933-4392
Mountain View, CA 94043 PP-ASEL-IA
Jason Kaczor
On Wed, 20 Aug 1997 00:36:39 GMT, (Pete M. Wilson) wrote:
>I agree that these aren't things most people need to program - and
>NewtonScript is wonderful for most PDA programs. But I'm not convinced
>C++ couldn't have been just as wonderful (check out C++ Builder) and
>still provide a large code library of utilities (GNU Chess?).
I know how wonderful C++ Builder is, as I use Delphi which is where it
takes most of it's VCL from.
Actually you are correct, there is no reason the prototypes couldn't
still be in ROM will a modified C++ interface.
ttyl
Jason
Jason Kaczor
On Tue, 19 Aug 1997 13:04:44 -0400, dev-...@panix.com (Alan Drogin)
wrote:
>Point number 2. Yes, it was a shame WinNTK took so long to get out of
>beta. Funny thing was, one of the reasons was the shaky PC serial
>connectivitiy.
Only shaky because someone made the decision not to use standard
Windows serial drivers and write their own. That someone shall remain
nameless, but as an organization it does often fall into the "not
invented here" trap.
ttyl
Jason
Arnold Kim
> I think NewtonScript is a good example of the inefficiency of large
> companies. The development community is awash in languages. Why develop a
> new one from scratch when several suitable ones already exist? Well, when
> you have a large amount of resources its tempting to show the rest of the
> world how good you are by developing your own language.
I don't think that's the case. I just don't think Apple's used
Newtonscript to it's full advantage. I think Newton's original conception
was a bit more grand. They intended it to be used in appliances large and
small... much like WinCE and Java are aimed today.
An advantage was that it ran interpreted. Size over speed. Plus, you
could change processors as you needed, and wouldn't have to rewrite code.
Just port the OS/interpreter to the new processor, and "binaries" should
still work.
The biggest problem was follow-through. If we were all sitting here with
all our NewtonOS devices - like clone-handhelds with XYZ processors, and a
Desktop Newton device, Newton emulators, and wrist-watch Newtons - we
wouldn't be sitting around complaining about Newtonscript - we'd be saying
"Newtonscript is great".
arnold
Paul Fernhout
Walter Smith wrote:
>
> Paul Fernhout wrote:
> >The issue I see is that Lisp, Forth, and Smalltalk have been around
> >and OO development (with extensions for Lisp and Forth).
> >Their existence makes
> >NewtonScript an unneeded language. That doesn't mean NewtonScript
> >isn't a good language, or useful, or neat. That just means it is yet
> >another language; yet another fragementation of development efforts;
> >yet another thing to learn.
>
> and Smalltalk are all redundant in the same way that NewtonScript is.
> Which one of the four did you want to be the "needed" one that
> isn't "another thing to learn"?
What I meant was:
Lisp was first implemented in 1958. By the early 1980s it had a
fantastic development environment (Symbolics).
Forth was first implemented in 1969. By the early 1980s it had several
fantastic development environments (as far as small footprints).
Smalltalk was first implemented in 1972. By the early 1980s it had a
fantastic development environment (Smalltalk-80).
NewtonScript came way after all of these successes, and correct me if
I'm wrong, had its genesis around 1985, with the first major programming
efforts in it around 1990. To this day it does not have a built in
debugger (on the target machine) to match any of these other three
languages. It does not have commonly available code libraries to match
these languages. It does not have cross platform support to match these
languages.
Timewise, NewtonScript is the fourth language to be developed; way after
the others. While I enjoyed learning it and the notion of prototype
based programming, prototype based programming could have been
implemented as add-ons to Lisp, Forth, or Smalltalk with much less fuss
than creating yet another programming language. A pascal like syntax
could have been added as a front end to either of those languages as
well. Soups would be just add on libraries.
I think NewtonScript was a fantastic research project and a great
experiment, and well worth investing in by Apple for its own sake. I
believe in the general goal - having a universal OO VM to handle most
application development - and if Apple had followed through on that
goal, we might be using NewtonScript instead of Java in web browsers (a
situation I would much prefer). For whatever reason, NewtonScript has
not become that universal VM. That means there is a high intellectual
cost of entry to work with the Newton, and the value of knowing
NewtonScript is restricted to doing Newton development or reusing the
ideas elsewhere.
The NewtonScript system is incomplete compared to the other languages as
they existed in 1985. The debugging facilities and source code
management and browsing facilties of NewtonScript are not as well
developed now as those tools had ten years ago. For me, that is the
biggest failing of NewtonScript (and it has nothing to do with the
language itself - which is a really neat language). NewtonScript could
have had those features if Apple had made the investment (or otherwise
put it in the public domain like Python) - but Apple didn't, and so
NewtonScript is an orphan programming language - good only on one
platform. Even its creator has moved onto other things. :-)
However, NewtonScript is the biggest game in town for Newton Developers,
and the Newton hardware and APIs are so much better than WinCE for
typical PDA apps that it is worth learning and using if you want to make
useful PDA applications quickly. However, consider how many people also
develop for the Newton in NewtonBasic or one of the form building
programs, and you will see that there is still virtue in giving
developer access to low level tools. Those third part development
sysstems are slower than they have to be because of lack of easy to use
low level Newton programming tools.
Nonetheless, you can't buck the trends and existing standards and be
widely succesful unless you are several times better than the standard.
As far as dynamic programming languages go, NewtonScript is not several
times better than Smalltalk, Lisp, and Forth. That is why it is a
stumbling block for the Newton.
> It also has obvious counterexamples: C++, Visual Basic, PL/SQL, dBase,
> HyperTalk, Java, and JavaScript are languages that were developed after
> Lisp, Forth, and Smalltalk, but a lot of people learned them, despite the
> resulting fragmentation of their development efforts.
True. However, that doesn't mean there was a *real* need for any of
those languages either (which are much wheel reinventing - maybe with
one new idea thrown in). THta doesn't mean those people would not have
been better off learnign an older language; and that the language
designers wouldn't have been better off improving the existign
languages. Languages evolve, like species, for their own reasons (and
their authors reasons). The truth is, all of those languages you
mention were also unneccesary in a sense when you consider when they
were written. For example, why invent HyperTalk when you had Smalltalk?
Why not make HyperCard as a Smalltalk library? Why write C++ at Bell
Labs when people are now developing telephone switches using Smalltalk
because it is easier and more reliable and the code can be easily
patched when the switch is in use. I'm not saying their goals are
unneccesary - like retrieveing database record. Just the need to ivent
a whole language (and supporting debuggers, compilers, browsers, etc.)
to do it.
I'm not saying innovation is unneccesary - just that Lisp, Forth, and
Smalltalk, and C (and Pascal for that matter) were strong enough bases
on top of which to build all the features those other languages have.
The reasons that did not happen had more to do with intellectual
property issues and marketing (and in some very few cases efficiency)
than with the true need for any of those tools. Mind you - I'm not
saying for example that a SQL like syntax for record retrieval isn't
useful sometimes - just that it could have been thought of as an add on
somehow into those other languages. In general, I'd be for supporting
task specific languages, with these programming paridigms as just
optional definitions to load into an existing Smalltalk or Lisp or Forth
system. If you want NewtonScript, you just load the definition into your
general purpose VM system. And actually, that is the way the industry
is moving (look at IBM's universal VM initiative).
The difference is that Lisp, Forth, and Smalltalk are complete enough in
their own ways to support other languages relatively easily. Most of
the other languages you mention are not. That is why I think they are
better choices for long term survival - because they can easily mimic
the best features of the other langauges.
I am trying to argue that existing programming languages were and are
adequate for the types of tasks a Newton must perform (and in the case
of constrained memory - Forth is superior). Nonetheless, this Babel of
programming languages (thousands of langauges) does us no good in day to
day development; it just means developers have to keep relearning how to
do the same thing in different ways - and, often loose features they
come to love - like Java lost Smalltalk blocks. Sure, it is true that
fragmentation allows new ideas to evolve which is good - that is why
NewtonScript's development is a good thing for programming in general,
although maybe was a bad thing for the Newton.
Language design is certainly lots of fun, as is learning new languages
(if you're the kind of person who thinks that sort of stuff is fun).
I've worked on languages myself - my favorite is something similar to
William Kent's ROSE system. It's a great way to keep your mind sharp -
designing programming languages. And of course, I hoped for years I
might come up with the next great thing. Yet, I realize now, my efforts
would probably be best as just a library for Smalltalk or Lisp. For
example, it is very hard to improve on Smalltalk selectors with
arguement names for clarity. I think Squeak has the potential to become
the open VM of choice for people with a bent for language tinkering
(either that or Python).
>
> >As someone who has been working on the Squeak->Newton port on and off
> >for the past nine months, I can say: what a pain to do complex low level
> >things on the Newton for a Newton programming newbee!
>
> You are nowhere near the target market for Newton or NewtonScript.
> It was never intended to make it easy to do complex low-level things. > (What system makes it easy for a newbee to do such things, anyway?)
> If you took a step back, learned more about NewtonScript, and
> thought about applying it to its intended purpose,
> you might begin to appreciate certain unique advantages.
> Wanting to implement a language runtime gives you a warped viewpoint
> (I should know!).
You are correct of course. I have been programming for about eighteen
years in various different languages (so newbee refers only to the
Newton). The issue remains that unless you are doing small PDA apps,
NewtonScript is difficult to use. Why build in such limitations to a
hardware platform? Why not make it possible to put new languages on the
Newton? Certainly C++ (when though of as a better assembly language) is
a good all around choice for allowing people to do whatever they want on
a platform (in most cases).
True, I'd rather program a GUI in NewtonScript than bare C++. But, I'd
rather program a GUI on a Newton Emulator in MetroWorks C++ with a good
class library than do NewtonScript on a Mac/Newton using the existing
cross compiler.
It isn't the NewtonScript language. It is the cross platform, emulator,
debugging and browsing tools, and library issues that go with a new
language that pose the major hurdles. That is why NewtonScript is a
hurdle; writing GUIs in straight C++ for the Newton (with well written
API libraries) would have meant that developers would have had all those
other things that make development so much easier (even if C++ can be a
bear to work with).
>
> He also wrote:
> >It addresses primarily one issue: limited DRAM
> >and slow to change FLASH RAM, by using protos.
>
> Actually, that's just a useful side effect (at least the first is;
> I don't
know what the Flash RAM part means).
I meant that there is limited DRAM which can be modified as regular
memory (one byte at a time). FLASH RAM needs to be modified in 1K to
32K chunks (depending onthe exact chip). So, FLASH RAM is more
difficult to work with on a byte by byte basis, and so the Newton stores
rarely modified data in FLASH (like protos). NewtonScript supports this
sort of thing very well becuse when values in an object change from the
proto, only then are new slots created in DRAM. However, I would think
this issue coudl have been addressed by Smalltalk or Lisp or Forth,
although likely in a different way.
> I prefer to think that NewtonScript
> mainly addresses a different issue: that prototype-based languages are much
> better than class-based languages for user interface programming. See
> http://www.pobox.com/~wrs/OOPSLA95.pdf for more on that topic.
You may well be correct However, they still need debuggers, browsers,
and easy access to documentation (preferably on the machine being
developed for) if they are to be a big success. Developing a new
language is only a tiny part of the entire effort needed to make it
succeed.
A lot of this is 20/20 hindsight. Just like if I could have seen the
future in 1985 I would have invested $10,000 in Microsoft stock instead
of blowing it hanging around CMU for a year playign at language design.
When NewtonScript was developed the computer landscape was very
different and no one knew what would happen with various languages, or
exactly what Apple would do with it.
Rainer Joswig
> In my opinion, the innovations of the Newton - hand writing recognition,
> soups, protos could have been served by a small library of C++ code,
This library would build NewtonScript and the Newton OS.
> completely take over the hardware with an C++ application would be
> desireable.
It won't be a Newton.
> The issue I see is that Lisp, Forth, and Smalltalk have been around for
> a very long time and are all capable of incremental development and OO
> development (with extensions for Lisp and Forth). Their existence makes
> NewtonScript an unneeded language.
NewtonScript is Lisp. ;-)
> since limited memory is no longer an issue,
It still is. 64 MB in my PowerBook is barely enough.
> development than a language. Forth, Lisp, and Smalltalk all can have
> integrated debuggers on the target machine.
NewtonScript could have that, too. Still the Newton is currently not very
good as a development machine. It is not intended to be one.
A color A4 size Newton with a sexy *****graphical*****
programming environment usable with a pen will be the killer
application. Text-based systems as C++ are stone age compared
to that. Imagine, *drawing* some programs while being
in a train or while sitting at the beach. ;-)
> NewtonScript could have had a chance to become an important language if
> it was made available on Windows, Mac, and UNIX as a stand alone
> cross-platform development environment with integerated debugger (and
> ideallly, web browser support). But it is probably too late for all
> that.
I would not say no. Currently I would like to see the above mentioned
A4 Newton with Ethernet, etc. I'd like to get rid of Macs, PCs and
the rest.
> * Forth, Lisp, Smalltalk, and Python availability for the Newton.
Would add bloat. Let the Newton be the elegant design it currently is.
> * An ability to compile to the metal with C++ with GUI classes (and
> limited or no OS support).
Not more unsafe software on the Newton. Please, less.
Unknown
Paul Fernhout <kfs...@netins.net> wrote:
>Why write C++ at Bell
>Labs when people are now developing telephone switches using Smalltalk
>because it is easier and more reliable and the code can be easily
>patched when the switch is in use.
Well, C++ was designed specifically to meet certain performance
criteria - it actually is supposed to be Simula with the speed of C,
not Smalltalk.
Unknown
ACoupl...@compuserve.com (Jason Kaczor) wrote:
Well, I have been using NTK since it dropped to $150 (yes, I paid for
mine), so I don't have a problem with NewtonScript.
It's not that different from C++? Let's say I want to write Forth for
the Newton (a friend is trying out the PilotForth on his Pilot). In
C++, I'd be finished with stuff. In NewtonScript, I'm not sure how to
start. Our I want to port the Prolog system I used to work on (ages
ago). I moved it from Pascal to C - but NewtonScript is a different
story.
I agree that these aren't things most people need to program - and
NewtonScript is wonderful for most PDA programs. But I'm not convinced
C++ couldn't have been just as wonderful (check out C++ Builder) and
still provide a large code library of utilities (GNU Chess?).
Walter Smith
Paul Fernhout wrote:
>The issue I see is that Lisp, Forth, and Smalltalk have been around for
>a very long time and are all capable of incremental development and OO
>development (with extensions for Lisp and Forth). Their existence makes
>isn't a good language, or useful, or neat. That just means it is yet
>another language; yet another fragementation of development efforts; yet
>another thing to learn.
I don't understand this argument. It implies that Lisp, Forth, and Smalltalk
are all redundant in the same way that NewtonScript is. Which one of the
four did you want to be the "needed" one that isn't "another thing to
learn"?
It also has obvious counterexamples: C++, Visual Basic, PL/SQL, dBase,
HyperTalk, Java, and JavaScript are languages that were developed after
Lisp, Forth, and Smalltalk, but a lot of people learned them, despite the
resulting fragmentation of their development efforts.
>As someone who has been working on the Squeak->Newton port on and off
>for the past nine months, I can say: what a pain to do complex low level
>things on the Newton for a Newton programming newbee!
You are nowhere near the target market for Newton or NewtonScript. It was
never intended to make it easy to do complex low-level things. (What system
makes it easy for a newbee to do such things, anyway?) If you took a step
back, learned more about NewtonScript, and thought about applying it to its
intended purpose, you might begin to appreciate certain unique advantages.
Wanting to implement a language runtime gives you a warped viewpoint (I
should know!).
He also wrote:
>It addresses primarily one issue: limited DRAM
>and slow to change FLASH RAM, by using protos.
Actually, that's just a useful side effect (at least the first is; I don't
know what the Flash RAM part means). I prefer to think that NewtonScript
mainly addresses a different issue: that prototype-based languages are much
better than class-based languages for user interface programming. See
http://www.pobox.com/~wrs/OOPSLA95.pdf for more on that topic.
- W
--
Walter Smith w...@pobox.com http://www.pobox.com/~wrs
I am speaking for myself, not my employer.
Jim Cricket
I think NewtonScript is a good example of the inefficiency of large
companies. The development community is awash in languages. Why develop a
new one from scratch when several suitable ones already exist? Well, when
you have a large amount of resources its tempting to show the rest of the
world how good you are by developing your own language.
I doubt that Newton Inc would have chosen a new language for development if
they had run the Newtons development from beginning to end, simple because
their resources are relatively small.
Unknown
ACoupl...@compuserve.com (Jason Kaczor) wrote:
>On Wed, 20 Aug 1997 00:36:39 GMT, (Pete M. Wilson) wrote:
>
>>I agree that these aren't things most people need to program - and
>>NewtonScript is wonderful for most PDA programs. But I'm not convinced
>>C++ couldn't have been just as wonderful (check out C++ Builder) and
>>still provide a large code library of utilities (GNU Chess?).
>
>I know how wonderful C++ Builder is, as I use Delphi which is where it
>takes most of it's VCL from.
>
>Actually you are correct, there is no reason the prototypes couldn't
>still be in ROM will a modified C++ interface.
Actually, I use Delphi as well. While I like C++ better (much better)
than Pascal, I think C++Builder's reliance on the VCL makes it less of
a good C++ tool. Its use of pointers to objects, etc. is not good C++.
OTOH, maybe this makes Walter's point about class based versus
prototype languages. Some of the unfortunate design issues in
C++Builder and Delphi come about from needing to create a new
(single-instance) class for every form, etc.
Chris Dawson
Very good point.
-Chris Dawson