RE: [9fans] g++

RE: [9fans] g++

[Tiit Lankots]

>yikes, even Star Trek script writers use Plan 9 now. 
 
should i feel elevated or depressed now ;)
 
Tiit
 
PS if they were, we would have seen acme on screens in Enterprise. Plan 9 has a tendency to stick.
Probably just because it's do damn beautiful.

RE: [9fans] g++

[ron minnich]

On Mon, 15 Sep 2003, Tiit Lankots wrote:

> Probably just because it's do damn beautiful.


This is an interesting point. Plan 9 esthetics are really nice. colors,
fonts, and so on just "look good". Who did all that?

ron

RE: [9fans] g++

[Geoff Collyer]

I believe Rob is the Plan 9 æsthete.

Re: [9fans] g++

[Rob Pike]

>
> This is an interesting point. Plan 9 esthetics are really nice. colors,
> fonts, and so on just "look good". Who did all that?
>

glad you like it.  really glad.  most people say something rude about
it.

i can take no credit for the fonts except for having the good luck to
know
chuck bigelow and kris holmes well enough to ask them to do a deal with
bell labs and let us use their fonts.  the postscript fonts used in the
manual,
which are related to the screen fonts (primarily those used in acme),
were
the first font designed specifically for unicode.  i also rather like
the screen
fonts, which were also maybe the first.

the clean appearance of the screen comes mostly from laziness, but the
color scheme is (obviously) deliberate. the intent was to build on an
observation by edward tufte that the human system likes nature and
nature
is full of pale colors, so something you're going to look at all day
might best
serve if it were also in relaxing shades.  renee french helped me with
the
specifics of the color scheme (she's a professional illustrator and my
color
vision is suspect), once i'd figured out how i wanted it to look.
there are
still some features of the color system that i put in that i think no
one has
ever noticed.  that's a good thing, in my opinion; the colors should
fade
away, if you'll pardon the expression.

having used other systems with different approaches to color screens,
most especially windows XP (extra pukey), i think tufte was right.

-rob

Re: [9fans] g++

[okamoto]

> having used other systems with different approaches to color screens,
> most especially windows XP (extra pukey), i think tufte was right.

I really love the color scheme of acme, too.

Kenji

Re: [9fans] g++

[boyd, rounin]

> glad you like it.  really glad.  most people say something rude about
> it.

i never liked the colours, but the don't worry me now and are infinitely
better than that child's playground known as XP.

OTOH i retract what i said about being able to 'pull on the side of
a transparent object' being a bad idea.  in retrospect, i always
wanted to resize labs' window systems' windows without having
to resort to 'Resize'.  i just wanted to change its size, not reposition
it too.  i have had to unlearn a lot of bad lunix habits i have picked up.

i always liked the fonts and the simplicity over the X11:

     -*-fuck-*-this-*-will-*-never-*-work-*-

(ahem) 'design'.

Re: [9fans] g++

[a]

this isn't directly related to the colo(u)?r scheme (sorry, i'm on an
extended stay in London), but the esthetics more generally are really
wonderful. as is the user interface in a more broad sense. just over a
year ago, i began using Mac OS X as my primary OS, and my Plan 9 usage
(aside from server usage) dropped significantly, much to my dismay. in
general i find the Mac OS X interface really, really nice. but there
remain several things i miss from plan 9, almost every hour i'm using
it. i miss ^W and ^U all the time (oh, and i miss having caps lock be
control, of course). i try to fade the colors as much as possible,
although OS X does a much better job by default than the teletubby OS
that is Win XP. Terminal.app is good, but i long for the rio windows.
and any time i'm doing any programming work or lower-level admin work,
i miss acme.

i find it somewhat ironic that while i love the UI of OS X, there
remain many elements i think Plan 9 does better.

i guess about a year and a half ago, maybe longer, i saw russ
demonstrate running plan 9 as a process on Win32. i'd love to be able
to do this on OS X. i've tried Inferno's version, but the OS X port
of Inferno is buggy, and not officially supported. i'd pay decent
money for a copy of either solution. we use Macs extensivly at work,
and i believe my employer would pay, as well. i realize it's
exceedingly dificult to make a business out of things like that, but
it remains frustrating that a solution is so close, but just out of
reach.

anyway: the plan 9 UI is amazing. calming, easy to use (once you
understand how), and consistant. wonderful.

oh, and nobody has anything *close* to how rio uses the mouse.
a

Re: [9fans] g++

[vdharani]

Hi,

These are the things I like in Plan 9 user interface:

- When the OS starts, it gives me a really clean screen. No menu bar, no
icons, nothing. Just a clean slate. I liked it so much, I manually removed
most of the icons in my Windows machine just to get closer to Plan 9 style.
May be I should also set my Wallpaper to a plain gray image. :-) I also
like the windows with just the borders.

- I like Acme a lot. It is simple and powerful. In particular, I like the 3-
button mouse usage and the Euro font (default font). One problem, though,
is I like the font so much, I find it difficult to use Plan 9 with a
resolution less than 1280x1024. And I miss Cut-and-Paste (with mouse)
feature of Plan 9 UI in every other OSes. Cant they atleast add it as a
configurable feature?

Regards
dharani

Re: [9fans] g++

[mirtchov]

> - I like Acme a lot. It is simple and powerful. In particular, I like the 3-
> button mouse usage and the Euro font (default font). One problem, though,
> is I like the font so much, I find it difficult to use Plan 9 with a
> resolution less than 1280x1024. And I miss Cut-and-Paste (with mouse)
> feature of Plan 9 UI in every other OSes. Cant they atleast add it as a
> configurable feature?

add the font as a configurable feature?  that's available as the -f
and -F options to acme (the Font acme command switches between the
two)...

i can cope reading email at 1024x768 with the euro.8 font (doing that
right now, in fact) but for programming in such small resolutions i
switch to 7x13, which is thinner, fixed size and gives you more space
for code.  it also supports more unicode glyphs than euro.8...

andrey

Re: [9fans] g++

[vdharani]

>> - I like Acme a lot. It is simple and powerful. In particular, I like
>> the 3- button mouse usage and the Euro font (default font). One
>> problem, though, is I like the font so much, I find it difficult to
>> use Plan 9 with a resolution less than 1280x1024. And I miss
>> Cut-and-Paste (with mouse) feature of Plan 9 UI in every other OSes.
>> Cant they atleast add it as a configurable feature?
>
> add the font as a configurable feature?  that's available as the -f and
> -F options to acme (the Font acme command switches between the two)...
No, I meant having Plan9-like cut-and-paste feature in Windows and Linux (X
Windows).

> i can cope reading email at 1024x768 with the euro.8 font (doing that
> right now, in fact) but for programming in such small resolutions i
> switch to 7x13, which is thinner, fixed size and gives you more space
> for code.  it also supports more unicode glyphs than euro.8...
If I am right, the font wasnt as neat looking as the euro.8. The euro.8 is
as good as an anti-aliased font in PDF.

dharani

Re: [9fans] g++

[YAMANASHI Takeshi]

"On Thu Sep 18 12:53:25 JST 2003, vdharani@infernopark.com wrote:"
> No, I meant having Plan9-like cut-and-paste feature in Windows and Linux (X
> Windows).

Mouse chording is my best beloved feature of acme.
If an editor has the chording and searching on button 3,
I would be sufficiently comfortable with it.

Even if it's the Windows Notepad, really.
--

Re: [9fans] g++

[Richard C Bilson]

> > This is an interesting point. Plan 9 esthetics are really nice. colors,
> > fonts, and so on just "look good". Who did all that?
>
> glad you like it.  really glad.  most people say something rude about
> it.

On the contrary -- I second Ron's sentiment.  I think I've had enough
faux-3d chrome to last a lifetime.

- Richard

Re: [9fans] g++

[andrey mirtchovski]

> glad you like it.  really glad.  most people say something rude about
> it.
>

i had to dig deep to find my comments about it, sent in a private email a
few months ago:

<quote>
i realized something: don't know whether it's the color scheme of rio, or
just the fact that plan9 is so much simpler and elegant, but i realized that
my stress level goes down tremendously as soon as i start up drawterm and do
some work in plan9. i find out that i can concentrate better there and spend
more time thinking about what i'm doing, rather than think about why my X is
running at nice -19, ponder over a bash one-liner, or wonder why xinetd
keeps usb port 840 open...

it was the same thing with linux and freebsd a few years back -- as soon as
i moved to freebsd i realized i was swimming in calmer waters...
</quote>

Ron didn't comment on my email back then, but he has seen the light now :)

[9fans] g++

[Andrew Simmons]

 > The only advance that the ``patterns'' community made was inventing a
common nomenclature.

That, and inventing the "Singleton" design pattern, for use on those
occasions when someone's holding a gun to your head trying to force you to
create an unnecessary second instance of a class. I invented the
"Doppelganger" and "Trifecta" patterns, for when you need exactly two or
three instances of a class, but they've never caught on.

Re: [9fans] g++

[Dan Cross]

> That, and inventing the "Singleton" design pattern, for use on those
> occasions when someone's holding a gun to your head trying to force you to
> create an unnecessary second instance of a class. I invented the
> "Doppelganger" and "Trifecta" patterns, for when you need exactly two or
> three instances of a class, but they've never caught on.

I like `trifecta'.  I've never had much luck at the aquaduct, though.

I'm not sure they invented the idea of a singleton, though (and I agree;
it's actually useful).  I believe they themselves say that nothing in the
book was new, it was just a collection of the better known, and useful
constructions.

	- Dan C.

Re: [9fans] g++

[paurea]

> I'm not sure they invented the idea of a singleton, though (and I agree;
> it's actually useful).  I believe they themselves say that nothing in the
> book was new, it was just a collection of the better known, and useful
> constructions.

Yes. To me they are just the OO generation of idioms.
							Gorka

RE: [9fans] g++

[Tiit Lankots]

>You'd still need to slap it with a phased verteron pulse, which would
>depolarize the resonance frequency generators and generate a subspace
>field implosion, inducing a reload of the positronic subprocessors from
>the protected memory archive.  Duh.
>

That's nonsense. If you depolarize the resonance frequency generators you
get a tachyon resonance cascade that will phase all positronic equipment.

Tiit

RE: [9fans] g++

[ron minnich]

On Mon, 15 Sep 2003, Tiit Lankots wrote:

>
> >You'd still need to slap it with a phased verteron pulse, which would
> >depolarize the resonance frequency generators and generate a subspace
> >field implosion, inducing a reload of the positronic subprocessors from
> >the protected memory archive.  Duh.
> >
>
> That's nonsense. If you depolarize the resonance frequency generators you
> get a tachyon resonance cascade that will phase all positronic equipment.

yikes, even Star Trek script writers use Plan 9 now.

ron

Re: [9fans] g++

[Laura Creighton]

	 >From: Martin C.Atkins <martin@parvat.com>
	 >To: 9fans@cse.psu.edu
	 >Subject: Re: [9fans] g++
	 >Organization: Parvat Infotech (Private) Limited
	 >Reply-To: 9fans@cse.psu.edu

	 ><snip>
	 >This discussion also reminds me of Sussman and Abelson's approach
	 >that the language should allow programming in the style appropriate
	 >to the problem, whether that style be o-o, logic, functional, etc.
	 >The problem in using different languages for each of these styles is
	 >that intercalling becomes difficult. The problem with using the same
	 >language is that no current (strongly-typed) language seems capable
	 >of (conveniently) supporting the whole range of styles. I want a
	 >compile-time strongly typed language for other, orthogonal but
	 >important, reasons.
	 >
	 >
	 >Martin
	 >--
	 >Martin C. Atkins			   martin@mca-ltd.com
	 >Mission Critical Applications Ltd, U.K.  http://www.mca-ltd.com{
	 >/,/martin}
	 >

We're working on writing a JIT specialised compiler for Python.
http://www.codespeak.net/pypy/index.cgi?home  One of the people
on the project is Armin Rigo, author of Psyco.
http://psyco.sourceforge.net/introduction.html

If we are as successful as we intend to be, will that take care of
your reasons?

Laura

[9fans] g++

[Andrew Simmons]

 > of course not.  do people think it is?  that's insane!

I think I detect the merest hint of sarcasm here, but seriously, what do
you mean by "o-o"? I've seen people earnestly arguing about whether or not
the STL is "really" object-oriented, and I don't really know what the term
means any more.

Re: [9fans] g++

[rob pike, esq.]

i was not being sarcastic.

polymorphism is the dual of o-o.  o-o fixes the data and varies the
functions (this->a(), this->b(), etc.); polymorphism fixes the
functions and varies the data (sort(type1), sort(type2), etc.).  the
stl uses macros to pretend all is o-o while the data varies
unpredictably in your hand.  have a look at how to define a custom
hash or allocator in STL.  somehow o-o + macros = polymorphism.  if
you can see the logic in that, you're probably insane; hence my
comment.

-rob

Re: [9fans] g++

[boyd, rounin]

> polymorphism is the dual of o-o.

i think it means o-oh, 'holy shit, man, this is one unstable
sumbitch. we had better watch our fucking step'.

    -- john keene

[9fans] g++

[Andrew Simmons]

 > Because we weren't anywhere near smart enough to build a working
 > kernel in C++.

But surely, if you'd built a Use Case Driven Object Model of the kernel
using UML, and used the Generic Iteration Workflow concept of the Rational
Unified Process for the Implementation Phase, you would have had no trouble
at all.

Re: [9fans] g++

[splite]

On Mon, Sep 15, 2003 at 10:13:05AM +1200, Andrew Simmons wrote:
> > Because we weren't anywhere near smart enough to build a working
> > kernel in C++.
>
> But surely, if you'd built a Use Case Driven Object Model of the kernel
> using UML, and used the Generic Iteration Workflow concept of the Rational
> Unified Process for the Implementation Phase, you would have had no trouble
> at all.

You'd still need to slap it with a phased verteron pulse, which would
depolarize the resonance frequency generators and generate a subspace
field implosion, inducing a reload of the positronic subprocessors from
the protected memory archive.  Duh.

Re: [9fans] g++

[Charles Forsyth]

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

i believe it is much quicker and indeed far more effective
to reverse the polarity of the neutron flow.

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

From: splite@purdue.edu
To: 9fans@cse.psu.edu
Subject: Re: [9fans] g++
Date: Mon, 15 Sep 2003 09:54:43 -0500
Message-ID: <20030915145443.GA8164@sigint.cs.purdue.edu>

On Mon, Sep 15, 2003 at 10:13:05AM +1200, Andrew Simmons wrote:
> > Because we weren't anywhere near smart enough to build a working
> > kernel in C++.
>
> But surely, if you'd built a Use Case Driven Object Model of the kernel
> using UML, and used the Generic Iteration Workflow concept of the Rational
> Unified Process for the Implementation Phase, you would have had no trouble
> at all.

You'd still need to slap it with a phased verteron pulse, which would
depolarize the resonance frequency generators and generate a subspace
field implosion, inducing a reload of the positronic subprocessors from
the protected memory archive.  Duh.

Re: [9fans] g++

[boyd, rounin]

> i believe it is much quicker and indeed far more effective
> to reverse the polarity of the neutron flow.

i think the the 9x19mm, 124 grain, FMJ round [about 30] from
an MP5-A5 would be a lot simpler;  deadly accurate, highly
reliable and not much recoil [roller locked, closed bolt].

might make a bit of noise but you could get the MP5SD
version which has a silencer:

    http://www.hkpro.com/video/MP5SD.mov

[9fans] g++

[Andrew Simmons]

 > implementing it using o-o so difficult you get monstrosities like the
 > STL

Stepanov has denied that the STL is object-oriented, and has very unkind
things to say about OO in general:

http://www.stlport.org/resources/StepanovUSA.html

Personally I've totally lost my grip on what "OO" is supposed to mean,
except that it seems to be some kind of magic fairy dust which
automatically results in good software, a bit like "structured" a few years
back.

Re: [9fans] g++

[rob pike, esq.]

> Stepanov has denied that the STL is object-oriented

of course not.  do people think it is?  that's insane!

-rob

RE: [9fans] g++

[Tiit Lankots]

>> Looking back at your previous message, perhaps it is the
>> "scope rules and silent actions associated with inheritance", in
>> which case are there any "Object Oriented" languages that you think
>> are OK?
>
>I'm not Charles, but I also answer.
>
>Have you seen Oberon-2?  It is OO done well.
>
> Brantley Coile
>
>

Oberon-2 pushes complexity out of the language and into the libraries, not 
unlike C. The part I miss most in it is some form of generics. Although I must
agree that its O-O is rather well-designed, indeed.

There appears to be some nasty law of physics at work here: the simple and
elegant O-O languages are easy to use right, but at the same time lack the
single biggest trump of O-O -- generics; while the languages that contain
generics are cumbersome and ugly. Go figure.

Tiit Lankots

RE: [9fans] g++

[rob pike, esq.]

> There appears to be some nasty law of physics at work here: the simple and
> elegant O-O languages are easy to use right, but at the same time lack the
> single biggest trump of O-O -- generics; while the languages that contain
> generics are cumbersome and ugly. Go figure.

i agree.  o-o is so easy to do by hand in the few cases it really
contributes to the design of software that it seems unimportant to
have languages centered on it, yet polymorphism is a genuine boon but
implementing it using o-o so difficult you get monstrosities like the
STL or lose all compile-time type safety, as with all the casting
through Object in Java.  don't know much about the generics in the new
Java but i've heard a lot of grumbling, so i don't hold out much hope.

but here's the bad news: within this state of affairs, we see o-o
being accepted as the foundation of good design and we educate our
students in that point of view.  o-o has its moments, but using it
well is very difficult.  i think the pattern book is the test that
proves the rule; if that's the best you can say, your apprach is
wrong.  o-o is clumsy, a big hammer that is only occasionally the
right tool.  when all you have in your hand is the o-o hammer,
everything is a thumb.

how did we get here? i despair.

-rob

Re: [9fans] g++

[Scott Schwartz]

| how did we get here?

Smart guys at Bell Labs produced an efficient OO language, and spread
it around widely, and no one else managed to produce an effective
(comfortable, usable, efficient) alternative.

Re: [9fans] g++

[boyd, rounin]

> | how did we get here?
>
> Smart guys at Bell Labs produced an efficient OO language, and spread
> it around widely, and no one else managed to produce an effective
> (comfortable, usable, efficient) alternative.

so why isn't plan 9 coded in C++?

Re: [9fans] g++

[David Presotto]

On Sun Sep 14 16:32:39 EDT 2003, boyd@insultant.net wrote:
> > | how did we get here?
> >
> > Smart guys at Bell Labs produced an efficient OO language, and spread
> > it around widely, and no one else managed to produce an effective
> > (comfortable, usable, efficient) alternative.
>
> so why isn't plan 9 coded in C++?
>
Because we weren't anywhere near smart enough to build a working
kernel in C++.

RE: [9fans] g++

[FODEMESI Gergely]

On Sun, 14 Sep 2003, rob pike, esq. wrote:

...
> implementing it using o-o so difficult you get monstrosities like the
> STL or lose all compile-time type safety, as with all the casting
> through Object in Java.  don't know much about the generics in the new
...

I suppose it wasn't rob but bwk, who wrote:
"It is a testament to the fundamental soundness of the STL design that
these changes required only substituting ...."
tpop, p81

I've been always wondering who wrote this.

 gergo

ps: tpop.awl.com

Re: [9fans] g++

[boyd, rounin]

> i think the pattern book is the test that
> proves the rule; if that's the best you can say, your apprach is
> wrong.

i don't understand these 'design pattern' zealots.  i don't need
a pattern -- i'll just code it.

Re: [9fans] g++

[Scott Schwartz]

| i don't understand these 'design pattern' zealots.  i don't need
| a pattern -- i'll just code it.

I didn't either, until I had to explain to some undergraduates how
to write programs.  Then suddenly you realize that there are ways and
means that you learned by reading "software tools" and a pile of open
source software and other stuff, but that these kids have never seen,
and are not going to see between now and monday, if ever.  So how do you
communicate those ideas in digestible chunks?  And after you've written
something for the ninth or tenth time, don't you want to reuse it?

The interesting critique I've heard about design patterns is that a
higher level/more powerful programming langauge is a better use of effort.

Re: [9fans] g++

[boyd, rounin]

> I didn't either, until I had to explain to some undergraduates how
> to write programs.

patterns is just a shake 'n bake approach.  the only way to get
good at it is to do it and have good teachers.

Re: [9fans] g++

[Dan Cross]

"boyd, rounin" <boyd@insultant.net> writes:
> patterns is just a shake 'n bake approach.  the only way to get
> good at it is to do it and have good teachers.

I like that: patterns is a shake 'n bake approach.  The only advance that
the ``patterns'' community made was inventing a common nomenclature.  That's
it.

	- Dan C.

Re: [9fans] g++

[Martin Harriss]

I've always liked Modula-3.  You do have to write code in a somewhat
idiomatic fashion to get the full benefit of the OO capabilities, but
overall it's quite a simple langueage (passes the "50-page rule.)  And
it has generics.

Shame it never cuaght on.

Martin


Tiit Lankots wrote:
>>>Looking back at your previous message, perhaps it is the
>>>"scope rules and silent actions associated with inheritance", in
>>>which case are there any "Object Oriented" languages that you think
>>>are OK?
>>
>>I'm not Charles, but I also answer.
>>
>>Have you seen Oberon-2?  It is OO done well.
>>
>>Brantley Coile
>>
>>
>
>
> Oberon-2 pushes complexity out of the language and into the libraries, not
> unlike C. The part I miss most in it is some form of generics. Although I must
> agree that its O-O is rather well-designed, indeed.
>
> There appears to be some nasty law of physics at work here: the simple and
> elegant O-O languages are easy to use right, but at the same time lack the
> single biggest trump of O-O -- generics; while the languages that contain
> generics are cumbersome and ugly. Go figure.
>
> Tiit Lankots
>

Re: [9fans] g++

[Scott Schwartz]

| I've always liked Modula-3.  You do have to write code in a somewhat
| idiomatic fashion to get the full benefit of the OO capabilities, but
| overall it's quite a simple langueage (passes the "50-page rule.)  And
| it has generics.
|
| Shame it never cuaght on.

But completely understandable.  The designers thought that sylistic
compatability with Modula-2 was important, but in reality the many
differences put off M2 users, while the Wirth style lack of ergonimics
put off C users.  Things like mandatory upper case keywords, and
unnecessary semicolons just screamed "B&D language".  Also, the quality
of implementation wasn't that good.  Simple programs created huge,
slow executables.  Why suffer when g++ does so much better?

Re: [9fans] g++

[boyd, rounin]

> I've always liked Modula-3.

i'm not really sure that was the solution either.  one of the nails
in its coffin was that SRC voted for C++ with the help of some
really fine taylor psychological manipulation.

Re: [9fans] g++

[YAMANASHI Takeshi]

> >> >> We need c++ sometime, ...
> > `We' must have been used in exclusive meaning, maybe.

`we' sometimes include the person addressed (inclusive),
but sometimes doesn't (exclusive).

In this case, I thought boyd is not included in `We' obviously. :)
But it seems boyd took it otherwise.
--

Re: [9fans] g++

[YAMANASHI Takeshi]

"On Fri Sep 12 13:42:34 JST 2003, okamoto@granite.cias.osakafu-u.ac.jp wrote:"
> >> We need c++ sometime, ...
> > no

`We' must have been used in exclusive meaning, maybe.
--

Re: [9fans] g++

[okamoto]

> "On Fri Sep 12 13:42:34 JST 2003, okamoto@granite.cias.osakafu-u.ac.jp wrote:"
>> >> We need c++ sometime, ...
>> > no
>
> `We' must have been used in exclusive meaning, maybe.

What does this mean?

Kenji

Re: [9fans] g++

[northern snowfall]

>
>
>`We' must have been used in exclusive meaning, maybe.
>
Boyd wa bakasakagen desu.
Hito natsukkoi desu. :-)

Don

http://www.7f.no-ip.com/~north_

FAI the web site is down while i recode the NetBSD kernel.

Re: [9fans] g++

[okamoto]

>>`We' must have been used in exclusive meaning, maybe.
>>
> Boyd wa bakasakagen desu.
> Hito natsukkoi desu. :-)

Yeah, I love his personality, judging from his writing here.
However, if he is more productive, I love him much.☺

Kenji

[9fans] g++

[okamoto]

I have not traced the discussion on gnu g++ port to Plan 9.
As I'm now try to compile hpijs utility, I'm facing this.
Is there anyone successfully using Plan 9 ported g++
by dhog?  If you do what is the latest version or setting
of it?

Kenji

Re: [9fans] g++

[Russ Cox]

okamoto@granite.cias.osakafu-u.ac.jp wrote:

>I have not traced the discussion on gnu g++ port to Plan 9.
>As I'm now try to compile hpijs utility, I'm facing this.
>Is there anyone successfully using Plan 9 ported g++
>by dhog?  If you do what is the latest version or setting
>of it?
>
>

It mostly works, with some band-aids.  It's not ready for prime time.
I may have a go at getting it more of the way there, to avoid needing
to use other operating systems to write C++, but I may not.

Russ

Re: [9fans] g++

[okamoto]

> It mostly works, with some band-aids.  It's not ready for prime time.
> I may have a go at getting it more of the way there, to avoid needing
> to use other operating systems to write C++, but I may not.

We need c++ sometime, because others use it.
Please have a go!

Kenji

Re: [9fans] g++

[boyd, rounin]

> We need c++ sometime, ...

no

Re: [9fans] g++

[okamoto]

>> We need c++ sometime, ...
>
> no

because you do only complain.
In the real world, we need it.

kenji

Re: [9fans] g++

[Peter Bosch]

>>> We need c++ sometime, ...
>>
>> no
>
> because you do only complain.
> In the real world, we need it.


why do we need it?  to write unreadable and unmaintainable code?

Re: [9fans] g++

[ron minnich]

On Fri, 12 Sep 2003, Peter Bosch wrote:

> why do we need it?  to write unreadable and unmaintainable code?


that's certainly a big part of it.

But, actually, there's a lot of C++ code out there for apps people care
about, and if you can't support them, then those potential plan 9 users
will go somewhere else.

At some point you have to make compromises if you want to have some
relevance.

I'd like to see Plan 9 come back out of its vmware hole-in-the-ground. To
do this, it needs users.

So, yes, C++ really sucks. But, if you want to see Plan 9 in wide use (I
do), then you get C++ on Plan 9.

ron

Re: [9fans] g++

[Peter Bosch]

> So, yes, C++ really sucks. But, if you want to see Plan 9 in wide use (I
> do), then you get C++ on Plan 9.

I'm maintaining a large pile of C++ code under Plan9.  There are
some oddities, but other than that the code just runs under Plan9.

Re: [9fans] g++

[Peter Bosch]

>> We need c++ sometime, ...
>
> no

agreed!

Re: [9fans] g++

[Charles Forsyth]

i found about 8 years ago that it was rather more productive to avoid
writing C++.  i found it harder to maintain than some other languages.  arguably
it does more checking that C (say) but the scope rules and silent actions associated
with inheritance, not to mention private languages by operator (re)definitions
made it a nightmare to read and maintain code written by others.
in fact, when i came back after several to some C++ code i'd written
myself, for the first time, i found i couldn't read some of my own code!
sometimes it was pretty, but sometimes it was just pretty confusing.
fortunately much of it didn't compile because the language had changed
again, and what did compile sometimes broke because g++ was broken, so i
gave up and rewrote it in something more sensible.

Re: [9fans] g++

[ron minnich]

On Fri, 12 Sep 2003, Charles Forsyth wrote:

> i found about 8 years ago that it was rather more productive to avoid
> writing C++.  i found it harder to maintain than some other languages.

that's not the issue, though. I don't write in C++ either.

The issue is, that some people do, and they won't change just because Plan
9 doesn't support C++. They'll just write plan 9 off as a possible
operating system.

ron

Re: [9fans] g++

[C H Forsyth]

i don't think i said it should not be supported.
come to think of it, i use pm which is currently still in c++.

if i aimed to discourage anything, it was
its enthusiastic use, especially for new things.
really, though, i was simply making some observations
about my own experience, particularly wrt maintenance,
since c++ and java enthusiasts often don't spend a lot
of time maintaining large quantities of other peoples'
code, and at one time, i did.  actually, i still do
but fortunately none of it is in c++ or java.
of course, the language is only part of it, as
rapidly becomes evident when reading the linux source code;
even to try to find the bits one needs to examine.
there's glory for you!

Re: [9fans] g++

[Brantley Coile]

In order to degrade the quality of this thread--or is it
to overload it?--does anyone have any current statistics on
the real use of C++ vs. C (or anything else)?  This may be
one of the few forums that are both informed and likely
to accept the truth regarding C++.

I thank my Deity that I've avoided C++ so far.

 Brantley

On Fri, 12 Sep 2003 16:39:47 +0100, C H Forsyth <forsyth@vitanuova.com> wrote:

> i don't think i said it should not be supported.
> come to think of it, i use pm which is currently still in c++.
>
> if i aimed to discourage anything, it was
> its enthusiastic use, especially for new things.
> really, though, i was simply making some observations
> about my own experience, particularly wrt maintenance,
> since c++ and java enthusiasts often don't spend a lot
> of time maintaining large quantities of other peoples'
> code, and at one time, i did.  actually, i still do
> but fortunately none of it is in c++ or java.
> of course, the language is only part of it, as
> rapidly becomes evident when reading the linux source code;
> even to try to find the bits one needs to examine.
> there's glory for you!
>

Re: [9fans] g++

[David Presotto]

The industry can generate any number you'ld like to hear.

Inside Lucent's BUs, C++ is the flavor of the weak.

Re: [9fans] g++

[ron minnich]

On Fri, 12 Sep 2003, David Presotto wrote:

> Inside Lucent's BUs, C++ is the flavor of the weak.
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
true!

can I get a T-shirt that says this? I'd wear it around here for as long as
I was allowed to live.


ron

Re: [9fans] g++

[David Presotto]

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

I'll have some made up.

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

From: ron minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] g++
Date: Fri, 12 Sep 2003 12:09:29 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0309121208430.12170-100000@maxroach.lanl.gov>

On Fri, 12 Sep 2003, David Presotto wrote:

> Inside Lucent's BUs, C++ is the flavor of the weak.
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
true!

can I get a T-shirt that says this? I'd wear it around here for as long as
I was allowed to live.


ron

Re: [9fans] g++

[boyd, rounin]

> I'll have some made up.

cool.  i assume the 'weak' was intentional.  nice pun.

Re: [9fans] g++

[mirtchov]

> In order to degrade the quality of this thread--or is it
> to overload it?--does anyone have any current statistics on
> the real use of C++ vs. C (or anything else)?  This may be
> one of the few forums that are both informed and likely
> to accept the truth regarding C++.
>
> I thank my Deity that I've avoided C++ so far.
>

at this here university if it's graphics it's C++.  others use Java, a
group or two does compiler work with Python and that's it.

i reimplemented a graphics language system in Haskell last year (the
original was written in C++) and it was much smaller, didn't crash,
and the speed was reasonable because it used the accelerated OpenGL
libraries already available.

it didn't impress anyone enough to say 'ok, let's switch'.

the gaming industry is all C++, and that's where the undergrads want
to go, so they demand to be taught in it.

Re: [9fans] g++

[Scott Schwartz]

In some recent (non-Plan 9) programming I've used C++.  The STL makes it
a slam-dunk decision.  It's just wrong to use char* instead of string,
or writing yet another hand coded container instead of just typing
map<string,int> or vector<foo>.  Any language without syntactically
convenient generics and a standard set of containers is just too painful
to use, in general.

Re: [9fans] g++

[boyd, rounin]

> In some recent (non-Plan 9) programming I've used C++.  The STL makes it
> a slam-dunk decision.  It's just wrong to use char* instead of string,
> or writing yet another hand coded container instead of just typing
> map<string,int> or vector<foo>.  Any language without syntactically
> convenient generics and a standard set of containers is just too painful
> to use, in general.

it's called 'limbo', but no one will use it so it's C++ or python.  i don't
wanna write any C++ -- ever.  i'm not that keen on writing python either.
and i certainly don't like writing in C for user mode stuff.

i have a native plan 9 awk, but it's buggy.  i hate debugging C.
i think i know what major bug is, but i haven't analysed it enough
to work out what i did wrong, but it's to do with mangling ARGC:

    http://plan9.bell-labs.com/magic/man2html/2/arg

which i had to do 'cos of a name clash.

Re: [9fans] g++

[Russ Cox]

>i have a native plan 9 awk, but it's buggy.  i hate debugging C.
>

seriously -- what's the point?
you could have patched the ape awk to use exits
in about five lines of code.  and now you've diverged
further from the source that bwk maintains.

Re: [9fans] g++

[boyd, rounin]

> seriously -- what's the point?

err, i wanted to do it and it would test out drawterm across the atlantic.

why not just get ape on plan 9 and _not port anything_?

> you could have patched the ape awk to use exits
> in about five lines of code.

i know/knew that.

so, should i just fix it with rm?  or should i countinue to bitch?  or both?

Re: [9fans] g++

[Sam]

>
> so, should i just fix it with rm?  or should i countinue to bitch?  or both?
>

Oh, please continue to bitch.  That's why I read 9fans.

;)

Sam

Re: [9fans] g++

[Ralph Corderoy]

Hi Sam,

> > so, should i just fix it with rm?  or should i countinue to bitch?
> > or both?
>
> Oh, please continue to bitch.  That's why I read 9fans.

I read it for the joy of hearing, just one more time, how Boyd wrote an
ftpfs as an NFS server.

Cheers,


Ralph.

Re: [9fans] g++

[boyd, rounin]

> In order to degrade the quality of this thread--or is it
> to overload it?--does anyone have any current statistics on
> the real use of C++ vs. C (or anything else)?

i don't have any stats, but given there are a large number
of machines that run windows and a large number of
applications that run on it one can assume there's a
lot of C++ code out there.  this presumes that the authors
are either masochists (writing in C) or writing C++.

there are just some things you can't do in C on windows
(tooltips iirc) without a lot of pain, but it's relatively trivial
in C++.

i just don't want to see this poison [C++] spread, but i
agree with ron that without it a lotta people will not look
at plan 9 -- pragmatism, ick ...

Re: [9fans] g++

[Dan Cross]

Brantley Coile <brantley@prepaynt.com> writes:
>
> In order to degrade the quality of this thread--or is it
> to overload it?--does anyone have any current statistics on
> the real use of C++ vs. C (or anything else)?  This may be
> one of the few forums that are both informed and likely
> to accept the truth regarding C++.

I can't sling any numbers, but I think C++ has its place.  I currently
pay my rent by slinging C++ code around; *I* don't really like it, but
times are rough and it's a way to make a living (of course, so is being
a two-bit nuckle buster for a loan-shark...).  That said, I think there
are good reasons to prefer C++ over C sometimes.  The existence of the
STL is a good one; I don't want to have to waste my time building basic
data structures and algorithms in C, and I find the STL implementation
less cumbersome than any general purpose C library I've found so far.
Certain things, like exceptions, can be nice to have in large
applications.

Personally, I'd rather just bite the bullet and program in C++ than
add all this stuff to C.  I think it's terrible that, e.g., Doug wants
to put exceptions et al into C; if you already need them, use another
language.

> I thank my Deity that I've avoided C++ so far.

You're a luckier man than me, I suppose.

But I'd point out that a programmer can write bad code in any language.
The fact that there's more bad code in C++ than in C (I'm not sure I
agree with that) might just be a function of their being more C++ code
out there than C code.  It's also likely a function of two other things;
the ability of C++ to `handle more complexity' (which, though intended
to reduce complexity, usually doesn't), and because in order to write
maintainable C++ code, the programmer has to be really, really
disciplined, and most aren't.

	- Dan C.

Re: [9fans] g++

[rob pike, esq.]

> But I'd point out that a programmer can write bad code in any language.
> The fact that there's more bad code in C++ than in C (I'm not sure I
> agree with that) might just be a function of their being more C++ code
> out there than C code.

if it's true - and i think it is true if we consider percentages rather than
absolute numbers of lines - it's because it's harder to write good software
in C++ but easier to write bad software.

it's a very difficult, tricky, special-case-ridden language that takes taste
and experience to use well.

-rob

Re: [9fans] g++

[boyd, rounin]

> it's a very difficult, tricky, special-case-ridden language that takes taste
> and experience to use well.

as dan pointed out:  you can code yourself easily into a very deep hole with c++

Re: [9fans] g++

[Dan Cross]

> it's a very difficult, tricky, special-case-ridden language that takes taste
> and experience to use well.

Thanks.  That more eloquently expresses what I was trying to get across.

Related, one can write useful, relatively clean code by ignoring 90% of
the language.  Unfortunately, most people don't do that.

	- Dan C.

Re: [9fans] g++

[bs]

Dan Cross wrote:
>>it's a very difficult, tricky, special-case-ridden language that takes taste
>>and experience to use well.
>
>
> Thanks.  That more eloquently expresses what I was trying to get across.
>
> Related, one can write useful, relatively clean code by ignoring 90% of
> the language.  Unfortunately, most people don't do that.
>
To that extent I use embedded C++ standards in my normal C++
development. It usually stays readable.

Re: [9fans] g++

[Brantley Coile]

While I've been successful at avoiding C++, I did begin long enough
ago to co-exist with PL/I.  It too was a very difficult, tricky,
special-case-ridden language.  We learned a subset,
as you suggest, of the language, but that didn't help you when we
were faced with other's code.

I remeber the first time I read the Pascal report and how excited I was that I could pretty much understand the entire language.  The importance of this seems to have been lost.  (But even C seems to have grown beyound understanding.  I understand the C99 is a 512 page
report and an upcomming book that comments on the standard is over 2,000 pages.)  Any programming language that takes more than 50 pages to describe is a problem.

 Brantley

On Sat, 13 Sep 2003 09:11:17 -0400, bs <bs@nospam.com> wrote:

> Dan Cross wrote:
>>> it's a very difficult, tricky, special-case-ridden language that takes taste
>>> and experience to use well.
>>
>>
>> Thanks.  That more eloquently expresses what I was trying to get across.
>>
>> Related, one can write useful, relatively clean code by ignoring 90% of
>> the language.  Unfortunately, most people don't do that.
>>
> To that extent I use embedded C++ standards in my normal C++ development. It usually stays readable.
>
>

Re: [9fans] g++

[Martin C.Atkins]

Hi Charles,

On Fri, 12 Sep 2003 16:39:47 +0100 C H Forsyth <forsyth@vitanuova.com> wrote:
>...
> since c++ and java enthusiasts often don't spend a lot

I'm interested that you lump in Java with C++ here, since I thought
that Java had removed most of the things that you listed as being
difficult to control in C++. Java also adds interfaces, which
addresses the single biggest flaw (IMHO) of C++. (Types should be based
on what things do, not on how they are constructed)

What is it about the Java language that you think causes the trouble?
(of course, there are many things about Java implementations to
dislike.) Looking back at your previous message, perhaps it is the
"scope rules and silent actions associated with inheritance", in
which case are there any "Object Oriented" languages that you think
are OK? (I'm assuming that you don't class Limbo as "Object Oriented"
here! :-)

Martin

--
Martin C. Atkins				martin@parvat.com
Parvat Infotech (Private) Limited		http://www.parvat.com

Re: [9fans] g++

[Brantley Coile]

On Sun, 14 Sep 2003 14:47:57 +0530, Martin C.Atkins <martin@parvat.com> wrote:

> Looking back at your previous message, perhaps it is the
> "scope rules and silent actions associated with inheritance", in
> which case are there any "Object Oriented" languages that you think
> are OK?

I'm not Charles, but I also answer.

Have you seen Oberon-2?  It is OO done well.

 Brantley Coile

Re: [9fans] g++

[Martin C.Atkins]

On Sun, 14 Sep 2003 08:53:26 -0400 Brantley Coile <brantley@prepaynt.com> wrote:
> On Sun, 14 Sep 2003 14:47:57 +0530, Martin C.Atkins <martin@parvat.com> wrote:
>
> > Looking back at your previous message, perhaps it is the
> > "scope rules and silent actions associated with inheritance", in
> > which case are there any "Object Oriented" languages that you think
> > are OK?
>
> I'm not Charles, but I also answer.

Sorry, I really meant:
	Hi Charles, Everyone,

>
> Have you seen Oberon-2?  It is OO done well.

I know of it. I suppose the thread that I was trying to pursue was
that Charles' message implied that the problems he had with C++ are
fundamental to the object-oriented approach (i.e. inheritance). What
does Oberon-2 do that mitigates the complications of "silent actions
associated with inheritance", for example?

On this question - Charles, would the modification of the 'self'
reference (so that it did not allow calls to overriding methods)
address your problems?

I've seen plenty of discussion (hype) over the last 20 years about
the advantages of the object-oriented approach, but precious little
analysis or discussion of the problems associated with it!

In this light, much of the following thread has been interesting,
especially the comments about generics, and polymorphism, but threads
such as Rob's comment:
> i agree.  o-o is so easy to do by hand in the few cases it really
> contributes to the design of software that it seems unimportant to
> have languages centered on it, yet polymorphism is a genuine boon but
>...
really begin to address the question of whether object-oriented
(whatever it means - that's another problem, but for now, maybe I
mean specifically the inheritance aspects) might be a step too far
for the understandable, maintainable construction of programs,
and what might be the alternatives.

As I touched on in my first message. I believe that better
type-compatibility rules in conventional languages (based on
interfaces, rather than construction) would be a step forward in
promoting the "o-o is so easy to do by hand in the few cases..."
part of Rob's message.

The Plan9 compiler's 'anonymous substructures' extension was an
interesting experiment in this direction. But what about making
pointers to
	struct { int a; int b}
and	struct { int a; int b; int c}
type compatible in the correct circumstances? This would provide support
for much of the power of o-o, but would it also open the door to
the abuses/difficulties?

This discussion also reminds me of Sussman and Abelson's approach
that the language should allow programming in the style appropriate
to the problem, whether that style be o-o, logic, functional, etc.
The problem in using different languages for each of these styles is
that intercalling becomes difficult. The problem with using the same
language is that no current (strongly-typed) language seems capable
of (conveniently) supporting the whole range of styles. I want a
compile-time strongly typed language for other, orthogonal but
important, reasons.

>
>  Brantley Coile
>

Martin
--
Martin C. Atkins			   martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.	   http://www.mca-ltd.com{/,/martin}

Re: [9fans] g++

[northern snowfall]

>
>
>The issue is, that some people do, and they won't change just because Plan
>9 doesn't support C++.
>
Right on. And as much as I may not enjoy C++, people should still be
allowed to use what ever language they prefer, not enforced to use
only what people think they should use.

Sure, when it comes to an issue such as security controls, that may
not be possible, given limits of a current technology. However, an
individual shouldn't be molded into what *Bob* or *I* believe is best
for them, unless they seek our guidance. Rather, I believe allowing
an individual to explore their computational curiosity by supporting
many flavors of a given facet ends up catering to more successful
projects, overall.

I don't believe the goal is as much to get users running plan9 as
it is to get users to *succeed in the computer field* via plan9.

Trust your technolust.
Don

http://www.7f.no-ip.com/~north_

FAI the web site is down while i recode the NetBSD kernel.

Re: [9fans] g++

[boyd, rounin]

> FAI the web site is down while i recode the NetBSD kernel.

that should keep you occupied ;)

Re: [9fans] g++

[northern snowfall]

>
>
>that should keep you occupied ;)
>

Nah, it's no big deal. I only audit/tweak the code paths I know
I'm going to use, so in the end the code path I read/alter is very
specific. It ends up being much less code than you'd think. I'm
already half done and it's been 4 non-full days.

Don

>
http://www.7f.no-ip.com/~north_

FAI the web site is down while i recode the NetBSD kernel.