oak
ozan s. yigit
amateurishly implemented, drooling "extension" [aka "scripting"] languages.
james gosling's oak. oak is a part of webrunner, an extensible web browser.
it is a simple, object oriented, distributed, interpreted, robust, secure,
architecture-neutral, portable, high-performance, multithreaded, [fully
buzzword-compliant :)] dynamic language that happens to look like
another popular language, but without pointers.
for an overview of webrunner and oak, and a complete oak language
description, see ftp://infosphere.com/pub/papers.tar.Z
oz
--
humpty-dumpty was pushed. | electric: o...@nexus.yorku.ca
- anonymous | or o...@sni.ca [416] 449 9449
Henry Baker
yigit) wrote:
> finally, something that may kill the tiring cacaphony of poorly designed,
> amateurishly implemented, drooling "extension" [aka "scripting"] languages.
> james gosling's oak. oak is a part of webrunner, an extensible web browser.
> it is a simple, object oriented, distributed, interpreted, robust, secure,
> architecture-neutral, portable, high-performance, multithreaded, [fully
> buzzword-compliant :)] dynamic language that happens to look like
> another popular language, but without pointers.
>
> for an overview of webrunner and oak, and a complete oak language
> description, see ftp://infosphere.com/pub/papers.tar.Z
This paper is no longer there, or is not accessible.
Brian Hanson
>
>for an overview of webrunner and oak, and a complete oak language
>description, see ftp://infosphere.com/pub/papers.tar.Z
I found only inetkit.exe, README, and the directory wr in the directory
pub - no papers.tar.Z.
Is there another source?
Brian Hanson
b...@cray.com
--
----
-- Brian Hanson
-- b...@cray.com
ozan s. yigit
for an overview of webrunner and oak, and a complete oak language
description, see ftp://infosphere.com/pub/papers.tar.Z
grumble. things moved, appearently because of a release.
see http://infosphere.com/webrunner for pointers to a home page
that includes papers, faq etc.
for more info, you may also send mail to webr...@sun.com.
Marc Wachowitz
[...]
> for an overview of webrunner and oak, and a complete oak language
> description, see ftp://infosphere.com/pub/papers.tar.Z
The language has been renamed to "Java", and the info server changed to
http://webrunner.neato.org/; the language specification is available by
anonymous ftp from webrunner.neato.org in the /docs directory.
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Larry W. Virden
I was just on <URL:ftp://infosphere.com/> and did not find a pub/papers.tar.Z,
but I did find one at <URL:ftp://webrunner.neato.org/docs/papers.tar.Z>
along with some other files relating to webrunner.
--
:s Larry W. Virden INET: larry....@cas.org
:s <URL:http://www-bprc.mps.ohio-state.edu/cgi-bin/hpp/lvirden_sig.html>
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.
ozan s. yigit
[a simple, object oriented, distributed, interpreted, robust, secure,
architecture neutral, portable, high-performance, multithreaded, dynamic
language] formerly known as oak, now named java, please note:
the papers on the java (formerly oak) language have been moved to
ftp://webrunner.neato.org/pub/papers.tar.Z
oz
---
ps: sorry i did not know this change at the time i posted the previous
pointer.
ozan s. yigit
[a simple, object oriented, distributed, interpreted, robust, secure,
architecture neutral, portable, high-performance, multithreaded, dynamic
language] formerly known as oak, now named java, please note:
the papers on the java (formerly oak) language have been moved to
ftp://webrunner.neato.org/docs/papers.tar.Z
----
oz
---
ps: sorry i did not know this change at the time i posted the previous
pointer.
---
README from webrunner.neato.org/docs
In this directory you will find various documents pertaining to
WebRunner and the Java programming language. the name of the
language was recently changed to Java from OAK and not all the
documents have been changed to reflect the new name.
26161 Feb 14 09:52 JavaOverview.ps.gz
25088 Feb 14 09:52 WebRunnerOverview.ps.gz
97535 Feb 13 19:24 implementing-native-methods.ps.Z
87026 Feb 14 09:52 javaspec.ps.gz
197781 Feb 14 09:52 papers.tar.Z
We are preparing a wider internet release of our software.
Watch this space or http://webrunner.neato.org/ for upcoming
announcements.
Henry Baker
> for those interested in webrunner, and its superior extension language
> [a simple, object oriented, distributed, interpreted, robust, secure,
> architecture neutral, portable, high-performance, multithreaded, dynamic
> language] formerly known as oak, now named java, please note:
>
> the papers on the java (formerly oak) language have been moved to
> ftp://webrunner.neato.org/pub/papers.tar.Z
When using anonymous ftp, I can see the papers there, but get a
'permission denied' message.
ozan s. yigit
Please somebody tell me I didn't waste my time just because somebody
wanted publicity. Please somebody tell me that there really is Lisp
in there someplace, or that the scheme newsgroup was included because
of thread drift or some other legitimate reason. [etc etc...]
i posted the article. it has nothing to do with publicity. i am not
involved in the project in any way, i do not have anything to gain from it
except in terms of knowledge. it was posted here along with comp.lang.misc
because someone gave an interesting list of characteristics for a modern
systems language. since schemers are often interested in other programming
languages and language design in general, it seemed like a useful pointer.
the languge is not lisp, nor c/c++ although it looks like c/c++. it is a
well-thought-out and well implemented language that i thought we can
learn something from.
my apologies to all those who have wasted their time looking at
a non-scheme language because of my pointer.
oz
Cameron Laird
>[a simple, object oriented, distributed, interpreted, robust, secure,
>architecture neutral, portable, high-performance, multithreaded, dynamic
>language] formerly known as oak, now named java, please note:
>
>the papers on the java (formerly oak) language have been moved to
>ftp://webrunner.neato.org/docs/papers.tar.Z
.
.
First reactions:
A. Not-good things about Java(TM):
1. ftp://webrunner.neato.org/docs/JavaOverview.ps.gz
explains why "a simple, object oriented, distributed,
... language" is a good thing, but not why Java is
going to be better for us than Perl5, or Python or
Scheme or ML or Taligent or ... In article
<OZ.95Feb...@nexus.yorku.ca>, Mr. yigit expresses
his weariness at "the tiring cacaphony of poorly
designed, amateurishly implemented, drooling 'exten-
sion' [aka 'scripting'] languages", but I truly
don't think we know enough yet about Java to be
confident of its superiority over all the alter-
natives. In fact, it's almost spooky that James
Gosling, who apparently has primary responsi-
bility for Java, has chosen to present so much
of Java in terms of a comparison with C++; surely
he knows that "today's standard practice" (page
1 of the "... Overview") encompasses more than
just C++.
2. It's vaporware. Not even alpha versions are avail-
able yet.
3. It's different. I don't mean syntactically, or
even semantically, but pragmatically. I have the
feeling that doing system calls, or making regular
expression substitutions, or employing an associ-
ative array, or linking in some C-coded modules,
is going to be a lot more tedious than in Tcl,
gawk, ...
4. There are flaws in the documentation. They are
small, and inconsequential (inconsistent use of
commas and hyphens, missing words as from "You
don't have to method invocation error"), but we
all know how important details are in our pro-
fession.
B. Good things about Java(TM):
1. It *is* a "simple, ... language", and the "...
Overview" does explain what that means.
2. The authors seem committed to distributing
their creation via the Net.
3. It's different. Maybe I'll have to work up my
own regular expression parser, but "Java has a
very extensive library of routines for easily
coping with TCP/IP protocols like HTTP and FTP.
Java ... can open ... via URLs with the same
ease that programmers are used to accessing
a local file system." 'Sounds good to me.
4. There are strengths in the documentation. It's
written by (anonymous; grr) folks who take
documentation seriously, and the prose ranges
from business-like (in the best sense) to
graceful.
"... Overview" describes a start in "small reliable portable
distributed real-time embedded systems", but the profile of
Java in
Morin, Richard
1995 "Oak and WebRunner", SunExpert Magazine,
volume 6, number 2, pages 30-31 (Febru-
ary 1995)
emphasizes software engineering and "agent" mentality-- "...
you can build all sorts of nifty distributed applications.
... [Java] allows code to be dynamically linked into a run-
ning application in a manner that is independent of the
CPU architecture of the system it is running on, and pro-
viding strong guarantees about the security of the system
..." That's certainly not incompatible with "small ...
embedded systems", but it's different from the way I'm used
to thinking about them. I suspect that Java will compete
with OSs--Taligent, Taos, Oberon, QNX, Telescript, AO/S--as
much as with languages--C++, Python, TCL, Forth, J, ...
Questions:
1. What are Sun's plans for Java? It's Sun that funds
Goslin's team.
1. Do Goslin et al. play volleyball matches against
Osterhout's team, or has California culture moved on
to other expressive forms?
2. Is the OS/language classification superannuated? Will
there be a better way to think about development/delivery
environments, a different set of key concepts?
3. How does Java perform? I bet it's plenty adequate (heck,
Tcl and /bin/sh do great work for us all, and we know
how slow they can be), but I want to feel it for myself.
4. What's in the library? The *... Language Spec ...* of
1 February 1995 looks promising, but I hunger for
details.
5. Is there any hope that Java will benefit from the
inspired leadership that Wall, Osterhout, van Rossum,
Meyer, ... have given Perl, Tcl, Python, Eiffel, ...?
We all know that those experiments have succeeded, not
(only) because the languages were correctly defined,
but because they inspired hordes of evangelical con-
verts, who helped implement good compilers/interpreters,
patiently build up the comp.lang.* infrastructure, and
passed around lots and lots of working code.
6. What happened to Dylan, anyway? Is there some lesson
there on how to stall out a project?
7. How well does Java scale, or promote teamwork? I *think*
the answer is, "quite well", but I haven't been able to
concentrate on the *... Spec ...* thoughtfully enough yet
to decide for myself.
8. Why is Mr. yigit so convinced that Java is a good thing,
and that that's a contrast with the usual c.l.m traffic?
9. What *are* Sun's plans, anyway?
I've narrowed follow-ups.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@Neosoft.com +1 713 267 7966
cla...@litwin.com +1 713 996 8546
Cameron Laird
k p c <k...@ptolemy.arc.nasa.gov> wrote:
.
.
.
>It must be thread drift:
>
>I thought that surely since the pointer was posted to
>comp.lang.scheme, the language would be a dialect of Lisp. I'm
.
.
.
>with Dylan. I guess I have to wait until somebody explicitly says
>that a language is a dialect of Lisp before I can really believe it is
>worth the effort to investigate it! :-)
This *is* getting confusing. Java is definitely C++-like;
maybe someone along the way confused it with GROW, which
"uses a variant of Scheme as its extension language". GROW
is designed to be "a portable, multi-tasking 'virtual OS'
with built-in support for communications and GUI building.
. . . GROW is designed to be implemented on a wide range of
computer systems. . . . GROW offers built-in support for
HTTP, HTML and other WWW standards." These quotes, and
everything else I know about GROW, are from
Morin, Richard
1995 "Grow, Little GROW Worm ...",
SunExpert, volume 6, number
1, pages 30-32 (January 1995)
The downside to GROW for you is that it "is still in the
planning stages, and there is no guarntee that it will
ever come to fruition."
Chris Warth
Cameron Laird <cla...@Starbase.NeoSoft.COM> wrote:
> .
> .
> .
>First reactions:
>A. Not-good things about Java(TM):
First, thanks for the long and thoughful posting. You raise a lot
of good points and I'd like to respond to the few that I can.
> 2. It's vaporware. Not even alpha versions are avail-
> able yet.
James or a bunch of others can recount the history of Java much
better than I can (that is a real story in itself), but the
language is certainly not vaporware. In fact I have been using
Java it since 1991, although it was called OAK then. The language
has gone through a lot of changes, and the focus has changed over
the years, but it is stable enough now that Arthur Van Hoff was
able to rewrite the Java compiler in Java.
The only proof that it is not vapor will be a public release of the
software, which we are madly trying to get out the door. Big
companies are very conservative, and Sun hasn't done anything like
this in a long time. It's not like a university, or even a small
company, where if you want to post something you just do it. The
political hurdles at a big company can be much more daunting than
the technical hurdles. TCL hasn't had quite the same set of
issues to deal with because it was public long before John came to
work for Sun.
I think we have passed the political hurdles at this point and we
are just working on technical issues. We want to make sure we don't
give the wrong impression on our first time out the gate.
> 4. There are flaws in the documentation. They are
You're right. We'll get this fixed.
>B. Good things about Java(TM):
> 4. There are strengths in the documentation. It's
> written by (anonymous; grr) folks who take
Again this is a big company thing, but it's also a personal
thing. Each person has a different idea of what looks
professional. Also I think big companies prefer to present a unified,
anonymous front. We made it a point to sign most of our code,
something unusual for Sun.
I know it sounds feeble now, but soon we will be able to debate
the strengths and weaknesses of Java while looking at the code. I
look forward to that.
-csw
Harley Davis
In article <1995Mar1.0...@ptolemy-ethernet.arc.nasa.gov> k p c <k...@ptolemy.arc.nasa.gov> writes:
The same thing happened for me with es. And it threatened to
happen with Dylan. I guess I have to wait until somebody
explicitly says that a language is a dialect of Lisp before I can
really believe it is worth the effort to investigate it! :-)
Check out <URL:http://riwww.osf.org:8001/www/waiba/index.html> and
follow the links to Ariadne. Ariadne is a web browser being designed
by OSF which is implemented in Talk, a Lisp dialect. You can get more
information about Talk from Ilog's web server at
<URL:http://www.ilog.com/>. To repeat, *Talk is a Lisp dialect!* :^)
-- Harley Davis
--
------------------------------------------------------------------------------
Harley Davis net: da...@ilog.fr
ILOG S.A. tel: +33 1 46 63 66 66
2 Avenue Galliéni, BP 85 fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France url: http://www.ilog.com/
Ilog Talk information: in...@ilog.com
k p c
> > for those interested in webrunner, and its superior extension language
> When using anonymous ftp, I can see the papers there, but get a
> 'permission denied' message.
I was able to retrieve the papers, uncompress them, untar them, find a
copy of ps2ascii, and ps2ascii them, but I was disappointed.
It must be thread drift:
I thought that surely since the pointer was posted to
comp.lang.scheme, the language would be a dialect of Lisp. I'm
interested in Lisp web software and versions of Lisp that can be used
for everyday tasks. I thought perhaps it would be worth the effort
for me to find out about this language.
It had a "nifty" recommendation from an implementer of Guile. It
sounded almost like it had something to do with Oaklisp.
But the language has, as far as I can tell, no relation to Lisp. It
appears to be a dialect of C+/- (:-)). The word lisp appears just
once.
Benjamin McLemore
info? All pointers appreciated. A quick scan of the article in the
bookstore was interesting, but no pointers jumped out...
-------------------------------------------------
> Morin, Richard
> 1995 "Grow, Little GROW Worm ...",
> SunExpert, volume 6, number
> 1, pages 30-32 (January 1995)
------------------------------------------------------------------
Benjamin McLemore Synapse Group, Ltd. General Partner
Infomart-Suite 5001 <b...@synapse.onramp.net>
1950 Stemmons Freeway 214/746.3732 voice
Dallas, TX 75207 214/746.3742 fax
------------------------------------------------------------------
Jonathan Payne
How does today's practices encompass more than just C++?
Anyway, it's James Gosling, with a "g" at the end, for future
reference. To answer your query, If perl5 is anything like the
incredibly useful, but otherwise a complete disaster of a language,
perl4, then the answer is, Java is a real language, with familiar
and consistent characteristics, with real performance, real
encapsulation, and real data types. Java is better than scheme
because for some reason the world just isn't up for LISP like
languages, something which continues to amaze me (although not upset
me as much as it used to with languages like Java around). I don't
know anything about Python or ML, and I thought Taligent was an
operating system. But since most people in the world seem to be
programming in C and C++, Java's advantage over most new languages
is that it feels very similar to C and C++ without a lot of the
baggage that makes both those languages a pain in the butt to use.
Java is not, in my opinion, an extension or scripting language,
although it may be possible to convince me I am wrong. It's a
general purpose implementation language, powerful enough to write
a compiler for itself in itself, and flexible and dynamic enough
for that process to be an enjoyable experience.
> 2. It's vaporware. Not even alpha versions are avail-
> able yet.
It's not vaporware, as you will find out soon. But I don't blame
you for thinking so.
> 3. It's different. I don't mean syntactically, or
> even semantically, but pragmatically. I have the
> feeling that doing system calls, or making regular
> expression substitutions, or employing an associ-
> ative array, or linking in some C-coded modules,
> is going to be a lot more tedious than in Tcl,
> gawk, ...
Actually, linking in C-code modules and providing nice java class
interfaces to those modules is quite easy to do. If somebody wants
to write a regular expression package in Java, then that's now part
of the "java library", just like there is RE support in the C library
(I think it's there). System calls are not portable, so you don't
want to do those, anyway. Associative arrays are like hashtables,
right? Well hashtables are in the Java library.
> Questions:
> 1. What are Sun's plans for Java? It's Sun that funds
> Goslin's team.
> 1. Do Goslin et al. play volleyball matches against
> Osterhout's team, or has California culture moved on
> to other expressive forms?
Ousterhout is working on tcl, and Gosling et al are working on
Java. One is an extension language, explicitely designed to be
really simple, to be embedded in other applications as a way to
extend those applications in an extremely dynamic manner. There
is a price to be paid for that, however, and part of that price is
performance. With java, you don't really hit the brick wall of
performance that you run into with many other applications. Most
applications don't need 100 mips of cpu to get their job done well.
There are usually a couple of places in the application which need
raw on-the-metal performance, but for the remaining 95% of the
application, a fast interpreter for a real language, is all you
need.
> 2. Is the OS/language classification superannuated? Will
> there be a better way to think about development/delivery
> environments, a different set of key concepts?
What does superannuated mean?
> 3. How does Java perform? I bet it's plenty adequate (heck,
> Tcl and /bin/sh do great work for us all, and we know
> how slow they can be), but I want to feel it for myself.
Java applications feel about 10 times slower than C applications.
No that's not quite right. Raw performance parts of C applications
are about 10 times faster than raw performance parts of Java
applications. In general Java applications feel pretty good. But
with the native code generator generating code for a few key aspects
of your system, applications will feel the same as C apps.
In my opinion and in my experience.
> 4. What's in the library? The *... Language Spec ...* of
> 1 February 1995 looks promising, but I hunger for
> details.
It's growing every day...
> 5. Is there any hope that Java will benefit from the
> inspired leadership that Wall, Osterhout, van Rossum,
> Meyer, ... have given Perl, Tcl, Python, Eiffel, ...?
> We all know that those experiments have succeeded, not
> (only) because the languages were correctly defined,
> but because they inspired hordes of evangelical con-
> verts, who helped implement good compilers/interpreters,
> patiently build up the comp.lang.* infrastructure, and
> passed around lots and lots of working code.
Gawd, it's amazing what you can make successful these days ... :-)
> 6. What happened to Dylan, anyway? Is there some lesson
> there on how to stall out a project?
Dylan was lisp, and the world can't accept all those parentheses?
I guess they gave it more of a C like syntax later (if I am
completely wrong about this, please don't flame me), but it was
too late? I am not sure. Or there was no compelling reason to
switch from more familiar C and C++ languages.
> 7. How well does Java scale, or promote teamwork? I *think*
> the answer is, "quite well", but I haven't been able to
> concentrate on the *... Spec ...* thoughtfully enough yet
> to decide for myself.
So far so good.
> 8. Why is Mr. yigit so convinced that Java is a good thing,
> and that that's a contrast with the usual c.l.m traffic?
Who is Mr. Yigit, and can somebody please send me the article he
seems to have sent to comp.lang.misc?
> 9. What *are* Sun's plans, anyway?
One never knows ...
Jonathan Payne (a former Sun employee suffering major withdrawal
symptoms from Java ...)
Cameron Laird
in email, but I want to make a few points in public. In article
<3J41Le$g...@nkosi.well.com>, Chris Warth <c...@well.sf.ca.us> wrote:
>In article <3j2udp$c...@Starbase.NeoSoft.COM>,
>Cameron Laird <cla...@Starbase.NeoSoft.COM> wrote:
>> .
>> .
>> .
>> able yet.
>
>James or a bunch of others can recount the history of Java much
>better than I can (that is a real story in itself), but the
>language is certainly not vaporware. In fact I have been using
available--but only to some people, not to the public
at large, yet.
This highlights a few software engineering issues that
interest me:
1. "the history of Java" is a story I'd like to see
told. I think we've collectively learned some
valuable lessons from the stories of genesis of
Unix, FORTH, COBOL, Apple, C++, ..., and I look
forward to the engineering or managerial princi-
ples operative in Java's history.
2. Sun has apparently made some commitment to
distributing Java binaries publicly. This is,
of course, a Good Thing, one that I applaud,
and it makes me feel particularly churlish
for writing "vaporware" without qualification.
3. Does Sun intend to pass around source for the
compiler and libraries? I'm sure that one of
the reasons Perl and Tcl and Python have come
so far is because of the enthusiasm of their
promoters for having folks look at the source
for their implementations. What's the benefit?
a. It gives comfort to those writing Serious
Applications. Maybe we don't have a
Technical Support telephone number at
which we can scream, but, if something
is flawed, we can in principle go in
and fix it ourselves.
b. It's the only way to handle porting.
Most Tcl heavyweights express more-or-
less profound uninterest in VMS, but
my current employer would have essenti-
ally zero tolerance for Tcl if I couldn't
supply VMS binaries. I can, because
there are a few other people in similar
niches, and, with everyone poring over
sources, it's natural to share the results
and even for John Ousterhout to incorporate
them in the master development sources.
c. It's good to read sources. I shan't
argue that that's particularly a benefit
to the language.
d. Review is Important. With thousands of
people around the world looking over
Perl source, Larry Wall hears about
errors and ideas for improvements FAR
faster than if he were having to work
it all out on his own.
Question: how much does this affect
functionality? I know review is effica-
cious at flushing out errors, I know
Messrs. Stroustrup and van Rossum and the
others who carry out their work in public
are open to suggestions, but how much
does this affect "higher-order" results?
I'll explain: Perl 5 has come a long way
from the first release of Perl. Larry
Wall has always had a consistent (consis-
tent in a Perl sense) vision of what Perl
should be, and that's valuable, but he
also has been influenced by criticisms
and suggestions of users. Are there any
specific cases in which his openness
about implementation--that is, that Perl
users were looking at source for the
interpreter--has inspired critics to make
suggestions about functionality or design
that he has incorporated?
A different way to say some of the same:
software engineers think in terms of models
such as
requirements [functionality] -> design -> implementation
With VisualBasic(TM), say, you have to
pay to read the syntax definition. Are
Perlians more creative at coming up with
suggestions for requirements because
they can freely look at the implementa-
tion? I think the answer is yes, and
that's why I believe Java will be
healthier if Sun releases a copy of the
compiler (written in Java, of course), but
I'm curious to learn whether we can docu-
ment this concretely.
.
.
.
>> 4. There are strengths in the documentation. It's
>> written by (anonymous; grr) folks who take
>
>Again this is a big company thing, but it's also a personal
>thing. Each person has a different idea of what looks
>professional. Also I think big companies prefer to present a unified,
Again, I was elliptic. Different people do differ on
good professional style in this regard. My bias is
toward individual signatures. However, I insist Java
documentation should have author references that at
least specify "The Java documentation team, Sun Micro-
systems", or the auto-replier at c...@Sun.COM, or
something comparable. As it stands, "Java: an Over-
view" has zero indication of authorship or date, and
I believe that's simply a mistake.
>anonymous front. We made it a point to sign most of our code,
>something unusual for Sun.
Congratulations! I think it'll be a benefit to the
project, and look forward to learning the "life-cycle"
consequences.
.
.
Tom Lord
It had a "nifty" recommendation from an implementer of Guile. It
sounded almost like it had something to do with Oaklisp.
I said "nifty" so you must mean me. But i'm not the implementer of
Guile -- only a few pieces of it. Most of the implementation comes
from Aubrey Jaffer and from a host of volunteers. I am, however,
becoming one of the chief patch-appliers of Guile ;-).
-t
Lenny Gray
Virtual Machine Spec". Where would one get that?
- Lenny Gray -
Cameron Laird
Jonathan Payne <jpa...@starwave.com> wrote:
.
.
.
>Actually, linking in C-code modules and providing nice java class
>interfaces to those modules is quite easy to do. If somebody wants
>to write a regular expression package in Java, then that's now part
>of the "java library", just like there is RE support in the C library
>(I think it's there). System calls are not portable, so you don't
>want to do those, anyway. Associative arrays are like hashtables,
"System calls are not portable, so you don't want
reaction to that; I suspect that it's somehow key
to understanding the appeal of Tcl, Perl, ... One
of my principal concentrations for two decades has
been portability, and I know darned well that I
don't want to do system calls, but I also want to
put answers in the hands of my customers now, rather
than tomorrow, and I end up doing system call-like
operations all the time. Is there some alternative
I'm missing? Can you amplify your comment on this
point, please?
>right? Well hashtables are in the Java library.
.
.
Cameron Laird
.
.
.
>> bility for Java, has chosen to present so much
>> of Java in terms of a comparison with C++; surely
>> he knows that "today's standard practice" (page
>> 1 of the "... Overview") encompasses more than
>> just C++.
>
>How does today's practices encompass more than just C++?
answer: see the advocacy wars in comp.*, including
the current one on the hazards of C++ right here in
comp.lang.misc. Examples: in comparison to Modula
or Eiffel or Ada 95 or ..., C++'s module system is
fragile; it's a nuisance that C++ classes aren't
first-class objects; and, as the Java documenters
and many, many others have explained, C++ memory
management simply isn't modern.
.
.
Richard Harter
Cameron Laird <cla...@Starbase.NeoSoft.COM> wrote:
>In article <3j85va$i...@orion.starwave.com>,
>Jonathan Payne <jpa...@starwave.com> wrote:
>"System calls are not portable, so you don't want
>to do those, anyway." Someone help me explain my
>reaction to that; I suspect that it's somehow key
>to understanding the appeal of Tcl, Perl, ... One
>of my principal concentrations for two decades has
>been portability, and I know darned well that I
>don't want to do system calls, but I also want to
>put answers in the hands of my customers now, rather
>than tomorrow, and I end up doing system call-like
>operations all the time. Is there some alternative
>I'm missing? Can you amplify your comment on this
>point, please?
This points to one of the real advantages of "scripting languages"
aka "command line interpreters". A good scripting language eliminates
most of the need for system calls because the functionality of the
common system calls is built into the language.
--
There are features that should not be used. | Richard Harter, SMDS Inc.
There are concepts that should not be exploited.| Phone: 508-369-7398
There are problems that should not be solved. | SMDS Inc. PO Box 555
There are programs that should not be written. | Concord MA 01742
Lenny Gray
Lenny Gray (lenn...@netcom.com) wrote:
: On page 5 of the "Java Language Spec", there is a reference to the
: "Java Virtual Machine Spec". Where would one get that?
------------------------- -------------------------
: - Lenny Gray -
ozan s. yigit
: On page 5 of the "Java Language Spec", there is a reference to the
: "Java Virtual Machine Spec". Where would one get that?
ftp to webrunner.neato.org and look under docs. it is vmspec.tar.Z.
if you would like more information, mail to webr...@sun.com, and
also check webrunner.neato.org regularly.
hope this helps.
oz
Larry Wall
: This points to one of the real advantages of "scripting languages"
: aka "command line interpreters". A good scripting language eliminates
: most of the need for system calls because the functionality of the
: common system calls is built into the language.
I heartily agree with your choice of the word "most". 95% of the time
you don't want the system calls. But at least 5% of the time you're
programming the 5% if your program that urgently needs the lower level
calls.
Easy things should be easy, and difficult things should be possible.
(I didn't say that first, but I wish I had.)
Larry Wall
lw...@netlabs.com
Richard Harter
And it should be simple to do things that you do frequently...
The thought occurs to me that "system calls" has two different meanings
in this context. There are calls to system, i.e. the invocation of
programs via calls to system, and calls into the system, i.e. calls to
the OS API.
Colas Nahaboo
<k...@ptolemy.arc.nasa.gov> writes:
|> I thought that surely since the pointer was posted to
|> comp.lang.scheme, the language would be a dialect of Lisp. I'm
|> interested in Lisp web software
a free scheme with good web extensions is OScheme, available by ftp at:
koala.inria.fr:/pub/OScheme
I think that scheme-48 has also lots of WWW extensions
--
Colas Nahaboo, Koala, BULL @ INRIA Sophia, http://www.inria.fr/koala/colas
Chris Patti
In article <3k9eb3$h...@sophia.inria.fr> co...@aye.inria.fr (Colas Nahaboo) writes:
Colas> In article
Colas> <1995Mar1.0...@ptolemy-ethernet.arc.nasa.gov>, k p
Colas> c <k...@ptolemy.arc.nasa.gov> writes: |> I thought that
Colas> surely since the pointer was posted to |> comp.lang.scheme,
Colas> the language would be a dialect of Lisp. I'm |> interested
Colas> in Lisp web software
Colas> a free scheme with good web extensions is OScheme,
Colas> available by ftp at: koala.inria.fr:/pub/OScheme
Colas> I think that scheme-48 has also lots of WWW extensions
Colas> -- Colas Nahaboo, Koala, BULL @ INRIA Sophia,
Colas> http://www.inria.fr/koala/colas
Scheme48 per se has almost none.
Scsh, however, which is based on top of Scheme48, has extensive HTML and HTTP
support either already there or in embryonic stages and not yet released.
-Chris
--
=- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =- =-
= Chris Patti Site Administrator ICAD, Inc. =
= chr...@icad.com "If it broke, I'm responsible :)" (617) 349-3644 x265 =
-= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -= -=