Re: eliminate writeln et comp?
dsimcha wrote: == Quote from Walter Bright (newshou...@digitalmars.com)'s article Having been involved with occasional contract disputes, I concur that the simpler and more obvious the language is, the better (and the lower your lawyer bill is :-) ). A perfect argument for the WTFPL! Yeah, but imagine a big lawsuit involving the WTFPL. There'd be a huge court case about what the F-word means. It'd be hilarious.
Re: eliminate writeln et comp?
On Mon, Mar 23, 2009 at 5:02 AM, dsimcha wrote: > == Quote from Walter Bright (newshou...@digitalmars.com)'s article >> Having been involved with occasional contract disputes, I concur that >> the simpler and more obvious the language is, the better (and the lower >> your lawyer bill is :-) ). > > A perfect argument for the WTFPL! As I understand it, in some places a warranty on software is implied if not specifically disclaimed. That's why such disclaimers can be found in just about every software license. I am not a lawyer, but I heard this from a lawyer. --bb
Re: eliminate writeln et comp?
== Quote from Walter Bright (newshou...@digitalmars.com)'s article > Having been involved with occasional contract disputes, I concur that > the simpler and more obvious the language is, the better (and the lower > your lawyer bill is :-) ). A perfect argument for the WTFPL!
Re: eliminate writeln et comp?
Georg Wrede wrote: Even if this includes "awkward things" (like having to have a constant string in the binary, mentioning Tango in the "About" menu item, or whatever else), it should be stated in layman-understandable terms. Currently, words like "encumbrance", phrases like "provides broad rights" etc. only make the prospective reader run away in frustration. Just state what you want, in language that can be understood at First Reading, without asking your mother. Or both of you having an IQ of 170+. Having been involved with occasional contract disputes, I concur that the simpler and more obvious the language is, the better (and the lower your lawyer bill is :-) ).
Re: eliminate writeln et comp?
Fawzi Mohamed wrote: On 2009-03-21 14:23:51 +0100, Daniel Keep said: Christopher Wright wrote: Daniel Keep wrote: Christopher Wright wrote: Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? "Portions of this program Copyright (C) Free Software Foundation. Uses glibc." Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel Right. It's invisible with glibc because you link to it dynamically, and because everyone installs it by default. Druntime has neither of these advantages. I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile "Hello, World" with Tango, distribute it and break the law. That glibc uses dynamic linking is immaterial: that there is no way to avoid the legal issues with Tango no matter what you do is the point I'm trying to make. -- Daniel This is bullshit, if you look at the header of c stdio.h you extremely likely to find exactly the same disclaimer (at least I did find it). If in your program you have an "about" and copyright, or you have documentation to it, then yes you should credit the inclusion of tango if you use the BSD license. Even if it doesn't have an "about" or documentation, you STILL need to include a license, as far as I can see. I don't see anything in the BSD license that allows you to avoid it, ever. If you want to avoid this then you should use the AFL license (which yes is incompatible with GPLv2). This if looking more and more like FUD. Fawzi Until this thread, I'd believed that. But now it seems that Phobos and Tango genuinely _are_ incompatible in terms of license issues. Are you sure that the AFL allows you to avoid the issue of providing a license? It's astonishingly difficult to make sense of that license. The 16-page commentary that it links you to is total rubbish, it seems to basically be an attack on the GPL, without saying what the AFL actually is. It only says: "In effect, then, AFL 3.0 is like the BSD license, with no reciprocal obligation to disclose source code." What the heck does "like" mean? It's certainly not the same, since BSD is GPL-compatible and AFL isn't. On that basis, it is NOT like the BSD license. I find that document (http://www.rosenlaw.com/OSL3.0-explained.pdf) appalling, and it severely erodes my confidence in the AFL.
Re: eliminate writeln et comp?
Lars Ivar Igesund wrote: Daniel Keep wrote: I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile "Hello, World" with Tango, distribute it and break the law. Sorry to use you as the source to enter the thread, Daniel. Tango DOES NOT IN ANY WAY require you to put attribution into your program. That is a choice you as a user would make entirely on your own by choosing to use Tango licensed under the BSD (which is quite possible because this license is better suited for use alongside the GPL). However, the AFL does not put such a restriction on your binaries, and (unless you use the GPL for your code) the AFL is the license most users should use. This is also noted on the license page (it was probably not clear enough, I hope it is now). http://dsource.org/projects/tango/wiki/LibraryLicense For current or prospective contributors; you are completely and entirely entitled to relicense your own code to whichever license you wish, however these should also include the AFL and BSD when used in Tango. To change the license to something else at this point (for instance to Apache 2.0 only), would be a major undertaking, but something that we may consider to do at a later point. I read http://dsource.org/projects/tango/wiki/LibraryLicense. I am sorry to say, the page /still/ is not /clear/ enough. (As of Mar 22, 00:24 UTC.) The first bullets establish the intent, yes. But everything after that is actually... worthless. What the page should instead say, is /in terms understandable to/ *anybody*, explain what you have to do if you incorporate Tango in your software, or if you make another library that depends on Tango. Even if this includes "awkward things" (like having to have a constant string in the binary, mentioning Tango in the "About" menu item, or whatever else), it should be stated in layman-understandable terms. Currently, words like "encumbrance", phrases like "provides broad rights" etc. only make the prospective reader run away in frustration. Just state what you want, in language that can be understood at First Reading, without asking your mother. Or both of you having an IQ of 170+. I'm not surprised that Don and others are getting second thoughts about contributing. A /clear/ stance to these issues makes everybody's (contributors, users, OS distributors, even app vendors) life easier. And, therefore, increases the popularity of Tango.
Re: eliminate writeln et comp?
On 2009-03-21 20:19:15 +0100, Fawzi Mohamed said: On 2009-03-21 14:23:51 +0100, Daniel Keep said: Christopher Wright wrote: Daniel Keep wrote: Christopher Wright wrote: Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? "Portions of this program Copyright (C) Free Software Foundation. Uses glibc." Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel Right. It's invisible with glibc because you link to it dynamically, and because everyone installs it by default. Druntime has neither of these advantages. I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile "Hello, World" with Tango, distribute it and break the law. That glibc uses dynamic linking is immaterial: that there is no way to avoid the legal issues with Tango no matter what you do is the point I'm trying to make. -- Daniel This is bullshit, if you look at the header of c stdio.h you extremely likely to find exactly the same disclaimer (at least I did find it). If in your program you have an "about" and copyright, or you have documentation to it, then yes you should credit the inclusion of tango if you use the BSD license. If you want to avoid this then you should use the AFL license (which yes is incompatible with GPLv2). This if looking more and more like FUD. Fawzi Sorry if I reacted a little too vehemently Fawzi
Re: eliminate writeln et comp?
On 2009-03-21 14:23:51 +0100, Daniel Keep said: Christopher Wright wrote: Daniel Keep wrote: Christopher Wright wrote: Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? "Portions of this program Copyright (C) Free Software Foundation. Uses glibc." Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel Right. It's invisible with glibc because you link to it dynamically, and because everyone installs it by default. Druntime has neither of these advantages. I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile "Hello, World" with Tango, distribute it and break the law. That glibc uses dynamic linking is immaterial: that there is no way to avoid the legal issues with Tango no matter what you do is the point I'm trying to make. -- Daniel This is bullshit, if you look at the header of c stdio.h you extremely likely to find exactly the same disclaimer (at least I did find it). If in your program you have an "about" and copyright, or you have documentation to it, then yes you should credit the inclusion of tango if you use the BSD license. If you want to avoid this then you should use the AFL license (which yes is incompatible with GPLv2). This if looking more and more like FUD. Fawzi
Re: eliminate writeln et comp?
Daniel Keep wrote: > I'm not talking about distribution of the actual library machine code, > I'm talking about the LEGAL ISSUES. Tango's license apparently requires > you to explicitly include attribution for Tango in your program. This > means it's possible to naively compile "Hello, World" with Tango, > distribute it and break the law. Sorry to use you as the source to enter the thread, Daniel. Tango DOES NOT IN ANY WAY require you to put attribution into your program. That is a choice you as a user would make entirely on your own by choosing to use Tango licensed under the BSD (which is quite possible because this license is better suited for use alongside the GPL). However, the AFL does not put such a restriction on your binaries, and (unless you use the GPL for your code) the AFL is the license most users should use. This is also noted on the license page (it was probably not clear enough, I hope it is now). http://dsource.org/projects/tango/wiki/LibraryLicense For current or prospective contributors; you are completely and entirely entitled to relicense your own code to whichever license you wish, however these should also include the AFL and BSD when used in Tango. To change the license to something else at this point (for instance to Apache 2.0 only), would be a major undertaking, but something that we may consider to do at a later point. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: eliminate writeln et comp?
Christopher Wright wrote: > Daniel Keep wrote: >> >> Christopher Wright wrote: >>> Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? "Portions of this program Copyright (C) Free Software Foundation. Uses glibc." >>> Executable code resulting from compilation is not a work derived from >>> GCC. >>> >>> glibc is extremely difficult to link statically and is distributed under >>> the LGPL, so no copyright notice is necessary. >>> >>> If dmd had good support for dynamic linking, this wouldn't be nearly as >>> much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it >>> can't be applied to the runtime. >> >> I think you're missing my point. I'm saying that a standard library >> shouldn't require you to insert legal disclaimers or attribution notices >> into your program or its documentation. >> >> A standard library should be be as invisible as possible in this regard. >> >> -- Daniel > > Right. It's invisible with glibc because you link to it dynamically, and > because everyone installs it by default. Druntime has neither of these > advantages. I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile "Hello, World" with Tango, distribute it and break the law. That glibc uses dynamic linking is immaterial: that there is no way to avoid the legal issues with Tango no matter what you do is the point I'm trying to make. -- Daniel
Re: eliminate writeln et comp?
Daniel Keep wrote: Christopher Wright wrote: Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? "Portions of this program Copyright (C) Free Software Foundation. Uses glibc." Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel Right. It's invisible with glibc because you link to it dynamically, and because everyone installs it by default. Druntime has neither of these advantages.
Re: eliminate writeln et comp?
Christopher Wright wrote: > Daniel Keep wrote: >> When was the last time you had to put this in your GCC-compiled programs? >> >> "Portions of this program Copyright (C) Free Software Foundation. Uses >> glibc." > > Executable code resulting from compilation is not a work derived from GCC. > > glibc is extremely difficult to link statically and is distributed under > the LGPL, so no copyright notice is necessary. > > If dmd had good support for dynamic linking, this wouldn't be nearly as > much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it > can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel
Re: eliminate writeln et comp?
On Fri, 20 Mar 2009 08:28:06 -0400, Don wrote: Boost, zlib, WTFYW, and public domain, seem to be the only ones which are suitable for a standard library. Actually, due to some interesting aspects of international copyright law public domain isn't suitable for a standard library. In some countries it is not possible to put a work into the public domain; a work may only enter it once the copyright has expired.
Re: eliminate writeln et comp?
Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? "Portions of this program Copyright (C) Free Software Foundation. Uses glibc." Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime.
Re: eliminate writeln et comp?
Fawzi Mohamed wrote: > after some extra digging > > tango licensing: > > BSD (and this is the revised 3 clause BSD) > - is compatible with GPL > - copyright need to be advertised also in the documentation and binary > > a commonly used permissive license (which probably you are using when > linking for example network code in almost any operating system). > It does *not* include the original fourth statement of BSD > > APL > - similar to BSD, but with some extra protections against the liability > of the licenser, in particular with respect to patents > - these extra restrictions make it incompatible with GPLv2 > - it should be equivalent to apache 2.0 ( > http://www.opensource.org/proliferation-report ) > and so it might be compatible with GPLv3 but I am not 100% sure on this. > > In any case the double licensing of tango allows one to use it also with > GPL code > > Fawzi > When was the last time you had to put this in your GCC-compiled programs? "Portions of this program Copyright (C) Free Software Foundation. Uses glibc." For a regular library, binary attribution clauses are OK. For a standard library, it's distasteful [1]. I shouldn't HAVE to worry about legal issues from compiling Hello World. -- Daniel [1] I've contributed code to Tango under BSD. If I'd have known about this issue, I would have made it Public Domain or a license without the binary attribution clause.
Re: eliminate writeln et comp?
after some extra digging tango licensing: BSD (and this is the revised 3 clause BSD) - is compatible with GPL - copyright need to be advertised also in the documentation and binary a commonly used permissive license (which probably you are using when linking for example network code in almost any operating system). It does *not* include the original fourth statement of BSD APL - similar to BSD, but with some extra protections against the liability of the licenser, in particular with respect to patents - these extra restrictions make it incompatible with GPLv2 - it should be equivalent to apache 2.0 ( http://www.opensource.org/proliferation-report ) and so it might be compatible with GPLv3 but I am not 100% sure on this. In any case the double licensing of tango allows one to use it also with GPL code Fawzi
Re: eliminate writeln et comp?
On 2009-03-20 13:28:06 +0100, Don said: Robert Jacques wrote: On Thu, 19 Mar 2009 09:23:44 -0400, Don wrote: I agree, requiring to include copyright with every binary distribution is unacceptable for a standard library. But... Tango is also available under the Academic Free License. Which I don't understand, despite having read through the ten page explanation of it. Specifically, you're allow to change it to "any license of your choice that does not contradict the terms and conditions, including Licensor's reserved rights and remedies, in this Academic Free > License;" But what does that mean? Which licenses does it include? Does it include the zlib license? I presume not. I read more carefully and tried to understand it better, I had not understood the problem that makes it incompatible with GPL, the thing is that it puts extra restrictions that limit the responsibility of the licenser, in particular has provisions for revoking the patent granted to the licensee should he choose to make a patent claim about the original work. Which is reasonable, but an extra restriction, and thus incompatible with GPL In which case Andrei and Walter's position is entirely justified. If that is correct, I will cease contributing to Tango. Someone, _please_ tell me I'm wrong. No, sadly you're right. According to wikipedia, the AFL is not GPL compatible. If AFL could be converted to zlib then you could convert ALF source to zlib and it would then be GPL compatible. Q.E.D. Hence, ALF can not be convert to zlib. So far the only other licence I saw without the binary-licence distribution problem is the Boost Software License (BSL1.0) (And of course the WTFYW licence) And I'm guessing this issue is why they wrote a new licence instead of reusing an old one. The zlib license also doesn't have the binary distribution problem. The Boost license looks pretty good to me, and they seem to have used better legal consultation than the zlib license. I also like the fact that it only occupies 3 lines of source code -- that's much better than zlib. Boost, zlib, WTFYW, and public domain, seem to be the only ones which are suitable for a standard library. I agree that these a good licenses for a standard library.
Re: eliminate writeln et comp?
On 2009-03-20 05:46:08 +0100, "Robert Jacques" said: On Thu, 19 Mar 2009 09:23:44 -0400, Don wrote: I agree, requiring to include copyright with every binary distribution is unacceptable for a standard library. But... Tango is also available under the Academic Free License. Which I don't understand, despite having read through the ten page explanation of it. Specifically, you're allow to change it to "any license of your choice that does not contradict the terms and conditions, including Licensor's reserved rights and remedies, in this Academic Free > License;" But what does that mean? Which licenses does it include? Does it include the zlib license? I presume not. In which case Andrei and Walter's position is entirely justified. If that is correct, I will cease contributing to Tango. Someone, _please_ tell me I'm wrong. No, sadly you're right. According to wikipedia, the AFL is not GPL compatible. If AFL could be converted to zlib then you could convert ALF source to zlib and it would then be GPL compatible. Q.E.D. Hence, ALF can not be convert to zlib. yes as far as I understand the problem with AFL is that it has a kind of viral component like GPL, in that derivative work need to have a compatible license, and redistribution should ensure that the license is preserved, zlib does not have that. I don't think it is wrong, but I would be happy also with zlib... Fawzi So far the only other licence I saw without the binary-licence distribution problem is the Boost Software License (BSL1.0) (And of course the WTFYW licence) And I'm guessing this issue is why they wrote a new licence instead of reusing an old one. Actually, some of the BSD/MIT like licences might be valid if you included the licence string as a constant in the binary distribution (although this is definitely not in the spirit of the licence)
Re: eliminate writeln et comp?
Robert Jacques wrote: On Thu, 19 Mar 2009 09:23:44 -0400, Don wrote: I agree, requiring to include copyright with every binary distribution is unacceptable for a standard library. But... Tango is also available under the Academic Free License. Which I don't understand, despite having read through the ten page explanation of it. Specifically, you're allow to change it to "any license of your choice that does not contradict the terms and conditions, including Licensor's reserved rights and remedies, in this Academic Free > License;" But what does that mean? Which licenses does it include? Does it include the zlib license? I presume not. In which case Andrei and Walter's position is entirely justified. If that is correct, I will cease contributing to Tango. Someone, _please_ tell me I'm wrong. No, sadly you're right. According to wikipedia, the AFL is not GPL compatible. If AFL could be converted to zlib then you could convert ALF source to zlib and it would then be GPL compatible. Q.E.D. Hence, ALF can not be convert to zlib. So far the only other licence I saw without the binary-licence distribution problem is the Boost Software License (BSL1.0) (And of course the WTFYW licence) And I'm guessing this issue is why they wrote a new licence instead of reusing an old one. The zlib license also doesn't have the binary distribution problem. The Boost license looks pretty good to me, and they seem to have used better legal consultation than the zlib license. I also like the fact that it only occupies 3 lines of source code -- that's much better than zlib. Boost, zlib, WTFYW, and public domain, seem to be the only ones which are suitable for a standard library. Actually, some of the BSD/MIT like licences might be valid if you included the licence string as a constant in the binary distribution (although this is definitely not in the spirit of the licence)
Re: eliminate writeln et comp?
On Thu, 19 Mar 2009 09:23:44 -0400, Don wrote: I agree, requiring to include copyright with every binary distribution is unacceptable for a standard library. But... Tango is also available under the Academic Free License. Which I don't understand, despite having read through the ten page explanation of it. Specifically, you're allow to change it to "any license of your choice that does not contradict the terms and conditions, including Licensor's reserved rights and remedies, in this Academic Free > License;" But what does that mean? Which licenses does it include? Does it include the zlib license? I presume not. In which case Andrei and Walter's position is entirely justified. If that is correct, I will cease contributing to Tango. Someone, _please_ tell me I'm wrong. No, sadly you're right. According to wikipedia, the AFL is not GPL compatible. If AFL could be converted to zlib then you could convert ALF source to zlib and it would then be GPL compatible. Q.E.D. Hence, ALF can not be convert to zlib. So far the only other licence I saw without the binary-licence distribution problem is the Boost Software License (BSL1.0) (And of course the WTFYW licence) And I'm guessing this issue is why they wrote a new licence instead of reusing an old one. Actually, some of the BSD/MIT like licences might be valid if you included the licence string as a constant in the binary distribution (although this is definitely not in the spirit of the licence)
Re: eliminate writeln et comp?
Adam D. Ruppe wrote: On Thu, Mar 19, 2009 at 11:47:37AM +0100, Alexander Pánek wrote: This library is available licensed under BSD, which basically means you can do whatever you please with it, as long as you don???t remove the copyright of the original authors. I think that's an unreasonable demand in a standard library. Incorporating BSD code into phobos, any amount of it, requires that every D program that is ever written to include their copyright notice, since phobos is redistributed in binary form with every D program. I agree, requiring to include copyright with every binary distribution is unacceptable for a standard library. But... Tango is also available under the Academic Free License. Which I don't understand, despite having read through the ten page explanation of it. Specifically, you're allow to change it to "any license of your choice that does not contradict the terms and conditions, including Licensor's reserved rights and remedies, in this Academic Free License;" But what does that mean? Which licenses does it include? Does it include the zlib license? I presume not. In which case Andrei and Walter's position is entirely justified. If that is correct, I will cease contributing to Tango. Someone, _please_ tell me I'm wrong. That's a pain to hobbyists and might be a roadblock to use the language professionally. As far as I know, the entire phobos library is currently public domain or zlib license, which is basically just public domain written out explicitly. That's the way it should remain.
Re: eliminate writeln et comp?
On Thu, Mar 19, 2009 at 11:47:37AM +0100, Alexander Pánek wrote: > This > library is available licensed under BSD, which basically means you can > do whatever you please with it, as long as you don???t remove the > copyright of the original authors. I think that's an unreasonable demand in a standard library. Incorporating BSD code into phobos, any amount of it, requires that every D program that is ever written to include their copyright notice, since phobos is redistributed in binary form with every D program. That's a pain to hobbyists and might be a roadblock to use the language professionally. As far as I know, the entire phobos library is currently public domain or zlib license, which is basically just public domain written out explicitly. That's the way it should remain. -- Adam D. Ruppe http://arsdnet.net
Re: eliminate writeln et comp?
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
That's not a very frequent operation. In most cases you should use
Cout("Hello"); instead. An ideal design solution, imo (fast, short
and clear).
Interesting. Should I do the same in phobos?
stdout("wyda");
I'd like that particularly because write() is too common a name to
place at namespace level for my taste. So then we'd have:
stdout("wyda"); // no newline
stdout("wyda\n"); // newline but no flushing on binary stream
stdout("wyda", newline); // write'n'flush
stdout.writeln("wyda"); // same
If we go that route I'll even drop writeln and rely on passing
newline. For formatting there'd be stdout.format and stdout.formatln
or something.
This is funny because Tango has adopted exactly the same design.
Well it isn't funny. It's obvious: you just told me about it! :o)
The only difference is that Stdout is written in upper case:
import tango.io.Stdout;
void main() {
Stdout("Hello, World\n"); // no flushing
Stdout("Hello, World").newline; // new line appended, flushs
Stdout.format("Hello, {}!", "Andrei").newline; // formatting
Stdout.formatln("Hello, {}!", "Kris");
}
It would be great if the two libraries share the same interface.
Ionno. In Phobos, types are Capitalized, values are camelCase or
justminuscules.
BTW, since you are in process of redesigning of Phobos IO/stream
system, it would be great if you take a look at the Tango IO system,
first. I recall you telling that you didn't give a good look at Tango,
so now is the time. I particularly insist on talking to Kris about it;
perhaps, he has some ideas on the topic. He may also share experience
with you (errors he made etc). I'll give you a few ideas of mine in a
separate post.
I don't know about licensing issues, and last thing I need would be to
be accused of stealing from Tango.
You shouldn't avoid looking on someone's code, especially if it may
help D get better standard library. There's nothing wrong with
borrowing ideas from others, too, especially if they give you a
permission for that. Tango is dual-licensed under Academic Free
License v3.0 and BSD License, so there might not be a need to, but
anyway.
I have zero knowledge of licensing stuff, but I understand Walter does.
He's not looking at Tango so nor should I. I'm sure it has some cool
ideas, but so do other libraries.
You know, this is just counter-productive. There are several people -
all of them very valuable members of the D community, with countless
contributions - who have put forth a library with its goals being mainly
the success of D and especially a vital, alive development process. This
library is available licensed under BSD, which basically means you can
do whatever you please with it, as long as you don’t remove the
copyright of the original authors.
Now, what you’re doing is despite the fact that the Tango sources are
completely free and available to you, deny any kind of insight you might
be able to gather in there. Why? If you’re responsible for the standard
library and you *do* take ideas from Tango and integrate them into the
official standard library, you’re doing every Tango dev a big favour.
Because, you know, that’s why there is Tango. You didn’t forget that,
did you?
No offense intended, of course. I just think you should really
reconsider your decision to not look at Tango, based on facts. Not based
on “I might step on someone’s toes because of I don’t know why.”
Kind regards,
Alex
PS: Pretty please, don’t get me wrong, I really appreciate your
contributions to D! :)
Re: eliminate writeln et comp?
Ruby handles this by putting such functions on its IO class as instance methods, and then defining global functions that are just aliases to more verbosely calling instance methods on global IO objects. For instance, puts is just an alias to $stdout.puts, gets is just an alias to $stdin.gets, etc. That way, people who want to type as little as possible to write Hello World programs are happy, and people who want a consistent object-oriented syntax and the benefits of polymorphism are also happy. Everyone is happy!
Re: eliminate writeln et comp?
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it would
be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
On one hand, I agree with Walter. On the other, I want to avoid the
phenomenon of the all-too-long "Hello, world" example.
What do you think?
Andrei
I have always thought of writefln as the flagship function of Phobos.
It's now looking as though the connection between Phobos2 and Phobos1 is
not really any stronger than between Tango1 and Phobos1.
(This is an observation, not intended to be critical in any way).
Re: eliminate writeln et comp?
On 2009-03-17 20:26:16 -0400, Andrei Alexandrescu
said:
Interesting. Should I do the same in phobos?
stdout("wyda");
I'd like that particularly because write() is too common a name to
place at namespace level for my taste. So then we'd have:
stdout("wyda"); // no newline
stdout("wyda\n"); // newline but no flushing on binary stream
stdout("wyda", newline); // write'n'flush
stdout.writeln("wyda"); // same
If we go that route I'll even drop writeln and rely on passing newline.
For formatting there'd be stdout.format and stdout.formatln or
something.
Seems nice. Can this work symmetrically for stdin?
int i;
stdin(i); // reads an integer and place it in i.
That would make things interesting, as with some streams you could use
the same code to serialize and unserialize a data structures.
stream(x, y, z); // either write or read the values depending on the
stream.
This reminds me of boost serialization which use a similar trick
allowing you to have a single function template to both serialize and
unserialize a given data type.
But that probably couldn't work with the standard text stream types.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: eliminate writeln et comp?
On Wed, Mar 18, 2009 at 12:24 PM, Jason House
wrote:
> Andrei Alexandrescu Wrote:
>
>> Hey all y'all,
>>
>>
>> Here's another nice bicycle shed discussion. During the recent
>> discussion about globals being harmful, Walter told me something that
>> made me think. I said, hey, there are things that are global - look at
>> stdout. He said, well, that's a bad thing. He then argued that it would
>> be better and cleaner to write:
>>
>> stdout.writeln("Hello, world");
>>
>> instead of the current:
>>
>> writeln("Hello, world");
>>
>> On one hand, I agree with Walter. On the other, I want to avoid the
>> phenomenon of the all-too-long "Hello, world" example.
>>
>> What do you think?
>>
>>
>> Andrei
>
> A lot of people have enjoyed the simplicity of using Phobos and it'd be a
> shame to ruin that. writeln is extremely common, especially with gdb support
> broken ;)
I think if you're going to change it at all it should be made shorter,
not longer.
And for heaven's sake, don't remove the version of the function that
automatically appends a newline! I always forget to put the dang \n
at the end of all my printfs in C, so from the very beginning I though
writefln was a godsend for that one thing alone.
--bb
Re: eliminate writeln et comp?
Andrei Alexandrescu Wrote:
> Hey all y'all,
>
>
> Here's another nice bicycle shed discussion. During the recent
> discussion about globals being harmful, Walter told me something that
> made me think. I said, hey, there are things that are global - look at
> stdout. He said, well, that's a bad thing. He then argued that it would
> be better and cleaner to write:
>
> stdout.writeln("Hello, world");
>
> instead of the current:
>
> writeln("Hello, world");
>
> On one hand, I agree with Walter. On the other, I want to avoid the
> phenomenon of the all-too-long "Hello, world" example.
>
> What do you think?
>
>
> Andrei
A lot of people have enjoyed the simplicity of using Phobos and it'd be a shame
to ruin that. writeln is extremely common, especially with gdb support broken
;)
Re: eliminate writeln et comp?
Denis Koroskin wrote:
On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
That's not a very frequent operation. In most cases you should use
Cout("Hello"); instead. An ideal design solution, imo (fast, short
and clear).
Interesting. Should I do the same in phobos?
stdout("wyda");
I'd like that particularly because write() is too common a name to
place at namespace level for my taste. So then we'd have:
stdout("wyda"); // no newline
stdout("wyda\n"); // newline but no flushing on binary stream
stdout("wyda", newline); // write'n'flush
stdout.writeln("wyda"); // same
If we go that route I'll even drop writeln and rely on passing
newline. For formatting there'd be stdout.format and stdout.formatln
or something.
This is funny because Tango has adopted exactly the same design.
Well it isn't funny. It's obvious: you just told me about it! :o)
The only difference is that Stdout is written in upper case:
import tango.io.Stdout;
void main() {
Stdout("Hello, World\n"); // no flushing
Stdout("Hello, World").newline; // new line appended, flushs
Stdout.format("Hello, {}!", "Andrei").newline; // formatting
Stdout.formatln("Hello, {}!", "Kris");
}
It would be great if the two libraries share the same interface.
Ionno. In Phobos, types are Capitalized, values are camelCase or
justminuscules.
BTW, since you are in process of redesigning of Phobos IO/stream system,
it would be great if you take a look at the Tango IO system, first. I
recall you telling that you didn't give a good look at Tango, so now is
the time. I particularly insist on talking to Kris about it; perhaps, he
has some ideas on the topic. He may also share experience with you
(errors he made etc). I'll give you a few ideas of mine in a separate post.
I don't know about licensing issues, and last thing I need would be to
be accused of stealing from Tango.
You shouldn't avoid looking on someone's code, especially if it may help
D get better standard library. There's nothing wrong with borrowing
ideas from others, too, especially if they give you a permission for
that. Tango is dual-licensed under Academic Free License v3.0 and BSD
License, so there might not be a need to, but anyway.
I have zero knowledge of licensing stuff, but I understand Walter does.
He's not looking at Tango so nor should I. I'm sure it has some cool
ideas, but so do other libraries.
Andrei
Re: eliminate writeln et comp?
Andrei Alexandrescu:
> Interesting. Should I do the same in phobos?
> stdout("wyda");
Generally I suggest to put a short & easy way useful for most situations, plus
something more complex (and generally with a more complex syntax) for the
special situations. For the general basic printing I like put()/putr() (r = add
a final newline).
Bye,
bearophile
Re: eliminate writeln et comp?
On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
That's not a very frequent operation. In most cases you should use
Cout("Hello"); instead. An ideal design solution, imo (fast, short and
clear).
Interesting. Should I do the same in phobos?
stdout("wyda");
I'd like that particularly because write() is too common a name to place
at namespace level for my taste. So then we'd have:
stdout("wyda"); // no newline
stdout("wyda\n"); // newline but no flushing on binary stream
stdout("wyda", newline); // write'n'flush
stdout.writeln("wyda"); // same
If we go that route I'll even drop writeln and rely on passing newline.
For formatting there'd be stdout.format and stdout.formatln or something.
This is funny because Tango has adopted exactly the same design.
The only difference is that Stdout is written in upper case:
import tango.io.Stdout;
void main() {
Stdout("Hello, World\n"); // no flushing
Stdout("Hello, World").newline; // new line appended, flushs
Stdout.format("Hello, {}!", "Andrei").newline; // formatting
Stdout.formatln("Hello, {}!", "Kris");
}
It would be great if the two libraries share the same interface.
BTW, since you are in process of redesigning of Phobos IO/stream system, it
would be great if you take a look at the Tango IO system, first. I recall you
telling that you didn't give a good look at Tango, so now is the time. I
particularly insist on talking to Kris about it; perhaps, he has some ideas on
the topic. He may also share experience with you (errors he made etc). I'll
give you a few ideas of mine in a separate post.
You shouldn't avoid looking on someone's code, especially if it may help D get
better standard library. There's nothing wrong with borrowing ideas from
others, too, especially if they give you a permission for that. Tango is
dual-licensed under Academic Free License v3.0 and BSD License, so there might
not be a need to, but anyway.
Back on topic, in most cases I use:
debug writefln("hello");
because I have no console in release version (and it throws when there
is no stdout, look in the bugzilla for a bug report). It is already
long enough, so I wouldn't like it to be even longer:
debug stdio.writefln("hello");
My 0.02 rubles.
Got them.
Andrei
Re: eliminate writeln et comp?
Denis Koroskin wrote:
That's not a very frequent operation. In most cases you should use
Cout("Hello"); instead. An ideal design solution, imo (fast, short and
clear).
Interesting. Should I do the same in phobos?
stdout("wyda");
I'd like that particularly because write() is too common a name to place
at namespace level for my taste. So then we'd have:
stdout("wyda"); // no newline
stdout("wyda\n"); // newline but no flushing on binary stream
stdout("wyda", newline); // write'n'flush
stdout.writeln("wyda"); // same
If we go that route I'll even drop writeln and rely on passing newline.
For formatting there'd be stdout.format and stdout.formatln or something.
Back on topic, in most cases I use:
debug writefln("hello");
because I have no console in release version (and it throws when there
is no stdout, look in the bugzilla for a bug report). It is already long
enough, so I wouldn't like it to be even longer:
debug stdio.writefln("hello");
My 0.02 rubles.
Got them.
Andrei
Re: eliminate writeln et comp?
On Tue, Mar 17, 2009 at 4:58 PM, Andrei Alexandrescu wrote: > > (Not in the upcoming Phobos.) > It's a little difficult to have a style discussion with you about Phobos when you're envisioning an entirely different library than what we have now ;)
Re: eliminate writeln et comp?
On Tue, 17 Mar 2009 19:46:37 +0300, Nick Sabalausky wrote:
"Adam D. Ruppe" wrote in message
news:mailman.967.1237304767.22690.digitalmar...@puremagic.com...
On Tue, Mar 17, 2009 at 08:35:35AM -0700, Andrei Alexandrescu wrote:
What do you think?
Eeek. That's too much typing for a trivial, common operation.
I wouldn't mind writefln being implemented as a macro that is turned to
fwritefln(stdout, ...)
But, I'd be fairly annoyed having to write the extra seven characters
each
time if the short version wasn't there.
That's how tango and C# do it.
Stdout.formatln("Hello"); // Tango
Console.WriteLine("Hello"); // C#
My preference has always been for something shorter, but the current
tango/C# ways have never really bothered me. You get used to it pretty
quick.
That's not a very frequent operation. In most cases you should use
Cout("Hello"); instead. An ideal design solution, imo (fast, short and clear).
Back on topic, in most cases I use:
debug writefln("hello");
because I have no console in release version (and it throws when there is no
stdout, look in the bugzilla for a bug report). It is already long enough, so I
wouldn't like it to be even longer:
debug stdio.writefln("hello");
My 0.02 rubles.
Re: eliminate writeln et comp?
Andrei Alexandrescu wrote:
Georg Wrede wrote:
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look
at stdout. He said, well, that's a bad thing. He then argued that it
would be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
On one hand, I agree with Walter. On the other, I want to avoid the
phenomenon of the all-too-long "Hello, world" example.
What do you think?
1. It is not often that a program that is first designed to write to
stdout is changed to write to somewhere else. (The whole reason of
stdout is, after all, that you can redirect outside the program!)
2. Of course it would be Proper (as in Prudent, almost as in goody
two-shoes) to write stdout.writeln. But then, to be useful the
programmer should write myOutDestination.writeln in order to be able
to "conveniently" later change the destination.
3. IMHO later redefining stdout would be a moronic idea. (And
/definitely/ not Prudent!)
4. Globals, shmobals... globals in spirit vs. globals in techicality.
I can't /believe/ there's any idea in totally banning globals. Heck,
this language has *goto*. Blind purism has made a few other languages
impractical.
5. Good defaults a good UI make. Can't we just decide that a bare
writeln(...) is defined as writing to stdout, period? Without thinking
of globals.
6. stdout is "global" to such an extent, that it actually exists
outside of the program. (RTF *nix man, man!)
Blehhh
PS, I don't think you were serious with the post.
I was, serious and especially curious. I'm with you on all of the above.
:-)
Re: eliminate writeln et comp?
Georg Wrede wrote:
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it
would be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
On one hand, I agree with Walter. On the other, I want to avoid the
phenomenon of the all-too-long "Hello, world" example.
What do you think?
1. It is not often that a program that is first designed to write to
stdout is changed to write to somewhere else. (The whole reason of
stdout is, after all, that you can redirect outside the program!)
2. Of course it would be Proper (as in Prudent, almost as in goody
two-shoes) to write stdout.writeln. But then, to be useful the
programmer should write myOutDestination.writeln in order to be able to
"conveniently" later change the destination.
3. IMHO later redefining stdout would be a moronic idea. (And
/definitely/ not Prudent!)
4. Globals, shmobals... globals in spirit vs. globals in techicality. I
can't /believe/ there's any idea in totally banning globals. Heck, this
language has *goto*. Blind purism has made a few other languages
impractical.
5. Good defaults a good UI make. Can't we just decide that a bare
writeln(...) is defined as writing to stdout, period? Without thinking
of globals.
6. stdout is "global" to such an extent, that it actually exists outside
of the program. (RTF *nix man, man!)
Blehhh
PS, I don't think you were serious with the post.
I was, serious and especially curious. I'm with you on all of the above.
Andrei
Re: eliminate writeln et comp?
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Ary Borenszweig wrote:
> > Andrei Alexandrescu wrote:
> >> Hey all y'all,
> >>
> >>
> >> Here's another nice bicycle shed discussion. During the recent
> >> discussion about globals being harmful, Walter told me something that
> >> made me think. I said, hey, there are things that are global - look at
> >> stdout. He said, well, that's a bad thing. He then argued that it
> >> would be better and cleaner to write:
> >>
> >> stdout.writeln("Hello, world");
> >>
> >> instead of the current:
> >>
> >> writeln("Hello, world");
> >>
> >> On one hand, I agree with Walter. On the other, I want to avoid the
> >> phenomenon of the all-too-long "Hello, world" example.
> >>
> >> What do you think?
> >
> > There must be something I'm missing here. Either writeln is using a
> > global "stdout" which you can't see in it's interface, or you are using
> > that global "stdout" yourself and invoking writeln on it. There's still
> > a global around. Nothing solved.
> The difference is that in the current call the use of the global is
> implicit.
Once D will accept both syntaxes for methods, it will be up to the user.
void fn( t1 p1, t2, p2 );
fn( v1, v2 ); <-> v1.fn( v2 );
Re: eliminate writeln et comp?
Jarrett Billingsley wrote:
On Tue, Mar 17, 2009 at 11:35 AM, Andrei Alexandrescu
wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent discussion
about globals being harmful, Walter told me something that made me think. I
said, hey, there are things that are global - look at stdout. He said, well,
that's a bad thing. He then argued that it would be better and cleaner to
write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
On one hand, I agree with Walter. On the other, I want to avoid the
phenomenon of the all-too-long "Hello, world" example.
What do you think?
Keep writefln. You're only going to be using it when (1) you're doing
debugging, when you want it short, and (2) you're writing a simple
console program. There's always dout.writefln when you need more
power.
Is dout in the std.stream thing? That entire framework is due for
retirement.
Andrei
Re: eliminate writeln et comp?
Max Samukha wrote:
On Tue, 17 Mar 2009 08:56:58 -0700, Sean Kelly
wrote:
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it would
be better and cleaner to write:
stdout.writeln("Hello, world");
But then stdout is still global :-) However, I do think an "fwritef"
routine would be good to have--I tend to write to stderr as often as stdout.
writef recognizes if its first parameter is a stream. you can already
use writef(stderr, ...)
(Not in the upcoming Phobos.)
Andrei
Re: eliminate writeln et comp?
Sean Kelly wrote:
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it
would be better and cleaner to write:
stdout.writeln("Hello, world");
But then stdout is still global :-) However, I do think an "fwritef"
routine would be good to have--I tend to write to stderr as often as
stdout.
Yah, there is in the elusive new Phobos which I still can't release due
to compiler bugs:
auto f = File("foo.txt", "w");
f.writef("%s", 42);
Andrei
Re: eliminate writeln et comp?
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it
would be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
On one hand, I agree with Walter. On the other, I want to avoid the
phenomenon of the all-too-long "Hello, world" example.
What do you think?
There must be something I'm missing here. Either writeln is using a
global "stdout" which you can't see in it's interface, or you are using
that global "stdout" yourself and invoking writeln on it. There's still
a global around. Nothing solved.
The difference is that in the current call the use of the global is
implicit.
Andrei
Re: eliminate writeln et comp?
Andrei Alexandrescu wrote:
...
I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it would
be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
int x;
I suggest we forbid int totally. It is too [insert something here], and
it is ambiguous, strictly speaking.
So forbid it, and force the programmer to explicitly specify signed or
unsigned, every single time. It would be better and cleaner.
Re: eliminate writeln et comp?
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it would
be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
On one hand, I agree with Walter. On the other, I want to avoid the
phenomenon of the all-too-long "Hello, world" example.
What do you think?
1. It is not often that a program that is first designed to write to
stdout is changed to write to somewhere else. (The whole reason of
stdout is, after all, that you can redirect outside the program!)
2. Of course it would be Proper (as in Prudent, almost as in goody
two-shoes) to write stdout.writeln. But then, to be useful the
programmer should write myOutDestination.writeln in order to be able to
"conveniently" later change the destination.
3. IMHO later redefining stdout would be a moronic idea. (And
/definitely/ not Prudent!)
4. Globals, shmobals... globals in spirit vs. globals in techicality. I
can't /believe/ there's any idea in totally banning globals. Heck, this
language has *goto*. Blind purism has made a few other languages
impractical.
5. Good defaults a good UI make. Can't we just decide that a bare
writeln(...) is defined as writing to stdout, period? Without thinking
of globals.
6. stdout is "global" to such an extent, that it actually exists outside
of the program. (RTF *nix man, man!)
Blehhh
PS, I don't think you were serious with the post.
Re: eliminate writeln et comp?
Anders F Björklund wrote:
Andrei Alexandrescu wrote:
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it
would be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
I thought the current was printf :-)
Looking at dmd/samples/d/hello.d
LOL
Re: eliminate writeln et comp?
Andrei Alexandrescu wrote:
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it would
be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
I thought the current was printf :-)
Looking at dmd/samples/d/hello.d
--anders
Re: eliminate writeln et comp?
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Hey all y'all,
> Here's another nice bicycle shed discussion. During the recent
> discussion about globals being harmful, Walter told me something that
> made me think. I said, hey, there are things that are global - look at
> stdout. He said, well, that's a bad thing. He then argued that it would
> be better and cleaner to write:
> stdout.writeln("Hello, world");
> instead of the current:
> writeln("Hello, world");
> On one hand, I agree with Walter. On the other, I want to avoid the
> phenomenon of the all-too-long "Hello, world" example.
> What do you think?
> Andrei
To me, the current form is best because it doesn't force you to explicitly
specify
that you want to write to stdout. Thus, it makes simple things simple. Of
course
DWIM isn't always a good idea, but when an obvious, safe default exists, I
prefer
not to have to explicitly specify this kind of stuff unless I want to override
the
default.
Also, I don't see globals as being all that evil in themselves. Global
_mutable_
state is an absolute mortal sin, but I see absolutely nothing wrong with global
variables that are immutable, or even set once and treated as read-only by
convention after initialization.
Re: eliminate writeln et comp?
On Tue, 17 Mar 2009 08:56:58 -0700, Sean Kelly
wrote:
>Andrei Alexandrescu wrote:
>> Hey all y'all,
>>
>>
>> Here's another nice bicycle shed discussion. During the recent
>> discussion about globals being harmful, Walter told me something that
>> made me think. I said, hey, there are things that are global - look at
>> stdout. He said, well, that's a bad thing. He then argued that it would
>> be better and cleaner to write:
>>
>> stdout.writeln("Hello, world");
>
>But then stdout is still global :-) However, I do think an "fwritef"
>routine would be good to have--I tend to write to stderr as often as stdout.
writef recognizes if its first parameter is a stream. you can already
use writef(stderr, ...)
Re: eliminate writeln et comp?
"Adam D. Ruppe" wrote in message
news:mailman.967.1237304767.22690.digitalmar...@puremagic.com...
> On Tue, Mar 17, 2009 at 08:35:35AM -0700, Andrei Alexandrescu wrote:
>> What do you think?
>
> Eeek. That's too much typing for a trivial, common operation.
>
> I wouldn't mind writefln being implemented as a macro that is turned to
> fwritefln(stdout, ...)
>
> But, I'd be fairly annoyed having to write the extra seven characters each
> time if the short version wasn't there.
>
That's how tango and C# do it.
Stdout.formatln("Hello"); // Tango
Console.WriteLine("Hello"); // C#
My preference has always been for something shorter, but the current
tango/C# ways have never really bothered me. You get used to it pretty
quick.
Re: eliminate writeln et comp?
On Tue, Mar 17, 2009 at 11:35 AM, Andrei Alexandrescu
wrote:
> Hey all y'all,
>
>
> Here's another nice bicycle shed discussion. During the recent discussion
> about globals being harmful, Walter told me something that made me think. I
> said, hey, there are things that are global - look at stdout. He said, well,
> that's a bad thing. He then argued that it would be better and cleaner to
> write:
>
> stdout.writeln("Hello, world");
>
> instead of the current:
>
> writeln("Hello, world");
>
> On one hand, I agree with Walter. On the other, I want to avoid the
> phenomenon of the all-too-long "Hello, world" example.
>
> What do you think?
Keep writefln. You're only going to be using it when (1) you're doing
debugging, when you want it short, and (2) you're writing a simple
console program. There's always dout.writefln when you need more
power.
Re: eliminate writeln et comp?
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it would
be better and cleaner to write:
stdout.writeln("Hello, world");
But then stdout is still global :-) However, I do think an "fwritef"
routine would be good to have--I tend to write to stderr as often as stdout.
Re: eliminate writeln et comp?
Andrei Alexandrescu wrote:
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it would
be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
On one hand, I agree with Walter. On the other, I want to avoid the
phenomenon of the all-too-long "Hello, world" example.
What do you think?
There must be something I'm missing here. Either writeln is using a
global "stdout" which you can't see in it's interface, or you are using
that global "stdout" yourself and invoking writeln on it. There's still
a global around. Nothing solved.
Re: eliminate writeln et comp?
On Tue, Mar 17, 2009 at 08:35:35AM -0700, Andrei Alexandrescu wrote: > What do you think? Eeek. That's too much typing for a trivial, common operation. I wouldn't mind writefln being implemented as a macro that is turned to fwritefln(stdout, ...) But, I'd be fairly annoyed having to write the extra seven characters each time if the short version wasn't there. > Andrei -- Adam D. Ruppe http://arsdnet.net
eliminate writeln et comp?
Hey all y'all,
Here's another nice bicycle shed discussion. During the recent
discussion about globals being harmful, Walter told me something that
made me think. I said, hey, there are things that are global - look at
stdout. He said, well, that's a bad thing. He then argued that it would
be better and cleaner to write:
stdout.writeln("Hello, world");
instead of the current:
writeln("Hello, world");
On one hand, I agree with Walter. On the other, I want to avoid the
phenomenon of the all-too-long "Hello, world" example.
What do you think?
Andrei
