Community

how outdated do you have to be? this is D, not assembler. this is a language
wich promotes type savety, ease of use, genericy, extendability, etc. none
of these exist in printf, and besides that, printf has much too much runtime
overhead for most tasks.
it is a tool yes. it can be used yes. doesn't make it good by any means. its
an improper tool, its an unsave tool, its a slow tool, a proprietary tool, a
monolithic tool, a non-type aware tool, etc.
it's about the worst piece of software existing in D and in c++. it has, in
both languages, no place to exist.
it was nice in c, yes. possibly.
the reason walter included it, is because at the start, D wasn't able to do
much more than calling functions (it's the first thing you have to get
working if you write a compiler), and printf is a function, you can rip the
source (he works at digital mars, he HAS the source for printf), and just
reuse it.
it was easy to insert. THATS why he used it. he even stated that. he knows
by himself it's shit.
"Matthew" <matthew.hat@stlsoft.dot.org> schrieb im Newsbeitrag
news:c0182c$2k6g$1@digitaldaemon.com...
> > it's not a bug of casting or anything. it's just the bad design of
printf.
> >
> > we're hard working on motivating walter to extend the language to
finally
> > get a real replacement.
> >
> > printf is shit. it will always be.
>
> What a ludicrous statement. Is assembler shit? Is void* shit? Is goto
shit?
> Are pointers shit? Are break/continue shit? Is for shit?
>
> If it's shit, can you explain why Walter and others (myself included) find
> it easy to use, and *very* rarely make errors using it?
>
> Maybe it's a tool, which, as with all others, have pros and cons. Once
> you've grokked it, you avoid the cons and experience only the pros. And
the
> pros of printf are considerable, which is why half the C-language family
> programming community prefer it over all the alternatives.
>
> How is any of what I'm saying not obvious to anyone/everyone?
>
> (Shakes his head in despair ...)
>
>
>

First, _you_ brought the invective into this by saying printf() is shit.
There are few flaws in printf() you could posit that I would not
acknowledge, and I neither maintain that it's great, nor superb, nor a model
of IO (or O) perfection. But to say that it is shit is ludicrous, and makes
you look like a fool.
More importantly, your characterisation doesn't help the ever increasing
numbers of people who are joining this group and getting interested in D,
many of whom may not be from C or C++, but will be inclined to wonder about
the whole quality of D if the (current) default output mechanism is shit.
Can I ask what modernity's got to do with anything? Are you saying that only
new things are good, and all chronological advances mark advances in
quality? If that's the case, why didn't Java become the pre-eminent language
of our time, as it was very "new" 7 or 8 years ago? If that's your criterion
for success, you need to stop software engineering and take up marketing.
Perhaps a better set of criteria would be Efficient, Robust, Maintainable
and Easy-to-use? What do you think? Given that, we should perhaps look at
printf() again with a considered mind.
Efficient? It's not the fastest thing in the world, to be sure, but it beats
the pants off the IOStreams. It's far from the zenith of performance. A
couple of years ago I had a "debate" with an ardent C programmer who said it
was impossible to write a type-safe, generic, streaming mechanism (in C++;
his challenge) that would outperform C streams. Needless to say I proved him
wrong. But since we don't currently have any alternative in D the efficiency
issue is moot.
Robust? This depends on your experience and perspective. IIRC sometime in
the last several months Walter asserted that he no longer makes mistakes
with printf()-family format specifiers. I can tell you that I don't either
(in C and C++); and I've only done the %s / %.*s mistake twice in my 2 years
of D. Maybe we're lying? That's up to you to decide. But if we're not, then
perhaps the robustness (or lack thereof) of printf() is, as I said in my
previous post, dependent on point of view. People crap on about Java being
far more robust than C++. Three years ago I had the unpleasant role of
Software Quality Manager for a group of Java developers working on an
internet banking product, already 12 months running past deadline when I was
recruited. I can tell you that I've never seen worse code or more dangerous
and fragile implementation (on all scales, from the individual function all
the way up to the system architecture) in any language, including my first
job in a team doing ISDN server development in assembler/C that had
conditional compilation for 13 targets over 4 different hardware
architectures.
Maintainable? printf() scores low on the maintainability scale. Maybe that
makes it shit? But what is maintainable? The IOStreams? You'll have to do
better than that.
Easy-to-use? It is ridiculously easy to use for 90% of one's requirements.
For the other 10% it can be quite vexing. Does that make it shit? It's no
harder (and in my opinion *far* easier) than the IOStreams for all those
weird border-case formatting stuff.
If you are dissatisfied with the current situation, and want us all to use
something better, then write it. If it's fast, robust, maintainable and
easy-to-use, I'll be the first one to swap over. Just make sure it's not
shit, as we wouldn't want to put off any more new users, would we?
"davepermen" <davepermen@hotmail.com> wrote in message
news:c01dch$2t61$1@digitaldaemon.com...
> how outdated do you have to be? this is D, not assembler. this is a
language
> wich promotes type savety, ease of use, genericy, extendability, etc. none
> of these exist in printf, and besides that, printf has much too much
runtime
> overhead for most tasks.
>
> it is a tool yes. it can be used yes. doesn't make it good by any means.
its
> an improper tool, its an unsave tool, its a slow tool, a proprietary tool,
a
> monolithic tool, a non-type aware tool, etc.
>
> it's about the worst piece of software existing in D and in c++. it has,
in
> both languages, no place to exist.
>
> it was nice in c, yes. possibly.
>
> the reason walter included it, is because at the start, D wasn't able to
do
> much more than calling functions (it's the first thing you have to get
> working if you write a compiler), and printf is a function, you can rip
the
> source (he works at digital mars, he HAS the source for printf), and just
> reuse it.
>
> it was easy to insert. THATS why he used it. he even stated that. he knows
> by himself it's shit.
>
> "Matthew" <matthew.hat@stlsoft.dot.org> schrieb im Newsbeitrag
> news:c0182c$2k6g$1@digitaldaemon.com...
> > > it's not a bug of casting or anything. it's just the bad design of
> printf.
> > >
> > > we're hard working on motivating walter to extend the language to
> finally
> > > get a real replacement.
> > >
> > > printf is shit. it will always be.
> >
> > What a ludicrous statement. Is assembler shit? Is void* shit? Is goto
> shit?
> > Are pointers shit? Are break/continue shit? Is for shit?
> >
> > If it's shit, can you explain why Walter and others (myself included)
find
> > it easy to use, and *very* rarely make errors using it?
> >
> > Maybe it's a tool, which, as with all others, have pros and cons. Once
> > you've grokked it, you avoid the cons and experience only the pros. And
> the
> > pros of printf are considerable, which is why half the C-language family
> > programming community prefer it over all the alternatives.
> >
> > How is any of what I'm saying not obvious to anyone/everyone?
> >
> > (Shakes his head in despair ...)
> >
> >
> >
>
>

Somehow, I have the impression that people either love printf or hate it. :)
I have a suggestion:
How about allowing printf as long as it is needed by the community? Nobody
forces you to use it.
IF someone comes up with something better than printf the majority
will use and printf will be ignored and forgotten.
Then Walter could have the compiler generate a warning that printf is
deprecated
and they should use something else. And of course, there should be a way to
disable the warning.
On the other hand, IF printf is still around after several years,
then I guess it has its place in a modern type-safe language such as D.
--
Jan-Eric Duden
"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
news:c01lqi$btq$1@digitaldaemon.com...
> First, _you_ brought the invective into this by saying printf() is shit.
>
> There are few flaws in printf() you could posit that I would not
> acknowledge, and I neither maintain that it's great, nor superb, nor a
model
> of IO (or O) perfection. But to say that it is shit is ludicrous, and
makes
> you look like a fool.
>
> More importantly, your characterisation doesn't help the ever increasing
> numbers of people who are joining this group and getting interested in D,
> many of whom may not be from C or C++, but will be inclined to wonder
about
> the whole quality of D if the (current) default output mechanism is shit.
>
> Can I ask what modernity's got to do with anything? Are you saying that
only
> new things are good, and all chronological advances mark advances in
> quality? If that's the case, why didn't Java become the pre-eminent
language
> of our time, as it was very "new" 7 or 8 years ago? If that's your
criterion
> for success, you need to stop software engineering and take up marketing.
>
> Perhaps a better set of criteria would be Efficient, Robust, Maintainable
> and Easy-to-use? What do you think? Given that, we should perhaps look at
> printf() again with a considered mind.
>
> Efficient? It's not the fastest thing in the world, to be sure, but it
beats
> the pants off the IOStreams. It's far from the zenith of performance. A
> couple of years ago I had a "debate" with an ardent C programmer who said
it
> was impossible to write a type-safe, generic, streaming mechanism (in C++;
> his challenge) that would outperform C streams. Needless to say I proved
him
> wrong. But since we don't currently have any alternative in D the
efficiency
> issue is moot.
>
> Robust? This depends on your experience and perspective. IIRC sometime in
> the last several months Walter asserted that he no longer makes mistakes
> with printf()-family format specifiers. I can tell you that I don't either
> (in C and C++); and I've only done the %s / %.*s mistake twice in my 2
years
> of D. Maybe we're lying? That's up to you to decide. But if we're not,
then
> perhaps the robustness (or lack thereof) of printf() is, as I said in my
> previous post, dependent on point of view. People crap on about Java being
> far more robust than C++. Three years ago I had the unpleasant role of
> Software Quality Manager for a group of Java developers working on an
> internet banking product, already 12 months running past deadline when I
was
> recruited. I can tell you that I've never seen worse code or more
dangerous
> and fragile implementation (on all scales, from the individual function
all
> the way up to the system architecture) in any language, including my first
> job in a team doing ISDN server development in assembler/C that had
> conditional compilation for 13 targets over 4 different hardware
> architectures.
>
> Maintainable? printf() scores low on the maintainability scale. Maybe that
> makes it shit? But what is maintainable? The IOStreams? You'll have to do
> better than that.
>
> Easy-to-use? It is ridiculously easy to use for 90% of one's requirements.
> For the other 10% it can be quite vexing. Does that make it shit? It's no
> harder (and in my opinion *far* easier) than the IOStreams for all those
> weird border-case formatting stuff.
>
>
> If you are dissatisfied with the current situation, and want us all to use
> something better, then write it. If it's fast, robust, maintainable and
> easy-to-use, I'll be the first one to swap over. Just make sure it's not
> shit, as we wouldn't want to put off any more new users, would we?
>
>
>
> "davepermen" <davepermen@hotmail.com> wrote in message
> news:c01dch$2t61$1@digitaldaemon.com...
> > how outdated do you have to be? this is D, not assembler. this is a
> language
> > wich promotes type savety, ease of use, genericy, extendability, etc.
none
> > of these exist in printf, and besides that, printf has much too much
> runtime
> > overhead for most tasks.
> >
> > it is a tool yes. it can be used yes. doesn't make it good by any means.
> its
> > an improper tool, its an unsave tool, its a slow tool, a proprietary
tool,
> a
> > monolithic tool, a non-type aware tool, etc.
> >
> > it's about the worst piece of software existing in D and in c++. it has,
> in
> > both languages, no place to exist.
> >
> > it was nice in c, yes. possibly.
> >
> > the reason walter included it, is because at the start, D wasn't able to
> do
> > much more than calling functions (it's the first thing you have to get
> > working if you write a compiler), and printf is a function, you can rip
> the
> > source (he works at digital mars, he HAS the source for printf), and
just
> > reuse it.
> >
> > it was easy to insert. THATS why he used it. he even stated that. he
knows
> > by himself it's shit.
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> schrieb im Newsbeitrag
> > news:c0182c$2k6g$1@digitaldaemon.com...
> > > > it's not a bug of casting or anything. it's just the bad design of
> > printf.
> > > >
> > > > we're hard working on motivating walter to extend the language to
> > finally
> > > > get a real replacement.
> > > >
> > > > printf is shit. it will always be.
> > >
> > > What a ludicrous statement. Is assembler shit? Is void* shit? Is goto
> > shit?
> > > Are pointers shit? Are break/continue shit? Is for shit?
> > >
> > > If it's shit, can you explain why Walter and others (myself included)
> find
> > > it easy to use, and *very* rarely make errors using it?
> > >
> > > Maybe it's a tool, which, as with all others, have pros and cons. Once
> > > you've grokked it, you avoid the cons and experience only the pros.
And
> > the
> > > pros of printf are considerable, which is why half the C-language
family
> > > programming community prefer it over all the alternatives.
> > >
> > > How is any of what I'm saying not obvious to anyone/everyone?
> > >
> > > (Shakes his head in despair ...)
> > >
> > >
> > >
> >
> >
>
>

"Jan-Eric Duden" <jeduden@whisset.com> skrev i en meddelelse
news:c02fd4$27fr$1@digitaldaemon.com...
> Somehow, I have the impression that people either love printf or hate it.
:)
>...
> On the other hand, IF printf is still around after several years,
> then I guess it has its place in a modern type-safe language such as D.
If you can call vargs with C linkage from D, you can just use the C std
library or some support C library could be added for D. In this way printf
will be available if you link with it.
As for a typesafe variant of printf: I haven't given it a lot of thought in
the context of D, however, I think it is perfectly doable to provide at
least runtime safety such that you get an exception if there is no valid
conversion. It may require special compiler support but then this is
probably the one construct where it is worthwhile.
If you require the formatting string to be a constant, the compiler can
typecheck all arguments in advance, effectively rolling a new printf
function each time it is called:
printf("hello %s world", "nice");
==>
printf("hello nice world"); // compile time substitution
printf("hello %s world", 1+1);
==>
printf("hello %s world", int_to_string(1+1)); // runtime conversion
printf("hello 2 world"); // or compile time conversion if possible
Having special compiler support allows for highly efficient code generation
because you do not need to parse the formatting string at runtime.
In case where the formatting string is not a constant, a slower version can
be called that does typeconversion to the formatting string on the fly with
possible exceptions for missing arguments or arguments with no conversion -
or perhaps such a construct is simply not permitted.
You could of course also support embedded expressions as in Ruby and C#
printf("hello #{2+2}"); // conversion to string
printf("hello #%x{2+2}"); // conversion according to specified formatter
This is just a more convenient version of the above.
Mikkel

the problem with this is, it means certain functions get special treatment.
this is unfair (an own printf would not work as fast then, and would not get
typechecking).
premature optimisation.
drop printf.
iostreams are much bether. the c++ version are rather bad implemented, but
you can do much bether if you want. but they are
faster
more robust
typesave
scalable
but anyways. some people are rather braindump sticking with printf praising
it as some holy grail. since 10 years people know its simply shit. but we
never get rid of it, as a lot simply let it stay alive. for what? for
nothing.
"MikkelFJ" <mikkel@dvideNOSPAMDOT.com> schrieb im Newsbeitrag
news:c039q0$fs1$1@digitaldaemon.com...
>
> "Jan-Eric Duden" <jeduden@whisset.com> skrev i en meddelelse
> news:c02fd4$27fr$1@digitaldaemon.com...
> > Somehow, I have the impression that people either love printf or hate
it.
> :)
> >...
> > On the other hand, IF printf is still around after several years,
> > then I guess it has its place in a modern type-safe language such as D.
>
> If you can call vargs with C linkage from D, you can just use the C std
> library or some support C library could be added for D. In this way printf
> will be available if you link with it.
>
> As for a typesafe variant of printf: I haven't given it a lot of thought
in
> the context of D, however, I think it is perfectly doable to provide at
> least runtime safety such that you get an exception if there is no valid
> conversion. It may require special compiler support but then this is
> probably the one construct where it is worthwhile.
>
> If you require the formatting string to be a constant, the compiler can
> typecheck all arguments in advance, effectively rolling a new printf
> function each time it is called:
>
> printf("hello %s world", "nice");
> ==>
> printf("hello nice world"); // compile time substitution
>
> printf("hello %s world", 1+1);
> ==>
> printf("hello %s world", int_to_string(1+1)); // runtime conversion
> printf("hello 2 world"); // or compile time conversion if possible
>
>
> Having special compiler support allows for highly efficient code
generation
> because you do not need to parse the formatting string at runtime.
>
> In case where the formatting string is not a constant, a slower version
can
> be called that does typeconversion to the formatting string on the fly
with
> possible exceptions for missing arguments or arguments with no
conversion -
> or perhaps such a construct is simply not permitted.
>
> You could of course also support embedded expressions as in Ruby and C#
>
> printf("hello #{2+2}"); // conversion to string
> printf("hello #%x{2+2}"); // conversion according to specified formatter
>
> This is just a more convenient version of the above.
>
> Mikkel
>
>