[9fans] Awk or Limbo ?

[9fans] Awk or Limbo ?

[William Staniewicz]

I have been following the discussion that has
been taking place but have to admit to not
knowing much about programming and the options
that are available.

What appears to be true is that C++ is not well
received here. That comes a bit of a surprise
because when I do wander through a bookstore in
the computer section C is there in large quantity.

Some people mention Limbo and AWK. Which is used
daily by the Plan9'rs?

		-Bill

Re: [9fans] Awk or Limbo ?

[Boyd Roberts]

> Some people mention Limbo and AWK. Which is used
> daily by the Plan9'rs?

depends on the job.

this was what was so stupid about the SRC C++/Modula 3
'one true language' debate/meeting.  taylor just psy-op'd
them into agreeing on modula 3.  i could barely contain
the hilarity of the situation.  the SRC labs meetings, as
a visitor, where always fun just to watch taylor in action.

Re: [9fans] Awk or Limbo ?

[Dan Cross]

In article <20010426231220.A2383@localhostnl.demon.nl> you write:
>I have been following the discussion that has
>been taking place but have to admit to not
>knowing much about programming and the options
>that are available.
>
>What appears to be true is that C++ is not well
>received here. That comes a bit of a surprise
>because when I do wander through a bookstore in
>the computer section C is there in large quantity.
>
>Some people mention Limbo and AWK. Which is used
>daily by the Plan9'rs?

Well, I use awk every day for a variety of reasons.  Others use Limbo
on a daily basis.  The thing about programming languages is that
they're like shoes; one pair is simply not enough for every occasion
(for instance, try skateboarding in wingtips; try getting a job on Wall
St wearing sneakers; try doing string processing in COBOL, and you'll
see what I mean).

The backlash against C++ shouldn't be too surprising, really.  C++ goes
against everything that good programmers are supposed to strive for:
Simplicity, clarity, ease of understanding, ease of maintenance,
abstraction of complexity, attention to (the problem's) detail, privacy
of implementation, good engineering tradeoffs, etc.  It's ironic that
many of these things are supposed to be made `easier' by C++.

When one works in C++, one finds oneself spending more time worrying
about minutae of syntax and minisule details to make the compiler happy
than worrying about the problem.  The effect is rather like drinking from
a firehose; while you *ought* to be getting all the details, there's no
way you can, because there are too many, and you get bogged down.

Many programmers find the language so difficult that they throw the
``good'' parts out the window and don't even attempt to provide, eg,
abstraction through classes.  Plus, the object system is all wrong,
forcing bizarre constructs like templates on the programmer, without
which it would be impossible to build anything remotely resembling a
generic container.

As pointed out by Presotto, much of this is a result of C++'s heritage
as an `extension' of C.  Java, IMHO, makes a better go of it by forgoing
C compatability where it makes sense, but as Forsyth noted, it's
concurrency model is grounded in decades old tradition; hardly an
advance of the state of the art.  It also falls short in a few other
places, such as making a distinction between objects and native types.

Then again, Rob Pike has described Java as an industrial response to
C++.  I don't think that's inaccurate.

One likes a programming language to be expressive; a tool for
communicating an idea, if you will.  Any time one gets swamped in
details imposed by the language, one is as a matter of course less
expressive in that language.  The ideal language is one that allows
an individual to express his- or herself directly and succintly.
I don't know of a language that really provides that, but C does
a reasonable job in some problem domains.  Languages like Python
do well in others (I really like python, even if the module system
is a little much).

One of the things about C, though, is that (IMHO) it works best as a
systems programming language.  As an application development language,
it has all sorts of traps and pitfalls (indeed, Koenig wrote a book
by that name once, listing many of them), and other annoyances, like
the lack of built-in ADTs (why should I build a dictionary myself?
99% of the time, I just want to use it; I don't care about how it's
implemented).

One does wonder, however, if the Unix utilities had been written in
another language like Limbo if we would be whitnessing all the stupid
buffer overrun attacks that the kids are using for bypassing security
these days.

Okay, I've rambled long enough.

	- Dan C.

Re: [9fans] Awk or Limbo ?

[Boyd Roberts]

From: "Dan Cross" <cross@math.psu.edu>
> One of the things about C, though, is that (IMHO) it works best as a
> systems programming language.  As an application development language,
> it has all sorts of traps and pitfalls (indeed, Koenig wrote a book
> by that name once, listing many of them) ...

yup, conehead had a wealth of experience. <laugh>

snocone, anyone?

Re: [9fans] Awk or Limbo ?

[Dan Cross]

In article <03cd01c0ceb9$70efa8c0$e8b7c6d4@SOMA> you write:
>snocone, anyone?

Have some brew and chips?

	- Dan C.

Re: [9fans] Awk or Limbo ?

[Boyd Roberts]

> Have some brew and chips?

nah, snocone was a snobol interpretter.

Re: [9fans] Awk or Limbo ?

[Dan Cross]

In article <001b01c0cecb$a01b71d0$e8b7c6d4@SOMA> you write:
>> Have some brew and chips?
>
>nah, snocone was a snobol interpretter.

Yeah, I know; the above is a quote from the coneheads.  :-)

	- Dan C.

Re: [9fans] Awk or Limbo ?

[Douglas A. Gwyn]

Dan Cross wrote:
> ... Plus, the [C++] object system is all wrong,
> forcing bizarre constructs like templates on the programmer, ...

? Templates seem like one of C++'s better features.
That and namespaces.
"Object orientation" fits GUI rather well, but is certainly
not natural for several other common programming needs.

> One of the things about C, though, is that (IMHO) it works best as a
> systems programming language.  As an application development language,
> it has all sorts of traps and pitfalls (indeed, Koenig wrote a book
> by that name once, listing many of them), and other annoyances, like
> the lack of built-in ADTs (why should I build a dictionary myself?
> 99% of the time, I just want to use it; I don't care about how it's
> implemented).

ADTs are easy to build in C; but part of it is that the programmer
himself must provide some of the discipline.

> One does wonder, however, if the Unix utilities had been written in
> another language like Limbo if we would be whitnessing all the stupid
> buffer overrun attacks that the kids are using for bypassing security
> these days.

Buffer overruns are not inherent in C; they're the result of
insufficient care by the undergraduates who whipped together
networking code that the industry then adopted without any
sensible review.  Similar problems occur using other languages.

Re: [9fans] Awk or Limbo ?

[Boyd Roberts]

From: "Douglas A. Gwyn" <gwyn@arl.army.mil>
> Buffer overruns are not inherent in C; they're the result of
> insufficient care by the undergraduates who whipped together
> networking code that the industry then adopted without any
> sensible review.  Similar problems occur using other languages.

bingo

Re: [9fans] Awk or Limbo ?

[Dan Cross]

In article <3AE976A5.34B30300@arl.army.mil> you write:
>Dan Cross wrote:
>> ... Plus, the [C++] object system is all wrong,
>> forcing bizarre constructs like templates on the programmer, ...
>
>? Templates seem like one of C++'s better features.
>That and namespaces.

They are, but that doesn't necessarily mean that they integrate well
with the rest of the programming environment, nor does it decrease
their bizarreness.

In this case, I think it's pretty clear that templates were an
afterthought, and they're grafted on in a convoluted way.  That said,
if forced into using C++, they are useful, but they ain't pretty....

As a specific example, create a class hierarchy, and then use templates
to create a container of objects from your class hierarchy.  (Or even
use the STL).  Note, now, that when you copy a subclass into the
container, it's converted to an instance of the base class and you
loose your subclass data.  Argh!  This is because polymorphism in C++
is only acheived when you refer to an object through a pointer or
reference, and templates are dumb.

Eiffel has a similar concept (I believe they even call them templates),
but I seem to recall that it integrates into the language in a *much*
less obtrusive way than in C++.

>"Object orientation" fits GUI rather well, but is certainly
>not natural for several other common programming needs.

Yes.

>> One of the things about C, though, is that (IMHO) it works best as a
>> systems programming language.  As an application development language,
>> it has all sorts of traps and pitfalls (indeed, Koenig wrote a book
>> by that name once, listing many of them), and other annoyances, like
>> the lack of built-in ADTs (why should I build a dictionary myself?
>> 99% of the time, I just want to use it; I don't care about how it's
>> implemented).
>
>ADTs are easy to build in C; but part of it is that the programmer
>himself must provide some of the discipline.

Sure, it's easy, but it's also easy to tie my shoes.  That doesn't make
it any less annoying.  :-)

When working on a problem, I start to envision what kind of structures
(in the sense of ``computational structures,'' not necessarily data
structures) I want to use to solve it.  For instance, I know that I'll
need an associative lookup, some sort of list, I'll have to put a sort
in some place, etc.  When I'm working in C, I have to go off and
implement most of that stuff before I can proceed.  It's not hard, but
it is tedious and annoying.  When working in another language (say,
smalltalk, for example) most of that stuff is already done for me, and
so I can just use it.  That's handy.

>> One does wonder, however, if the Unix utilities had been written in
>> another language like Limbo if we would be whitnessing all the stupid
>> buffer overrun attacks that the kids are using for bypassing security
>> these days.
>
>Buffer overruns are not inherent in C; they're the result of
>insufficient care by the undergraduates who whipped together
>networking code that the industry then adopted without any
>sensible review.  Similar problems occur using other languages.

No, they're not *inherent*, but they're a lot easier to make a mistake
which results in one.  Your example of undergraduates wreaking havoc
on the industry is right on, but if you think *those* undergraduates
were bad, you should see the code they write in industry!

But don't get me wrong; I like C, a lot.  I just think that it's
important to recognize that it's not the right tool for every job.

	- Dan C.

Re: [9fans] Awk or Limbo ?

[Douglas A. Gwyn]

Dan Cross wrote:
> When working on a problem, I start to envision what kind of structures
> (in the sense of ``computational structures,'' not necessarily data
> structures) I want to use to solve it.  For instance, I know that I'll
> need an associative lookup, some sort of list, I'll have to put a sort
> in some place, etc.  When I'm working in C, I have to go off and
> implement most of that stuff before I can proceed.  It's not hard, but
> it is tedious and annoying.  When working in another language (say,
> smalltalk, for example) most of that stuff is already done for me, and
> so I can just use it.  That's handy.

Actually, most of this kind of support could be already done in C,
too, but the problem is that not much of it is *standard*, so you
pretty much have to carry around your own support library.  I'm in
the process of updating the generally-useful packages of the MUVES
project's support library, to make it more suitable for embedded
applications.  I think when I finish I can give it away to anybody
who thinks he could use it.  When the time comes I'll tell more
about it, probably in comp.lang.c.moderated.

> But don't get me wrong; I like C, a lot.  I just think that it's
> important to recognize that it's not the right tool for every job.

Agreed.  However, it can be used to build more suitable tools..

Re: [9fans] Awk or Limbo ?

[nospam]

On Thu, 26 Apr 2001 21:32:27 GMT, wstan@localhostnl.demon.nl (William
Staniewicz) wrote:
>Some people mention Limbo and AWK. Which is used
>daily by the Plan9'rs?

presotto@plan9.bell-labs.com and boyd@planete.net both prefer (and
use(*) limbo, but there seems little evidence to me of common use as a
language to build applications for Plan9. Why is that?

(*) http://mapage.noos.fr/~repo/

Re: [9fans] Awk or Limbo ?

[geoff.9fans]

Popularity and quality are not related.  (A more pessimistic view is
that they are related, but inversely.  The current state of operating
systems, languages and software generally tends to support that view.)

Re: [9fans] Awk or Limbo ?

[geoff.9fans]

Limbo programs do seem to be more robust against buffer overflows,
deliberate or accidental, but I believe that the fundamental problem
is this: to be a good programmer, you have to be willing to cope with
all the details inherent in programming, and apparently most of the
population don't have the personality traits (patience, attention to
detail, etc.)  to do it (though that doesn't stop them trying).  One
of the advantages of writing substantial quantities of
assembly-language code is that everything else seems so much easier,
since there is so much less detail to deal with.  Limbo removes still
more fiddly details of memory allocation.  I think some of the
advantages of automatic string allocation can be had using Plan 9's
libString, which has existed for years inside upas.

But there's really no excuse for using gets() nor overrunning static
buffers.  If there's isn't a suitable routine around for the task at
hand, you write one.  It's amazing to me that as Sendmail, Inc. stamp
out one buffer overrun, another pops up, and it's 18 years later.
It's like a Conservation of Overruns.  These problems could have been
found and fixed in a pass over the code with a small string library
(such as the one we used in C News).  But the kids would rather write
yet another sorely-needed Linux desktop manager than tackle real
problems.  Rotten kids...

Barry Shein commented that `X was written by seventeen-year-olds who
can't program sitting down' (I hope I haven't misquoted him) and it
shows.  There's a little known program in the Plan 9 distribution,
Brenda Baker's dup(1), that one can run over the source of the latest
whiz-bang program and get a sense for how much code was cut-and-pasted
instead of converted into proper functions, presumably by the same
sort of kids with bladders full of Jolt cola.  Incidentally, the
distributed /rc/bin/dup didn't work when I last looked; here's a fixed
one:

#!/bin/rc
path=(/$cputype/bin/aux $path)
pdup $* | dupstat

See http://www.collyer.net/~geoff/cant.ps (when our DSL line is up)
for a longer, somewhat dated rant.

Re: [9fans] Awk or Limbo ?

[Scott Schwartz]

| It's like a Conservation of Overruns.  These problems could have been
| found and fixed in a pass over the code with a small string library
| (such as the one we used in C News).  But the kids would rather write
| yet another sorely-needed Linux desktop manager than tackle real
| problems.

The main problem is that there's no standard string library, but there is
a standard char* type and standard libc functions.  Ordinary programmers
have never read the source for C News (or similarly nice code), so they
don't know any better, or are inclined to just do the easiest thing.

There's only one hope:  Dennis Ritchie has to pick a string library,
declare it to be the One True C String Thing, and instruct, via an
announcement on slashdot, the swarming Linux minions to spread it to
the eight corners of the universe in a massive and unstoppable jihad,
followed, possibly, by it's inclusion in a future version of the
C standard.

Re: [9fans] Awk or Limbo ?

[Boyd Roberts]

> The main problem is that there's no standard string library, but there is
> a standard char* type and standard libc functions.

do me a favour.  it's a page of code:

echo flex.h
sed 's/.//' >flex.h <<'//GO.SYSIN DD flex.h'
-/*
- *	Flexible string definitions.
- *
- *	@(#)flex.h	1.31
- */
-
-#define FLEXZ	128
-
-typedef struct
-{
-	char	*f_str;
-	char	*f_end;
-	char	*f_ptr;
-}
-		flex;
-
-#define flex_char(f, c)	(*((f)->f_ptr == (f)->f_end ? flex_fill(f) :
(f)->f_ptr++) = (c))
-
-extern void	flex_end();
-extern char	*flex_fill();
-extern void	flex_init();
-extern void	flex_str();
-extern void	flex_nstr();
//GO.SYSIN DD flex.h

echo flex.c
sed 's/.//' >flex.c <<'//GO.SYSIN DD flex.c'
-/*
- *	Flexible string handling.
- */
-
-#ifndef	lint
-static char	sccsid[]	= "@(#)flex.c	1.31";
-#endif	lint
-
-#include	"mace.h"
-#include	"flex.h"
-
-void
-flex_init(f)
-register flex	*f;
-{
-	f->f_str = f->f_ptr = salloc(FLEXZ);
-	f->f_end = f->f_ptr + FLEXZ;
-}
-
-char	*
-flex_fill(f)
-register flex	*f;
-{
-	register int	s;
-
-	s = f->f_end - f->f_str + FLEXZ;
-
-	f->f_str = srealloc(f->f_str, s);
-	f->f_end = f->f_str + s;
-	f->f_ptr = f->f_end - FLEXZ;
-
-	return f->f_ptr++;
-}
-
-void
-flex_end(f)
-register flex	*f;
-{
-	f->f_ptr = f->f_str;
-}
-
-void
-flex_str(f, s)
-register flex	*f;
-register char	*s;
-{
-	while (*s != '\0')
-		flex_char(f, *s++);
-}
-
-void
-flex_nstr(f, s, n)
-register flex	*f;
-register char	*s;
-register int	n;
-{
-	while (n-- > 0 && *s != '\0')
-		flex_char(f, *s++);
-}
//GO.SYSIN DD flex.c

exit

and here's how you'd use it with an RFC 822 / STD 11 address:

-static void
-putdom(d)
-register Dom *d;
-{
-	register char **p;
-
-	for (p = d->sub; p != d->top; p++)
-	{
-		flex_str(&f, *p);
-		flex_char(&f, RFC_SPEC_DOT);
-	}
-
-	flex_str(&f, *p);
-}
-
-/*
- *	Take an Addr struct and return a textual representation that
- *	a delivery agent can use to deliver the message.
- */
-char	*
-make_address(a)
-register Addr	*a;
-{
-	register Dom	*d;
-	register char	*p;
-
-	if (f.f_str == NULLSTR)
-		flex_init(&f);
-
-	d = a->route;
-
-	while (d != (Dom *)0 && d->next != (Dom *)0)
-	{
-		/* source route */
-
-		flex_char(&f, RFC_SPEC_AT);
-		putdom(d);
-		flex_char(&f, d->next->next ? RFC_SPEC_COMMA : RFC_SPEC_COLON);
-		d = d->next;
-	}
-
-	flex_str(&f, a->localp);
-
-	if (d != (Dom *)0)
-	{
-		flex_char(&f, RFC_SPEC_AT);
-		putdom(d);
-	}
-
-	flex_char(&f, '\0');
-	p = newstr(f.f_str);
-	flex_end(&f);
-
-	return p;
-}

trivial.

Re: [9fans] Awk or Limbo ?

[Douglas A. Gwyn]

I suggest that the "community" beat really hard on proposed
library support for strings, time, bignums, etc. and arrive
at a consensus on an interface.  Then, a few years from now
when we start to consider proposals for C0x, submit the
interface spec *early in the process* and find at least one
champion on WG14 to push it forward.  Peter Seebach and I
are obvious choices, assuming we're still involved then.

Re: [9fans] Awk or Limbo ?

[Dan Cross]

In article <20010427023717.9765219A33@mail.cse.psu.edu> you write:
>
>  [lots of good comments elided for brevity]
>
>Barry Shein commented that `X was written by seventeen-year-olds who
>can't program sitting down' (I hope I haven't misquoted him) and it
>shows.  There's a little known program in the Plan 9 distribution,
>Brenda Baker's dup(1), that one can run over the source of the latest
>whiz-bang program and get a sense for how much code was cut-and-pasted
>instead of converted into proper functions, presumably by the same
>sort of kids with bladders full of Jolt cola.  Incidentally, the
>distributed /rc/bin/dup didn't work when I last looked; here's a fixed
>one:
>
>#!/bin/rc
>path=(/$cputype/bin/aux $path)
>pdup $* | dupstat

Plan 9 has dup(1) in it?  Not on my system unfortunately; I've been
looking for a copy for years, too....

Cutting and pasting may be bad in X, but you should have seen my last
job.  Oi.

	- Dan C.

Re: [9fans] Awk or Limbo ?

[geoff.9fans]

Russ observes that dup hasn't been distributed
with Plan 9 and indeed I don't see it in my 2nd
nor 3rd edition manuals.  I can't find it in netlib
either and google only finds the papers and references
thereto.  My senility must be accelerating; sorry
about that.

Re: [9fans] Awk or Limbo ?

[geoff.9fans]

For writing some applications, limbo is quite pleasant.  I've written
concurrent ("multithreaded") programs in limbo and felt comfortable
doing so, whereas using the Unix LWP (light-weight process) libraries
(or POSIX threads) directly has always seemed hazardous.  Unix LWPs
are fighting Unix, specifically the libraries, that were designed
assuming one process (or "thread") per address space.  This is one
reason (aside from unportability across Unixes and dubious gains) that
we let Rich Salz go off and do INN; I had no desire to deal with that
mess, especially the mess 10 years ago.

However, limbo is implemented as a part of Inferno and the two are
somewhat intertwined, so running limbo programs on Plan 9 is really
running limbo programs in Inferno on Plan 9, and Inferno's interface
as a command (emu) to the surrounding Plan 9 isn't seemless, though
it's getting better.  Thus forsyth's recent comments about a native
implementation of limbo on Plan9, which would make it more appealing
for some jobs.

libthread attempts to capture some of the benefits of limbo (notably
communication) in C, but I'd rather have one kind of process (not
processes and threads) and it feels a little like LWP libraries to me,
plus you don't get the concise limbo communication syntax and
automatic memory (de)allocation.

Re: [9fans] Awk or Limbo ?

[Boyd Roberts]

pthreads -- awful.

i coded up the pthreads version of a hash table of linked
lists -- ghastly.

bio.c had it right.

Re: [9fans] Awk or Limbo ?

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

>it's getting better.  Thus forsyth's recent comments about a native
>implementation of limbo on Plan9, which would make it more appealing
>for some jobs.

Isn't this a new version of Alef?   Yes, it apeals us very strongly.
I thought this wasn't possible because of some "political/economic"
reasons, but not of research...  I'm not blaming inferno though.

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2794 bytes --]

From: geoff.9fans@collyer.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Awk or Limbo ?
Date: Fri, 27 Apr 2001 15:09:41 -0400
Message-ID: <20010427191000.3ABBA19A80@mail.cse.psu.edu>

For writing some applications, limbo is quite pleasant.  I've written
concurrent ("multithreaded") programs in limbo and felt comfortable
doing so, whereas using the Unix LWP (light-weight process) libraries
(or POSIX threads) directly has always seemed hazardous.  Unix LWPs
are fighting Unix, specifically the libraries, that were designed
assuming one process (or "thread") per address space.  This is one
reason (aside from unportability across Unixes and dubious gains) that
we let Rich Salz go off and do INN; I had no desire to deal with that
mess, especially the mess 10 years ago.

However, limbo is implemented as a part of Inferno and the two are
somewhat intertwined, so running limbo programs on Plan 9 is really
running limbo programs in Inferno on Plan 9, and Inferno's interface
as a command (emu) to the surrounding Plan 9 isn't seemless, though
it's getting better.  Thus forsyth's recent comments about a native
implementation of limbo on Plan9, which would make it more appealing
for some jobs.

libthread attempts to capture some of the benefits of limbo (notably
communication) in C, but I'd rather have one kind of process (not
processes and threads) and it feels a little like LWP libraries to me,
plus you don't get the concise limbo communication syntax and
automatic memory (de)allocation.

Re: [9fans] Awk or Limbo ?

[Andrey A Mirtchovski]

On Tue, 1 May 2001 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> Isn't this a new version of Alef?   Yes, it apeals us very strongly.
>

all your alefs are belong to us :)

sorry. could not resist :)


this comment should not be understood as a pun of japanese english, but
rather as an... damit..it just sounds so ninja :)



andrey :)

who likes plan9 and www.ninjatune.net at the same time :)

--
stupendously wasting space on /n/dump since last night :)