boost::log review (printf style api)
It is actually more relevant than a "flame war." We are discussing how a log API should look to be most useful (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library?
My point is that Boost is a C++ library and should not care at all about the impact on C developers, or people who happen to be used to that "glue language," even for their C++ development. I still think it is a valid discussion to have.
Well said. Good summary, although as noted, I disagree with your conclusion. The larger question is -- what has gone wrong with boost? Why do so many libraries languish in the review queue. Why has the the C++ standard taken so long to get enough momentum to pass through committee. In my view, C++ is tired. Boost is an experiment of a particular style of development, that being functional, generic, orthogonal and "non-hieararchical". Boost through its heavily template ladden libraries offered this style of development, and it had great appeal to those who had grown tired of object oriented style of development. The experience of those of us that have developed with this style over the years has been mixed. Like anything, somethings are nice, somethings are more trouble than there worth. Fortunately, for those of us that have an appreciation for functional programming will still be highly relevent in the future. The reason has primarily has to do with parralel programming which lends its self very nicely to functional programming, which is what boost is all about. The way I explain it, functional programming is just a variation of procedural programming with a different way of passing around state. Unfortunately, this advanced programming style is often abused in hideous ways. Particularly, when they are used in small utilty libraries which should be simple and general purpose, and not push a particular style of development. I've already made this point, but I'll make it again. Utility libraries should be agnositic and usable across the widest variety of programming styles, that being procedural, objected orienteated or functional. This boost::log library should not be approved without a simple "C" friendly api. That being a printf style api. Failure to include a "printf" style api will only continue to marginalize boost further to small subset of c++ developers. Most develpers will look at the api without a printf and go, HUH?
I think this is a highly interesting discussion. I just wonder: where can we have it? On www.lambda.org? Do we need to create a new forum, "Future of Native Development"? The people that will soon scream OT do (or will) have a point; Boost has (probably) decided, intrinsically, to be C++ only, and any usefulness from even C++ versions, such as Managed C++, is a pure coincidence. I will not comment it here anymore, in order not to stretch out this tangent too far. Perhaps it is best if we (such as you and I, initially) bring it off-list, till we figure out a proper forum? /David On Mar 14, 2010, at 6:59 PM, Tom Brinkman wrote:
It is actually more relevant than a "flame war." We are discussing how a log API should look to be most useful (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library?
My point is that Boost is a C++ library and should not care at all about the impact on C developers, or people who happen to be used to that "glue language," even for their C++ development. I still think it is a valid discussion to have.
Well said. Good summary, although as noted, I disagree with your conclusion.
The larger question is -- what has gone wrong with boost? Why do so many libraries languish in the review queue. Why has the the C++ standard taken so long to get enough momentum to pass through committee.
In my view, C++ is tired. Boost is an experiment of a particular style of development, that being functional, generic, orthogonal and "non-hieararchical".
Boost through its heavily template ladden libraries offered this style of development, and it had great appeal to those who had grown tired of object oriented style of development.
The experience of those of us that have developed with this style over the years has been mixed. Like anything, somethings are nice, somethings are more trouble than there worth.
Fortunately, for those of us that have an appreciation for functional programming will still be highly relevent in the future. The reason has primarily has to do with parralel programming which lends its self very nicely to functional programming, which is what boost is all about.
The way I explain it, functional programming is just a variation of procedural programming with a different way of passing around state.
Unfortunately, this advanced programming style is often abused in hideous ways. Particularly, when they are used in small utilty libraries which should be simple and general purpose, and not push a particular style of development.
I've already made this point, but I'll make it again. Utility libraries should be agnositic and usable across the widest variety of programming styles, that being procedural, objected orienteated or functional.
This boost::log library should not be approved without a simple "C" friendly api. That being a printf style api.
Failure to include a "printf" style api will only continue to marginalize boost further to small subset of c++ developers. Most develpers will look at the api without a printf and go, HUH? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sure, I'm always in a mood for a good debate. Pick the forum. On Sun, Mar 14, 2010 at 4:13 PM, David Bergman < David.Bergman@bergmangupta.com> wrote:
I think this is a highly interesting discussion. I just wonder: where can we have it? On www.lambda.org? Do we need to create a new forum, "Future of Native Development"?
The people that will soon scream OT do (or will) have a point; Boost has (probably) decided, intrinsically, to be C++ only, and any usefulness from even C++ versions, such as Managed C++, is a pure coincidence.
I will not comment it here anymore, in order not to stretch out this tangent too far. Perhaps it is best if we (such as you and I, initially) bring it off-list, till we figure out a proper forum?
/David
On Mar 14, 2010, at 6:59 PM, Tom Brinkman wrote:
It is actually more relevant than a "flame war." We are discussing how a log API should look to be most useful (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library?
My point is that Boost is a C++ library and should not care at all about the impact on C developers, or people who happen to be used to that "glue language," even for their C++ development. I still think it is a valid discussion to have.
Well said. Good summary, although as noted, I disagree with your conclusion.
The larger question is -- what has gone wrong with boost? Why do so many libraries languish in the review queue. Why has the the C++ standard taken so long to get enough momentum to pass through committee.
In my view, C++ is tired. Boost is an experiment of a particular style of development, that being functional, generic, orthogonal and "non-hieararchical".
Boost through its heavily template ladden libraries offered this style of development, and it had great appeal to those who had grown tired of object oriented style of development.
The experience of those of us that have developed with this style over the years has been mixed. Like anything, somethings are nice, somethings are more trouble than there worth.
Fortunately, for those of us that have an appreciation for functional programming will still be highly relevent in the future. The reason has primarily has to do with parralel programming which lends its self very nicely to functional programming, which is what boost is all about.
The way I explain it, functional programming is just a variation of procedural programming with a different way of passing around state.
Unfortunately, this advanced programming style is often abused in hideous ways. Particularly, when they are used in small utilty libraries which should be simple and general purpose, and not push a particular style of development.
I've already made this point, but I'll make it again. Utility libraries should be agnositic and usable across the widest variety of programming styles, that being procedural, objected orienteated or functional.
This boost::log library should not be approved without a simple "C" friendly api. That being a printf style api.
Failure to include a "printf" style api will only continue to marginalize boost further to small subset of c++ developers. Most develpers will look at the api without a printf and go, HUH? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
From: "Tom Brinkman" <reportbase2007@gmail.com> [snip] Snipped Tom's views and opinions about functional programming which I agree with but which are OT with regard to boost::log.
This boost::log library should not be approved without a simple "C" friendly
api. That being a printf style api.
I second that. If we want the library to be anything beyond an academic toy, it has to be practical and deployed, it should to be easy to retrofit such new library into *existing* projects. The ovewhelming majority of the projects I've been involved in use printf-style formating for logging. On a large scale the std::stream-style formatting failed miserably and programmers (well, at least those I worked with) voted with their feet/hends/whatever. Best, Vladimir.
AMDG Vladimir Batov wrote:
I second that. If we want the library to be anything beyond an academic toy, it has to be practical and deployed, it should to be easy to retrofit such new library into *existing* projects. The ovewhelming majority of the projects I've been involved in use printf-style formating for logging. On a large scale the std::stream-style formatting failed miserably and programmers (well, at least those I worked with) voted with their feet/hends/whatever.
The library does support Boost.Format. In Christ, Steven Watanabe
Vladimir Batov wrote:
From: "Tom Brinkman" <reportbase2007@gmail.com>
This boost::log library should not be approved without a simple "C" friendly api. That being a printf style api.
I second that. If we want the library to be anything beyond an academic toy, it has to be practical and deployed, it should to be easy to retrofit such new library into *existing* projects. The ovewhelming majority of the projects I've been involved in use printf-style formating for logging. On a large scale the std::stream-style formatting failed miserably and programmers (well, at least those I worked with) voted with their feet/hends/whatever.
Steven noted support for Boost.Format, so this library effectively supports streaming and printf-style formatting. I'll add that our own long lived logging API supports both styles and both are used regularly, often by the same developer. Consequently, while I think Tom over generalizes from his specific experiences, it is valuable to have efficient support for both formatting styles. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
From: "Stewart, Robert" <Robert.Stewart@sig.com>
Steven noted support for Boost.Format, so this library effectively supports streaming and printf-style formatting.
Yes, I remember having a look at Boost.Format (admittedly quite a while ago). The interface looked quite alien (which I could live with) and performance was not that great (I think back then it was std::iostream based, dunno these days). I agreed with Alexandrescu's view on that (http://erdani.com/publications/cuj-2005-08.pdf) and his alternative interface which I since adopted. Best, V.
On Sun, Mar 14, 2010 at 3:59 PM, Tom Brinkman <reportbase2007@gmail.com>wrote:
It is actually more relevant than a "flame war." We are discussing how a log API should look to be most useful (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library?
... lots of other stuff snipped. What you're *saying* (i.e., by voting no) is that boost::log is unsuitable for boost. What you're *arguing* (i.e. by means of your points / rationales), is that boost is unsuitable for... well, just about anything. These arguments appear to be completely separate issues. If you're saying that Boost.Log should not be accepted into Boost because it's a perfect Boost library, then that's not much of an argument from my point of view. I think your vote of no is somewhat unreasonable, but I do think it's reasonable to say that it should be accepted on condition that it add support for variadic template printf-style formatting. Zach
I do think it's reasonable to say that it should be accepted on condition that it add support for variadic template printf-style formatting.
Agreed. That sums it up. On Sun, Mar 14, 2010 at 6:45 PM, Zachary Turner <divisortheory@gmail.com>wrote:
On Sun, Mar 14, 2010 at 3:59 PM, Tom Brinkman <reportbase2007@gmail.com
wrote:
It is actually more relevant than a "flame war." We are discussing how a log API should look to be most useful (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library?
... lots of other stuff snipped.
What you're *saying* (i.e., by voting no) is that boost::log is unsuitable for boost. What you're *arguing* (i.e. by means of your points / rationales), is that boost is unsuitable for... well, just about anything.
These arguments appear to be completely separate issues. If you're saying that Boost.Log should not be accepted into Boost because it's a perfect Boost library, then that's not much of an argument from my point of view.
I think your vote of no is somewhat unreasonable, but I do think it's reasonable to say that it should be accepted on condition that it add support for variadic template printf-style formatting.
Zach _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Brinkman Sent: Sunday, March 14, 2010 10:59 PM To: Boost@lists.boost.org Subject: [boost] boost::log review (printf style api)
Failure to include a "printf" style api will only continue to marginalize boost further to small subset of c++ developers. Most developers will look at the api without a printf and go, HUH?
Others may go "UGH!" ... So last millennium ... ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Tom Brinkman wrote:
The larger question is -- what has gone wrong with boost?
That presupposes something has gone wrong with Boost.
Why do so many libraries languish in the review queue.
People are busy. I only recently volunteered to be a review manager. I'm working with the author to ready the library for review, but it takes time for both of us.
Why has the the C++ standard taken so long to get enough momentum to pass through committee.
Many (all?) committee members are volunteers, though some, I presume, have at least some financial backing from their employer. It is time consuming and not "their real job." Many of us sit back and await their efforts rather than being involved.
In my view, C++ is tired. Boost is an experiment of a particular style of development, that being functional, generic, orthogonal and "non-hieararchical".
Curiously, most developers at my company are only recently willing to jump on the Boost bandwagon and many are going at it with abandon. There were a great many years in which "template" was a dirty word when used for anything other than container-style genericity. Now they recognize the performance opportunities and other benefits and are willing to accept the problems to get them. That's the opposite trend from what you've described.
Boost through its heavily template ladden libraries offered this style of development, and it had great appeal to those who had grown tired of object oriented style of development.
Your opinion and experience clearly differs from that of others here. Without objective information, there is no way to gauge which is the more common, though one assumes this list is self selecting in favor of the Boost style.
Unfortunately, this advanced programming style is often abused in hideous ways.
So many things are.
Particularly, when they are used in small utilty libraries which should be simple and general purpose, and not push a particular style of development.
"As simple as possible, but no simpler" is always good. That, of course, must be weighed against useful flexibility and measured performance.
I've already made this point, but I'll make it again. Utility libraries should be agnositic and usable across the widest variety of programming styles, that being procedural, objected orienteated or functional.
Appealing to a wider audience is always nice, but not if it violates important principles. In the logging case, Boost.Format is a nice compromise. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (7)
-
David Bergman -
Paul A. Bristow -
Steven Watanabe -
Stewart, Robert -
Tom Brinkman -
Vladimir Batov -
Zachary Turner