Boost

[Jorgen Grahn]

Indeed, this supposedly means that you gonna use a computer program
helping you not to read. Otherwise you just keep reading. You must be
terribly clever, like your friends.

We never got the answer to the Boost concern. Do I have to be stupid to
use that?

Are you insulting people, nym-shifting and whatnot, and /still/ expect
people to discuss Boost with you? Seriously?

/Jorgen

 

[Oscar Chesnutt]

Are you insulting people, nym-shifting and whatnot, and /still/ expect
people to discuss Boost with you? Seriously?

What nym-shifting and what insulting, are you serious??

From what I read in this thread you and your likes are insulting by not
relating to the issues, calling people "trolls", "nym-shifters" and so on.

Plonk also is just another insult, otherwise if applied literary would
imply feeding a computer program or algorithm with a file, helping the
owner NOT TO READ in and usenet forum.

Are you going to debate semantics or talk about the issue indicated by the
subject line.

You and your "friends" are violating the unwritten rules of usenet. Take
care.

 

[Jorgen Grahn]

What nym-shifting and what insulting, are you serious??

As far as I can tell, you are posting in this thread as (at least)
Nick Baumbach
Walter Profile
Bob Hammerman
Oscar Chesnutt
That's the definition of nym-shifting, ok?

If you stop doing that, I'm prepared to discuss Boost[1] -- it
doesn't have diplomatic immunity or anything, and we're allowed to
criticize or defend it.

/Jorgen

[1] Except I personally don't have any real experience,
so I can only comment on the barriers to adopting it --
like trying to read up on some library and giving up
when I don't understand anything after 20 minutes.

 

[J. Clarke]

What nym-shifting and what insulting, are you serious??

As far as I can tell, you are posting in this thread as (at least)
Nick Baumbach
Walter Profile
Bob Hammerman
Oscar Chesnutt
That's the definition of nym-shifting, ok?

If you stop doing that, I'm prepared to discuss Boost[1] -- it
doesn't have diplomatic immunity or anything, and we're allowed to
criticize or defend it.

/Jorgen

[1] Except I personally don't have any real experience,
so I can only comment on the barriers to adopting it --
like trying to read up on some library and giving up
when I don't understand anything after 20 minutes.

And that's its real failing--like much else computer related the
documentation sucks bigtime.

 

[woodbrian77]

[1] Except I personally don't have any real experience,
so I can only comment on the barriers to adopting it --
like trying to read up on some library and giving up
when I don't understand anything after 20 minutes.

And that's its real failing--like much else computer related the
documentation sucks bigtime.

I could use some help with my documentation...
If you have some specific ideas on how to improve my
documentation please let me know. (And yes, the software
does support some of Boost.)

Brian
Ebenezer Enterprises -
“Ask and it will be given to you; seek and you will find;
knock and the door will be opened to you.' Matthew 7:7
http://webEbenezer.net

 

[Jorgen Grahn]

[1] Except I personally don't have any real experience,
so I can only comment on the barriers to adopting it --
like trying to read up on some library and giving up
when I don't understand anything after 20 minutes.

And that's its real failing--like much else computer related the
documentation sucks bigtime.

I don't believe that's true for the programming APIs I use.
- Sections 2, 3 and 7 of the Linux man pages (C, POSIX and Linux-
specific functions) are really well-written.
- for the "original" STL implementation, SGI's "Standard Template
Library Programmer's Guide" is excellent.

It seems to me the way [many] Boost libraries fail to document
themselves is that the actual /work/ the library does is hard to
explain. It's not primarily about writing skills.

/Jorgen

 

[Öö Tiib]

[1] Except I personally don't have any real experience,
so I can only comment on the barriers to adopting it --
like trying to read up on some library and giving up
when I don't understand anything after 20 minutes.

And that's its real failing--like much else computer related the
documentation sucks bigtime.

I don't believe that's true for the programming APIs I use.
- Sections 2, 3 and 7 of the Linux man pages (C, POSIX and Linux-
specific functions) are really well-written.
- for the "original" STL implementation, SGI's "Standard Template
Library Programmer's Guide" is excellent.

It seems to me the way [many] Boost libraries fail to document
themselves is that the actual /work/ the library does is hard to
explain. It's not primarily about writing skills.

Then it may help if you try to be more specific what you mean.
See: http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm
What percentage of listed libraries is so difficult to understand
like you describe? Can't be most of those. I also see that there
are things with rare specific usage or things that are obsolete
thanks to C++11. Rest of libraries still seem useful.

 

[Onoto Winnemucca]

What nym-shifting and what insulting, are you serious??

As far as I can tell, you are posting in this thread as (at least)
Nick Baumbach Walter Profile Bob Hammerman Oscar Chesnutt
That's the definition of nym-shifting, ok?

If you stop doing that, I'm prepared to discuss Boost[1] -- it doesn't
have diplomatic immunity or anything, and we're allowed to criticize or
defend it.

Hi Jorgen

I only can see that those posters are using a public usenet access posting
server. Are you sure you can read headers or just enjoy making a smart ass
of yourself.

You must be a big magician otherwise, with remote-viewing capabilities and
so on. Am I those people too?

In any case, you disrupt the flow of this interesting discussion by
calling others names, trolls etc. I suggest you leave in silence.

Admittedly you are incapable in programming, much less to tell anything
about Boost. Just leave, yesterday.

 

[J. Clarke]

[1] Except I personally don't have any real experience,
so I can only comment on the barriers to adopting it --
like trying to read up on some library and giving up
when I don't understand anything after 20 minutes.

And that's its real failing--like much else computer related the
documentation sucks bigtime.

I don't believe that's true for the programming APIs I use.
- Sections 2, 3 and 7 of the Linux man pages (C, POSIX and Linux-
specific functions) are really well-written.
- for the "original" STL implementation, SGI's "Standard Template
Library Programmer's Guide" is excellent.

It seems to me the way [many] Boost libraries fail to document
themselves is that the actual /work/ the library does is hard to
explain. It's not primarily about writing skills.

Then it may help if you try to be more specific what you mean.
See: http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm
What percentage of listed libraries is so difficult to understand
like you describe? Can't be most of those. I also see that there
are things with rare specific usage or things that are obsolete
thanks to C++11. Rest of libraries still seem useful.

I don't know what I was looking at earlier (or maybe it's just that I'm
well-rested at the moment) but what you linked is much improved over
whatever documentation I saw previously.

 

[Jorgen Grahn]

....

Hi Jorgen

I only can see that those posters are using a public usenet access posting
server. Are you sure you can read headers or just enjoy making a smart ass
of yourself.

You must be a big magician otherwise, with remote-viewing capabilities and
so on. Am I those people too?

Yes, as far as I can tell you are -- your style shines through.
Please stop doing this. You're not five years old; it's silly, and if
you think about it, it doesn't help you or anyone else.

/Jorgen

 

[Jorgen Grahn]

It seems to me the way [many] Boost libraries fail to document
themselves is that the actual /work/ the library does is hard to
explain. It's not primarily about writing skills.

Then it may help if you try to be more specific what you mean.
See: http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm
What percentage of listed libraries is so difficult to understand
like you describe?

I can't give you a percentage, but I note that I have Bjarne
Stroustrup on my side. See his FAQ.

Can't be most of those. I also see that there
are things with rare specific usage or things that are obsolete
thanks to C++11. Rest of libraries still seem useful.

Oh, I don't claim they aren't /useful/. They probably are -- but
there are so many complications to get past!

I used to feel the same way about the STL, fifteen years ago or so.
Iterators, the begin--end idiom ... that was stuff that I needed to
think about for some weeks or months before I "got" it and could use
it. The difference being that's stuff that's useful daily, in any
program. I'd prefer not to spend that kind of effort on every Boost
library which might or might not be useful to me.

Perhaps there should be "for dummies" Boost interfaces which are
simpler and cover what 99% of us need to do. Then if we max our those
interfaces we can turn to the "real" ones.

/Jorgen

 

[Alf P. Steinbach]

* Onoto Winnemucca a.k.a. user.speranza.aioe.org:

Am I those people too?

To the casual reader:

The above was posted in reply to Jorgen Grahn's reply to Oscar Chesnutt
a.k.a. user.speranza.aioe.org, and looking at the article references all
the way up to the start of the thread, every second article is by
user.speranza.aioe.org, posting under various fictitious names.

So, we're dealing with a childish troll.

May be relevant, or not:

<url: https://www.google.com/search?q=Michael+"Snit"+Glasser>


Cheers & hth.,

- Alf

 

[Onoto Winnemucca]

* Onoto Winnemucca a.k.a. user.speranza.aioe.org:

To the casual reader:

The above was posted in reply to Jorgen Grahn's reply to Oscar Chesnutt
a.k.a. user.speranza.aioe.org, and looking at the article references all
the way up to the start of the thread, every second article is by
user.speranza.aioe.org, posting under various fictitious names.

So, we're dealing with a childish troll.

May be relevant, or not:

<url: https://www.google.com/search?q=Michael+"Snit"+Glasser>

Another smart-ass wannabe. I am you too. I am your clone. I have your eyes.

Have you a reading disability, not seeing they are completely different
users, different user-agents and other things, posting through aioe.org
public server? There are millions of them.

More likely you are just stupid, or convincingly try to mimic one.

 

[Onoto Winnemucca]

Yes, as far as I can tell you are -- your style shines through. Please
stop doing this. You're not five years old; it's silly, and if you
think about it, it doesn't help you or anyone else.

You looks like an idiot. I must be you too.

Sincerely, me.

 

[Onoto Winnemucca]

I can't give you a percentage, but I note that I have Bjarne Stroustrup
on my side. See his FAQ.

I am convinced then. Who else do you know, Bill Gates, Linus Torvalds?

 

[Öö Tiib]

I can't give you a percentage, but I note that I have Bjarne
Stroustrup on my side. See his FAQ.

Stroustrup does say that some of it is too coupled and some of
it is too complex but it is bad idea to reinvent wheel if that is
already in boost (or in C++11).

Oh, I don't claim they aren't /useful/. They probably are -- but
there are so many complications to get past!

The complications arise from attempt to address boost as a whole.
It is *not* a whole. It is a lot of different purpose libraries. It is net
total 15 millions lines of code. So one approaching it *must* put on
heavy filters.

I used to feel the same way about the STL, fifteen years ago or so.
Iterators, the begin--end idiom ... that was stuff that I needed to
think about for some weeks or months before I "got" it and could use
it. The difference being that's stuff that's useful daily, in any
program. I'd prefer not to spend that kind of effort on every Boost
library which might or might not be useful to me.

Such major effort is likely overkill. Learn about a library in boost when
you need something like that. If it looks like overly complex then
look for alternatives.

Perhaps there should be "for dummies" Boost interfaces which are
simpler and cover what 99% of us need to do. Then if we max our those
interfaces we can turn to the "real" ones.

When there is big amount of things from different authors for various
purposes then that can not be likely made uniform, simple and easy to
access for dummies.

 

[woodbrian77]

Stroustrup does say that some of it is too coupled and some of
it is too complex but it is bad idea to reinvent wheel if that is
already in boost (or in C++11).

Hmm. There's also case where two approaches cover same
area, but they do so through different means. For
example, the serialization library in Boost uses C++
compiler based code generation and the C++ Middleware
Writer (CMW) is an external code generator.

If I took too literally your advice, I wouldn't have
developed CMW and imo C++ wouldn't have advantage over
other languages that CMW provides. CMW provides
automation of serialization like C# and Java, but
it goes beyond that in terms of being an on line
code generator.

The complications arise from attempt to address boost as a whole.
It is *not* a whole. It is a lot of different purpose libraries. It is net
total 15 millions lines of code. So one approaching it *must* put on
heavy filters.

Yes.


Such major effort is likely overkill. Learn about a library in boost when
you need something like that. If it looks like overly complex then
look for alternatives.

I have spent some days getting acquainted with a Boost
library only to eventually find what I considered to
be a serious flaw. This can happen with any library
regardless of it being in Boost or not.

When there is big amount of things from different authors for various
purposes then that can not be likely made uniform, simple and easy to
access for dummies.

"A fool with a plan can outsmart a genius with no plan."
T. Boone Pickens

Some of Boost is genius with no plan... Frankenstein.


Brian
Ebenezer Enterprises - "Where there is no revelation,
people cast off restraint; but blessed is the one who
heeds wisdom's instruction." Proverbs 29:18

http://webEbenezer.net

 

[Öö Tiib]

Hmm. There's also case where two approaches cover same
area, but they do so through different means.

Yes. We can always try to do same thing differently.
There's always some yet another way. However no one
has time to try all ways out.

If I took too literally your advice, I wouldn't have
developed CMW and imo C++ wouldn't have advantage over
other languages that CMW provides. CMW provides
automation of serialization like C# and Java, but
it goes beyond that in terms of being an on line
code generator.

Who knows? It may be that if you had taken my advice
literally then may be you would have developed some
other tool to some less or more full market that is less
or more outstanding from crowd. That we can never
tell.

About Java, C# or Python ... we often need to interoperate
with programs written in other languages indeed, but that
is not what your CMW helps with?

I have spent some days getting acquainted with a Boost
library only to eventually find what I considered to
be a serious flaw. This can happen with any library
regardless of it being in Boost or not.

More people look and try and use boost. So the defects
will be found and eventually repaired. That is one of the
strengths of boost.

 

[woodbrian77]

Yes. We can always try to do same thing differently.
There's always some yet another way. However no one
has time to try all ways out.

"Unless the L-rd builds the house, they labor in
vain who build it. Unless the L-rd guards the city,
the watchman waketh but in vain.' Psalms 127:1

Who knows? It may be that if you had taken my advice
literally then may be you would have developed some
other tool to some less or more full market that is less
or more outstanding from crowd. That we can never
tell.

About Java, C# or Python ... we often need to interoperate
with programs written in other languages indeed, but that
is not what your CMW helps with?

Other serialization libraries are also focused on C++.
Corba takes language neutral approach. Is it thriving?
I tend to think it is stagnant and dying.

My approach is to focus first on C++. After dust
settles, I hope to provide support for one or two other
languages. C++ is most important language for services,
so good place to start.

More people look and try and use boost. So the defects
will be found and eventually repaired. That is one of the
strengths of boost.

Don't hold your breath if you have requests for some
libraries. The maintenance can be very thin.


Brian
Ebenezer Enterprises
http://webEbenezer.net

 

[woodbrian77]

Other serialization libraries are also focused on C++.
Corba takes language neutral approach. Is it thriving?
I tend to think it is stagnant and dying.

My approach is to focus first on C++. After dust
settles, I hope to provide support for one or two other
languages. C++ is most important language for services,
so good place to start.

I looked into Java a number of years ago and found
it's requirement for a class to be in only one file
to be antithetical to code generation.

So I would guess the second language we'll support
will be either C# or Python.

Brian
Ebenezer Enterprises
http://webEbenezer.net