www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - eliminate writeln et comp?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 17 2009
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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
Mar 17 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.967.1237304767.22690.digitalmars-d 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.
Mar 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 17 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Mar 17 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> 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
Mar 17 2009
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> 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! :)
Mar 19 2009
parent reply Don <nospam nospam.com> writes:
Adam D. Ruppe wrote:
 On Thu, Mar 19, 2009 at 11:47:37AM +0100, Alexander Pnek 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.

Mar 19 2009
next sibling parent reply Don <nospam nospam.com> writes:
Robert Jacques wrote:
 On Thu, 19 Mar 2009 09:23:44 -0400, Don <nospam nospam.com> 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)

Mar 20 2009
parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-03-20 13:28:06 +0100, Don <nospam nospam.com> said:

 Robert Jacques wrote:
 On Thu, 19 Mar 2009 09:23:44 -0400, Don <nospam nospam.com> 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.
Mar 20 2009
prev sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-03-20 05:46:08 +0100, "Robert Jacques" <sandford jhu.edu> said:

 On Thu, 19 Mar 2009 09:23:44 -0400, Don <nospam nospam.com> 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)

Mar 20 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
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
Mar 20 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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.
Mar 20 2009
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Mar 20 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Mar 21 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
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."

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.
Mar 21 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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."

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
Mar 21 2009
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Mar 21 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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.
Mar 21 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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 :-) ).
Mar 22 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 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!
Mar 22 2009
parent Don <nospam nospam.com> writes:
dsimcha wrote:
 == Quote from Walter Bright (newshound1 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.
Mar 23 2009
prev sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-03-21 14:23:51 +0100, Daniel Keep <daniel.keep.lists gmail.com> 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."

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
Mar 21 2009
next sibling parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-03-21 20:19:15 +0100, Fawzi Mohamed <fmohamed mac.com> said:

 On 2009-03-21 14:23:51 +0100, Daniel Keep <daniel.keep.lists gmail.com> 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."

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
Mar 21 2009
prev sibling parent Don <nospam nospam.com> writes:
Fawzi Mohamed wrote:
 On 2009-03-21 14:23:51 +0100, Daniel Keep <daniel.keep.lists gmail.com> 
 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."

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
 

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.
Mar 22 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Mar 23, 2009 at 5:02 AM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Walter Bright (newshound1 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
Mar 22 2009
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-03-17 20:26:16 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> 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.fortin michelf.com http://michelf.com/
Mar 17 2009
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Mar 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 17 2009
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail 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.

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 );
Mar 17 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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.
Mar 17 2009
next sibling parent reply Max Samukha <samukha voliacable.com.removethis> writes:
On Tue, 17 Mar 2009 08:56:58 -0700, Sean Kelly
<sean invisibleduck.org> 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, ...)
Mar 17 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Max Samukha wrote:
 On Tue, 17 Mar 2009 08:56:58 -0700, Sean Kelly
 <sean invisibleduck.org> 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");

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
Mar 17 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 17 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Mar 17, 2009 at 4:58 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> 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 ;)
Mar 17 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Mar 17, 2009 at 11:35 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> 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.
Mar 17 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Tue, Mar 17, 2009 at 11:35 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> 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
Mar 17 2009
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail 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.
Mar 17 2009
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Mar 17 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Anders F Bjrklund 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
Mar 17 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
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!) Blehhhhhhh.... PS, I don't think you were serious with the post.
Mar 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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!) Blehhhhhhh.... 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
Mar 17 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
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!) Blehhhhhhh.... 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.

:-)
Mar 17 2009
prev sibling next sibling parent Georg Wrede <georg.wrede iki.fi> writes:
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.
Mar 17 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 17 Mar 2009 19:46:37 +0300, Nick Sabalausky <a a.a> wrote:

 "Adam D. Ruppe" <destructionator gmail.com> wrote in message
 news:mailman.967.1237304767.22690.digitalmars-d 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.
Mar 17 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 18 Mar 2009 03:26:16 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> 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

Mar 17 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
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 ;)
Mar 17 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Mar 18, 2009 at 12:24 PM, Jason House
<jason.james.house gmail.com> 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=

pport 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
Mar 17 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
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).
Mar 18 2009
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Mar 19, 2009 at 11:47:37AM +0100, Alexander Pnek 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
Mar 19 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 19 Mar 2009 09:23:44 -0400, Don <nospam nospam.com> 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)
Mar 19 2009
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 20 Mar 2009 08:28:06 -0400, Don <nospam nospam.com> 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.
Mar 20 2009