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
>
>