Re: [OT] Quality of software localization
Walter Bright Wrote: Tomek Sowiñski wrote: Oh, and if the problem called for a turbo spreadsheet, I had to re-learn the function names all over because in VBA they're English. :-/ Yes, localized Excel is a real pain. My father spent years in Japan after the war, and of course Japanese words would creep into his vocabulary. So I grew up thinking a lot of Japanese words were english g. Japanese did assimilate many english words. Every time I hear it - what they say? - it's unnatural.
Re: [Slight OT] TDPL in Russia
Steven Schveighoffer Wrote: This is all based on your opinion. And unfortunately it's all wrong -- I know what is good and what is bad, you should just stop posting. We both know, what is good, so we both should stop posting.
Re: Bug 3999 and 4261
bearophile Wrote: But enums are not integers ?? Where did you get it?
Reporting TDPL bugs in Bugzilla
To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. Also note that all new bugs should have version marked as D1, D2 or D1D2, depending on where the bug has been observed. The long list of specific compiler versions should be ignored, it has always been completely useless.
Re: Bug 3999 and 4261
On 8/31/2010 19:46, bearophile wrote: But you can use const for constants that are known at run-time only. While you can't use enum for constant known at run-time. In C++, const is used for both run-time and compile-time constants. In practice, this works out fine. It its value can only be known at run-time, it's a run-time constant. If its value is used at compile-time, it's a compile-time constant. If both of these apply, it's an error. If neither applies, nobody cares if it's a compile-time or run-time constant. (The actual rules in C++ are a bit more complex, less intuitive, and less useful than that, which is presumably why Walter chose not to copy the C++ in this case. Still, overloading 'const' for both compile-time and run-time constants is viable, and more intuitive than the current situation with 'enum'.) -- Rainer Deyke - rain...@eldwood.com
Re: Bug 3999 and 4261
Rainer Deyke wrote: On 8/31/2010 19:46, bearophile wrote: But you can use const for constants that are known at run-time only. While you can't use enum for constant known at run-time. In C++, const is used for both run-time and compile-time constants. In practice, this works out fine. It its value can only be known at run-time, it's a run-time constant. If its value is used at compile-time, it's a compile-time constant. If both of these apply, it's an error. If neither applies, nobody cares if it's a compile-time or run-time constant. (The actual rules in C++ are a bit more complex, less intuitive, and less useful than that, which is presumably why Walter chose not to copy the C++ in this case. Still, overloading 'const' for both compile-time and run-time constants is viable, and more intuitive than the current situation with 'enum'.) The enum situation exists ONLY because of linker limitations. It seems most people still don't understand that.
Re: Bug 3999 and 4261
Kagamin: But enums are not integers ?? Where did you get it? The whole point of this discussion about my enhancement request 3999 is to turn a certain subset of enums into not integers (or not bytes, not longs, etc). Bye, bearophile
Re: D.challenge
On 28/08/10 06:45, Andrej Mitrovic wrote: I like this idea. I don't know about showing off superiority of D, but it would be a good way to learn from each other. E.g. one could submit a solution to a challenge, and then others can refine it to be safer/faster/better in some regards if they want to, while others present their solutions that take a different approach. Yes, well, of course I meant to enquote 'superiority' as you rightly did. Naturally superiority of any PL is dependent upon, or subjective within, the application domain which a PL purports itself to excel in (over and above other PLs which compete in the same application domain). To set the record straight, may it now be asked (without prejudice :-)) that we qualify what application domain(s) D purports to excel in? Cheers Justin Johansson
Re: std.mixins
TDPL says it should work for any type. http://d.puremagic.com/issues/show_bug.cgi?id=3382 2010/9/1 Nick Sabalausky a...@a.a: dsimcha dsim...@yahoo.com wrote in message news:i5jtdn$1g4...@digitalmars.com... Isn't this a core language feature that's in the spec but is only currently implemented for arrays? I thought eventually uniform function call syntax was coming for classes and structs, too. I've been really wishing for a long time that would actually happen. It's annoying enough not to be able to do it for most types, but then the fact that it's special-cased at all is a bit of a bizarre inconsistency.
Re: [Slight OT] TDPL in Russia
On Wed, 01 Sep 2010 02:59:42 -0400, Kagamin s...@here.lot wrote: Steven Schveighoffer Wrote: This is all based on your opinion. And unfortunately it's all wrong -- I know what is good and what is bad, you should just stop posting. We both know, what is good, so we both should stop posting. I was just employing irony and sarcasm to demonstrate why your arguments were meaningless :) The only measurable factor for good art is how many people use it/buy it. For-sale software, books, movies do rather well, so I'm inclined to believe they are pretty good. There are also some open source/free materials that do rather well, but they are not nearly as common as free materials that are crappy. My point was that for-sale art by far outperforms freely available art in popularity and usage. When you get paid to make something, you can do it more often, you get better at it, and your quality of work goes up. Anyways, we can stop debating, clearly it's not going anywhere. -Steve
[D.typesystem] Static (CT) enforce anybody?
IIRC std.contracts has been deprecated and replaced by std.exception, enforce and friends. The latter are runtime things, correct(?). Is there a valid use case for compile-time (i.e. subject to static analysis) design-by-contract (DBC) enforce-like machinery? For example, and perhaps not the best example, one might like to pass an array of Foos to a function which by static design expects to receive such array at runtime as containing a minimum and/or maximum of elements. Should (i.e. could it be desirable that) such interface contracts be checkable at compile-time? Cheers Justin Johansson
Re: [D.typesystem] Static (CT) enforce anybody?
On Wed, 01 Sep 2010 09:03:39 -0400, Justin Johansson n...@spam.com wrote:
IIRC std.contracts has been deprecated and replaced by std.exception,
enforce and friends. The latter are runtime things, correct(?).
Is there a valid use case for compile-time (i.e. subject to static
analysis) design-by-contract (DBC) enforce-like machinery?
For example, and perhaps not the best example, one might like to pass
an array of Foos to a function which by static design expects to
receive such array at runtime as containing a minimum and/or maximum of
elements. Should (i.e. could it be desirable that) such interface
contracts be checkable at compile-time?
Compile time checks are only available for compile time values. If you
have a function like this:
void foo(int[] x)
There is no way at compile time to check whether x has a maximum or
minimum number of elements. But if you have something like this:
void foo(uint N)(ref int[N] x)
Then you can check N, because it is a compile-time value. you can make
checks via template constraints or static assert statements:
void foo(uint N)(ref int[N] x) if(N = minvalue)
- or -
void foo(uint N)(ref int[N] x)
{
static assert(N = minvalue, Error, invalid sized array passed to
foo);
}
Both of these will fail to compile if you pass incorrect data.
-Steve
Re: std.mixins
Philippe Sigaud philippe.sig...@gmail.com wrote: I also have a template that gets the list of all members of an aggregate type (classes, structs and, well, modules, in a way), even the constructors, even the overloaded members, separated by type, and list them with their names and associated type. It even gets the types aliases and unittests, though I don't know what to do with the latter. That was part of a project to duplicate a type: generate a new type with this extracted info. I had vague projects to transform the methods into their const equivalent for example or to render the fields immutable, but didn't get that far. Would that be interesting to someone? I could imagine extracting the unittests could be useful for making a unittest system. Are they only included when passing -unittest? -- Simen
[D.typesystem] Suggestion for improving OO inheritance models
Whilst one admirable aspiration of D is to make for better meta-programming capability in a PL, IMHO one seemingly-lacking aspiration of D is in the area of improving OO inheritance models over and above that provisioned for in C++ and Java. Maybe I'm ill-informed though I'd say that D, C++ and Java more-or-less share the same OO inheritance model being that of inheritance/derivation by extension as opposed to, say, inheritance/derivation by restriction. (Observation: Java even uses the 'extends' keyword to introduce derived classes; this hardly caters for inheritance by restriction). May I suggest that a discussion ensure about a taxonomy of OO inheritance models, including the notions of inheritance by extension, restriction, code refactoring purposes etc. so that D can evolve to a position to be able to claim a higher moral plane over C++, Java, et al. Cheers Justin Johansson
Re: [D.typesystem] Static (CT) enforce anybody?
On 01/09/10 22:49, Steven Schveighoffer wrote:
Compile time checks are only available for compile time values. If you
have a function like this:
void foo(int[] x)
There is no way at compile time to check whether x has a maximum or
minimum number of elements. But if you have something like this:
void foo(uint N)(ref int[N] x)
Then you can check N, because it is a compile-time value. you can make
checks via template constraints or static assert statements:
void foo(uint N)(ref int[N] x) if(N = minvalue)
- or -
void foo(uint N)(ref int[N] x)
{
static assert(N = minvalue, Error, invalid sized array passed to foo);
}
Both of these will fail to compile if you pass incorrect data.
-Steve
Thanks Steve,
I'm returning to bomb bay to think about this. (See my
'Dark Star' post for interpretation)
- Justin :-)
[OT] Dark Star (1974) - the platinum age of movies
I know this is completely off topic and surely shows my age, but I wonder if anyone else on this ng has seen this movie. I couldn't remember the name of this movie but googling for movie star bomb bay I think found it for me first pop. Dark Star (1974) - Memorable quotes http://www.imdb.com/title/tt0069945/quotes The reason for mentioning this is because the next time I ask a question about D on this ng that comes back with a something for me to consider further, I'll be answering along the lines returning to bomb bay to think about this and hopefully people will understand what I mean :-) Cheers Justin Johansson
Re: Bug 3999 and 4261
Nick Sabalausky schrieb: Daniel Gibson metalcae...@gmail.com wrote in message news:i5kbpr$24t...@digitalmars.com... bearophile schrieb: Daniel Gibson: Why not use the non-fictional const keyword? The const attribute declares constants that can be evaluated at compile time.[1] But you can use const for constants that are known at run-time only. While you can't use enum for constant known at run-time. Really? Than that definition from the language docs is inaccurate. You were looking at the D1 docs. The whole const system changed in D2. http://www.digitalmars.com/d/2.0/attribute.html#const says the same.
Re: Reporting TDPL bugs in Bugzilla
To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. Thats ridiclous. The only purpose for prioriting these bugs is- you fail at compiler construction. The language is so full of shit.. why not be more honest? you had over 10 years of time to develop basic foundations but its still a amateurish attempt at language design. Tell me about another language which is so much work in progress after 10 years of development. They are all so stable. If I want I can build a 'E' language and fix all your legacy bugs. D is nowhere near perfection. The bug #1 in your bugzilla was 'just give up already'. Someone marked it wontfix.
Re: Reporting TDPL bugs in Bugzilla
== Quote from user (ad...@net.net)'s article Tell me about another language which is so much work in progress after 10 years of development. Python circa 2001? Lisp circa 1968? C++ circa 1993? C circa 1982? You're a funny, funny guy.
Re: Reporting TDPL bugs in Bugzilla
On Wed, 01 Sep 2010 10:49:46 -0500, user ad...@net.net wrote: Thats ridiclous. The only purpose for prioriting these bugs is- you fail at compiler construction. The language is so full of shit.. why not be more honest? you had over 10 years of time to develop basic foundations but its still a amateurish attempt at language design. Tell me about another language which is so much work in progress after 10 years of development. They are all so stable. If I want I can build a 'E' language and fix all your legacy bugs. D is nowhere near perfection. The bug #1 in your bugzilla was 'just give up already'. Someone marked it wontfix. Why, hello there retard! -- Yao G.
Re: [D.typesystem] Suggestion for improving OO inheritance models
Wed, 01 Sep 2010 23:16:15 +0930, Justin Johansson wrote: Whilst one admirable aspiration of D is to make for better meta-programming capability in a PL, IMHO one seemingly-lacking aspiration of D is in the area of improving OO inheritance models over and above that provisioned for in C++ and Java. Maybe I'm ill-informed though I'd say that D, C++ and Java more-or-less share the same OO inheritance model being that of inheritance/derivation by extension as opposed to, say, inheritance/derivation by restriction. (Observation: Java even uses the 'extends' keyword to introduce derived classes; this hardly caters for inheritance by restriction). May I suggest that a discussion ensure about a taxonomy of OO inheritance models, including the notions of inheritance by extension, restriction, code refactoring purposes etc. so that D can evolve to a position to be able to claim a higher moral plane over C++, Java, et al. Have you taken a loot at Scala traits already? It would be a great starting point.
Re: [OT] Dark Star (1974) - the platinum age of movies
Justin, Just remember that if you teach bombs phenomenology bad things tend to happen. On Wed, 2010-09-01 at 23:56 +0930, Justin Johansson wrote: I know this is completely off topic and surely shows my age, but I wonder if anyone else on this ng has seen this movie. I couldn't remember the name of this movie but googling for movie star bomb bay I think found it for me first pop. Dark Star (1974) - Memorable quotes http://www.imdb.com/title/tt0069945/quotes The reason for mentioning this is because the next time I ask a question about D on this ng that comes back with a something for me to consider further, I'll be answering along the lines returning to bomb bay to think about this and hopefully people will understand what I mean :-) Cheers Justin Johansson -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Reporting TDPL bugs in Bugzilla
On 9/1/10 11:12 CDT, Yao G. wrote: On Wed, 01 Sep 2010 10:49:46 -0500, user ad...@net.net wrote: Thats ridiclous. The only purpose for prioriting these bugs is- you fail at compiler construction. The language is so full of shit.. why not be more honest? you had over 10 years of time to develop basic foundations but its still a amateurish attempt at language design. Tell me about another language which is so much work in progress after 10 years of development. They are all so stable. If I want I can build a 'E' language and fix all your legacy bugs. D is nowhere near perfection. The bug #1 in your bugzilla was 'just give up already'. Someone marked it wontfix. Why, hello there retard! retard has recently made admirable efforts to write good, informative posts. Let's respond to that in kind. Thanks. Andrei
Re: [OT] Dark Star (1974) - the platinum age of movies
Justin Johansson wrote: returning to bomb bay Please remember, that leaving the bomb bay was faulty already---and may raise the question why after so many years you are still committing errors. -manfred
Re: [OT] Dark Star (1974) - the platinum age of movies
ok, Justin Bomb #20 Johansson, point taken. Great movie, beside. On 01/09/2010 16:26, Justin Johansson wrote: I know this is completely off topic and surely shows my age, but I wonder if anyone else on this ng has seen this movie. I couldn't remember the name of this movie but googling for movie star bomb bay I think found it for me first pop. Dark Star (1974) - Memorable quotes http://www.imdb.com/title/tt0069945/quotes The reason for mentioning this is because the next time I ask a question about D on this ng that comes back with a something for me to consider further, I'll be answering along the lines returning to bomb bay to think about this and hopefully people will understand what I mean :-) Cheers Justin Johansson
Re: [OT] Dark Star (1974) - the platinum age of movies
Justin Johansson n...@spam.com wrote in news:i5lnr4$1cm...@digitalmars.com: I know this is completely off topic and surely shows my age, but I wonder if anyone else on this ng has seen this movie. Perhaps of interest, a new DVD release is sceduled for late October.
Re: [OT] Dark Star (1974) - the platinum age of movies
Justin Johansson n...@spam.com wrote in message news:i5lnr4$1cm...@digitalmars.com... I know this is completely off topic and surely shows my age, but I wonder if anyone else on this ng has seen this movie. I couldn't remember the name of this movie but googling for movie star bomb bay I think found it for me first pop. Dark Star (1974) - Memorable quotes http://www.imdb.com/title/tt0069945/quotes The reason for mentioning this is because the next time I ask a question about D on this ng that comes back with a something for me to consider further, I'll be answering along the lines returning to bomb bay to think about this and hopefully people will understand what I mean :-) Never heard of it, but it sounds like something I'll have to check out :)
Re: Bug 3999 and 4261
On Wed, 01 Sep 2010 11:06:51 +0300, Rainer Deyke rain...@eldwood.com wrote: On 8/31/2010 19:46, bearophile wrote: But you can use const for constants that are known at run-time only. While you can't use enum for constant known at run-time. In C++, const is used for both run-time and compile-time constants. In practice, this works out fine. It its value can only be known at run-time, it's a run-time constant. If its value is used at compile-time, it's a compile-time constant. If both of these apply, it's an error. If neither applies, nobody cares if it's a compile-time or run-time constant. (The actual rules in C++ are a bit more complex, less intuitive, and less useful than that, which is presumably why Walter chose not to copy the C++ in this case. Still, overloading 'const' for both compile-time and run-time constants is viable, and more intuitive than the current situation with 'enum'.) I have never had troubles with C++ compile/runtime const difference, and don't think it is a problem in C++. With this in mind enum is a great keyword of choice to express compile-time types, as long as it is forbidden for run-time constants. (I hope that example of bearophile is just a bug.) Thanks. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: std.mixins
Torarin torar...@gmail.com wrote in message news:mailman.31.1283345570.858.digitalmar...@puremagic.com... 2010/9/1 Nick Sabalausky a...@a.a: dsimcha dsim...@yahoo.com wrote in message news:i5jtdn$1g4...@digitalmars.com... Isn't this a core language feature that's in the spec but is only currently implemented for arrays? I thought eventually uniform function call syntax was coming for classes and structs, too. I've been really wishing for a long time that would actually happen. It's annoying enough not to be able to do it for most types, but then the fact that it's special-cased at all is a bit of a bizarre inconsistency. TDPL says it should work for any type. http://d.puremagic.com/issues/show_bug.cgi?id=3382 /me squeals with excitement like a schoolgirl
Re: Bug 3999 and 4261
Daniel Gibson metalcae...@gmail.com wrote in message news:i5lrkr$1ij...@digitalmars.com... Nick Sabalausky schrieb: Daniel Gibson metalcae...@gmail.com wrote in message news:i5kbpr$24t...@digitalmars.com... bearophile schrieb: Daniel Gibson: Why not use the non-fictional const keyword? The const attribute declares constants that can be evaluated at compile time.[1] But you can use const for constants that are known at run-time only. While you can't use enum for constant known at run-time. Really? Than that definition from the language docs is inaccurate. You were looking at the D1 docs. The whole const system changed in D2. http://www.digitalmars.com/d/2.0/attribute.html#const says the same. Yea, that's probably wrong then. Unless there's something I don't know.
Re: Bug 3999 and 4261
(I hope that example of bearophile is just a bug.)
This one.
void main(string[] args) {
enum int n = args.length;
}
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [OT] Dark Star (1974) - the platinum age of movies
Nick Sabalausky wrote: Never heard of it, but it sounds like something I'll have to check out :) Yes, you do. It's a classic.
Re: Bug 3999 and 4261
so: (I hope that example of bearophile is just a bug.) I have added it as bug 4786 Bye, bearophile
Re: Bug 3999 and 4261
On Wednesday, September 01, 2010 11:58:39 so wrote: I have never had troubles with C++ compile/runtime const difference, and don't think it is a problem in C++. With this in mind enum is a great keyword of choice to express compile-time types, as long as it is forbidden for run-time constants. (I hope that example of bearophile is just a bug.) Thanks. C++ doesn't have CTFE. CTFE is why it really matters in D. If you're dealing with a compile-time constant, it uses CTFE. If you're dealing with a runtime constant, it doesn't. So, you need to be explicit. Personally, I don't really care about using enum the way it is. Having enums freely converting to and from their base type is more of a concern, though I'm not sure how much that really does or doesn't matter. It's quite clear when an enum is used as a manifest constant and when it's used as an enum, so I don't really see a problem with the way it is, though I can see why someone wouldn't like it. - Jonathan M Davis
Re: [Slight OT] TDPL in Russia
Steven Schveighoffer wrote: I was just employing irony and sarcasm to demonstrate why your arguments were meaningless :) The only measurable factor for good art is how many people use it/buy it. For-sale software, books, movies do rather well, so I'm inclined to believe they are pretty good. There are also some open source/free materials that do rather well, but they are not nearly as common as free materials that are crappy. My point was that for-sale art by far outperforms freely available art in popularity and usage. When you get paid to make something, you can do it more often, you get better at it, and your quality of work goes up. Someone once told me that capitalism doesn't support the arts. I asked him how the Beatles got rich. Oops! There's a subgroup of the theater crowd around here who regard producers as sellouts if their plays actually attract an audience.
Re: Bug 3999 and 4261
ctconst is a fictional keyword that denotes compile-time constants. Now you are probably able to see that there is no correlation between the n and Color. In D they are using the same keyword by accident, probably because Walter thinks that saving a keyword is more important than keeping the semantics tidy. So today you are probably struck with using enum to define compile-time constants. The C++0x design group has not introduced the enum class for fun, their strong typing nature is useful to make the code less bug-prone. See: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1719.pdf See for example Problem 1: Implicit conversion to an integer. Bye, bearophile Another taste discussion? Enum, again for my taste a great find for the job. Bugs aside, i can't seem to follow you. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [OT] Dark Star (1974) - the platinum age of movies
On Wed, 2010-09-01 at 12:01 -0700, Walter Bright wrote: Nick Sabalausky wrote: Never heard of it, but it sounds like something I'll have to check out :) Yes, you do. It's a classic. Extremely serious low budget though -- everyone needs to remember that when watching (1974, so pre Star Wars, and a very, very low budget). Great work by John Carpenter and Dan O'Bannon. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [Slight OT] TDPL in Russia
On Wednesday, September 01, 2010 12:15:24 Walter Bright wrote: Someone once told me that capitalism doesn't support the arts. I asked him how the Beatles got rich. Oops! Capitalism is going to tend to support what is generally popular or what is popular with the affluent crowd. Anything that doesn't fall in either of those categories isn't necessarily going to do well. So, the artsy stuff that appeals primarily to artsy people isn't necessarily going to do well. The Beatles managed general popularity, so capitalism supported them just fine. Music and movies are huge industries. Capitalism definitely supports them. However, if you're dealing with less well-known, less generally-liked stuff, then capitalism isnt't really going to support it. Of course, arguably, that's for the better, since if it doesn't do well that means that it's not something that the majority supports, but there is good stuff out there that never becomes particularly popular or successful. However, since art is generally in the eye of the beholder, there will always be people unhappy with how it gets handled regardless of the economic system in use. There's a subgroup of the theater crowd around here who regard producers as sellouts if their plays actually attract an audience. I hear that this sort of thing tends to happen with Indie artists as well. There are fans who like them until they get popular. I guess that there are people who _like_ it when the stuff that they like is niche. - Jonathan M Davis
Re: [Slight OT] TDPL in Russia
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.victz4b5eav...@localhost.localdomain... The only measurable factor for good art is how many people use it/buy it. That's not a bad point - I can't think of many other metrics for art. Quality certainly can positively influence popularity. But I think we have to be careful not to conflate popularity with quality too much. Similar to the old saying: What's popular is not always right. What's right is not always popular. PHP is wildly popular, but for anyone actually familiar with a variety of languages, the quality is undeniably poor, so again, we have to be careful with assuming connections between popularity and quality. For-sale software, books, movies do rather well, so I'm inclined to believe they are pretty good. There are also some open source/free materials that do rather well, but they are not nearly as common as free materials that are crappy. My point was that for-sale art by far outperforms freely available art in popularity and usage. When you get paid to make something, you can do it more often, you get better at it, and your quality of work goes up. I'm not disagreeing with the phenomenon you describe, but I think there are other contrary factors in play as well: - For-sale anything tends to have more marketing behind it than free (because if you're trying to get money for it, you're more motivated to get it out in front of people), so that can be a factor in the popularity/usage of for-sale things. If you're trying to sell your paintings, you're more likely to try to go as as many art fairs as you can, get business cards made out to hand out, get a spot and display that people will really notice, push your website, etc. If your work is free, you have less reason to do all that, which in turn, works against popularity and usage. - Free stuff is more likely to be a labor of love (because if you're not getting paid for it, why else bother if not because you truly care?), while for-sale tends to involve people who just don't give a crap about anything but the paycheck. They know something will sell as-is, so why waste the resources making it as good as they can make it, like the labor of love people would do? Businessmen have long ago learned that, contrary to the old saying, If you build a better mousetrap, the world will NOT beat a path to your door. Especially if the world doesn't even know you've done so. They'll just keep using their inferior, but popular, mousetraps. But if you can *convince* them you've built a better one, regardless of whether or not it's actualy true, then they *will*, metaphorically, beat a path to your door.
Re: Bug 3999 and 4261
On Tue, 31 Aug 2010 20:59:15 -0400, bearophile bearophileh...@lycos.com
wrote:
Daniel Gibson:
Then there still is the consistency-issue (anon. enums are treated
differently then named enums).
Look at this:Se
enum int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...
Color is a sequence of symbols, Red, Green and Blue, named Color. When
you write your program often all you need to know is if color is Red or
Green, and you don't care much how the compiler represents those symbols.
The n is a compile-time constant value. It's not a sequence of something.
Now, just for fun, replace the first enum with something as:
ctconst int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...
ctconst is a fictional keyword that denotes compile-time constants. Now
you are probably able to see that there is no correlation between the n
and Color.
In D they are using the same keyword by accident, probably because
Walter thinks that saving a keyword is more important than keeping the
semantics tidy.
AFAIK, enum meaning manifest constant was Andrei's request. And I think
if you have an idea to try and fix it, you might as well know now, it
will never happen. See this quote from Andrei in a bug report of mine
(bug 1961):
And enum... you'll have to yank that out from my dead cold hands.
Extending
enum instead of adding yet another way of defining symbolic constants is
The
Right Thing to do. I am sure people would have realized how ridiculous the
whole manifest thing is if we first proposed it. We just can't define one
more way for each kind of snow there is.
There was a point in D2 development with the 'manifest' keyword added to
do exactly what enum now does (except for actual enumerations, for which
enum was used).
FWIW, I am not a huge fan of enum being used for meaning manifest
constants that are not enumerations, but as far as daily usage, it's not
really bad. It's somewhat of a petty problem, since enum is not
functionally deficient. It just looks weird, especially to those used to
other languages. I suppose you could think of it as an enumeration with
one member :)
-Steve
Re: std.mixins
On Wed, Sep 1, 2010 at 20:59, Nick Sabalausky a...@a.a wrote: Torarin torar...@gmail.com wrote in messageTDPL says it should work for any type. http://d.puremagic.com/issues/show_bug.cgi?id=3382 /me squeals with excitement like a schoolgirl Any type, really? Even the basic built-in types, not only class/struct? That'd fun.
Re: std.mixins
It says: If a.fun(b, c, d) is seen but fun is not a member of a's type, D rewrites that as fun(a, b, c, d) and tries that as well. So I guess it's possible it won't work with numerical types because they can never have members. 2010/9/1 Philippe Sigaud philippe.sig...@gmail.com: On Wed, Sep 1, 2010 at 20:59, Nick Sabalausky a...@a.a wrote: Torarin torar...@gmail.com wrote in messageTDPL says it should work for any type. http://d.puremagic.com/issues/show_bug.cgi?id=3382 /me squeals with excitement like a schoolgirl Any type, really? Even the basic built-in types, not only class/struct? That'd fun.
Re: Bug 3999 and 4261
On Wednesday, September 01, 2010 12:36:04 Steven Schveighoffer wrote: AFAIK, enum meaning manifest constant was Andrei's request. And I think if you have an idea to try and fix it, you might as well know now, it will never happen. See this quote from Andrei in a bug report of mine (bug 1961): And enum... you'll have to yank that out from my dead cold hands. Extending enum instead of adding yet another way of defining symbolic constants is The Right Thing to do. I am sure people would have realized how ridiculous the whole manifest thing is if we first proposed it. We just can't define one more way for each kind of snow there is. There was a point in D2 development with the 'manifest' keyword added to do exactly what enum now does (except for actual enumerations, for which enum was used). FWIW, I am not a huge fan of enum being used for meaning manifest constants that are not enumerations, but as far as daily usage, it's not really bad. It's somewhat of a petty problem, since enum is not functionally deficient. It just looks weird, especially to those used to other languages. I suppose you could think of it as an enumeration with one member :) -Steve It's the kind of thing that is distasteful from a language purity standpoint, but it really doesn't cause any problems in code as far as I can tell. Once you know that you use enum to declare a manifest constant, it's perfectly normal to see it in code that way, so it's not confusing. And since you're not going to try to enumerate over such enums, it's not like they cause any real confusion with normal enums. You can think of it a bit like static. Static is used for different things in different contexts (even though most contexts are quite similar - IIRC, there's a way to define static in C++ which fits all of its uses in C++, though D adds some more that don't fit that definitition), but it doesn't really cause any confusion. enum is the same way. Sure, from the standpoint of language purity, manifest constants shouldn't be declared using enum, but the reality of the matter is that it works just fine. - Jonathan M Davis
Re: std.mixins
On Wed, Sep 1, 2010 at 15:25, Simen kjaeraas simen.kja...@gmail.com wrote:
Philippe Sigaud philippe.sig...@gmail.com wrote:
I also have a template that gets the list of all members of an aggregate
type (classes, structs and, well, modules, in a way), even the
constructors,
even the overloaded members, separated by type, and list them with their
names and associated type. It even gets the types aliases and unittests,
though I don't know what to do with the latter. That was part of a project
to duplicate a type: generate a new type with this extracted info. I had
vague projects to transform the methods into their const equivalent for
example or to render the fields immutable, but didn't get that far. Would
that be interesting to someone?
I could imagine extracting the unittests could be useful for making a
unittest system. Are they only included when passing -unittest?
Hmm, don't know. Let see:
import std.stdio;
class C
{
int i;
unittest
{
assert(true);
writeln(Hello World!);
}
}
void main() {
writeln([__traits(allMembers, C)]);
writeln(typeof(C.__unittest1()).stringof);
C.__unittest1();
}
No, compile this with and without -unittest, and __unittest1 is present. Oh,
btw, contrary to the docs __traits(getOverloads, T) works also for structs
and modules, not only classes.
The unittests type is void delegate(), which is coherent with them being
blocks of instructions. You can even call it like a function (see the last
line of main).
Strange, I never could get that to work... Maybe I didn't try this with a
class.
Philippe
Re: std.mixins
On Wed, Sep 1, 2010 at 21:47, Torarin torar...@gmail.com wrote: It says: If a.fun(b, c, d) is seen but fun is not a member of a's type, D rewrites that as fun(a, b, c, d) and tries that as well. So I guess it's possible it won't work with numerical types because they can never have members. I just tried this: int i; writeln(i.max); // writes int.max ! So it seems you can access the type properties through a value of that type. Man, I learnt two new things in two minutes... Philippe
Re: [OT] Dark Star (1974) - the platinum age of movies
Russel Winder rus...@russel.org.uk wrote in message news:mailman.34.1283369300.858.digitalmar...@puremagic.com... On Wed, 2010-09-01 at 12:01 -0700, Walter Bright wrote: Nick Sabalausky wrote: Never heard of it, but it sounds like something I'll have to check out :) Yes, you do. It's a classic. Extremely serious low budget though -- everyone needs to remember that when watching (1974, so pre Star Wars, and a very, very low budget). Great work by John Carpenter and Dan O'Bannon. It's John Carpenter?? Ok, now I *know* I have to see it! :)
Re: Reporting TDPL bugs in Bugzilla
On 01/09/10 16:49, user wrote: To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. Thats ridiclous. The only purpose for prioriting these bugs is- you fail at compiler construction. The language is so full of shit.. why not be more honest? you had over 10 years of time to develop basic foundations but its still a amateurish attempt at language design. Tell me about another language which is so much work in progress after 10 years of development. They are all so stable. If I want I can build a 'E' language and fix all your legacy bugs. D is nowhere near perfection. The bug #1 in your bugzilla was 'just give up already'. Someone marked it wontfix. Don't feed the trolls, that is all.
Re: Bug 3999 and 4261
Jonathan M Davis jmdavisp...@gmail.com wrote in message news:mailman.33.1283368612.858.digitalmar...@puremagic.com... Personally, I don't really care about using enum the way it is. Having enums freely converting to and from their base type is more of a concern, though I'm not sure how much that really does or doesn't matter. I find it to be a pain nearly every time I need to convert one to a string.
Re: std.mixins
2010/9/1 Philippe Sigaud philippe.sig...@gmail.com: I just tried this: int i; writeln(i.max); // writes int.max ! So it seems you can access the type properties through a value of that type. Man, I learnt two new things in two minutes... Yay, looks pretty good, then! :)
[Challenge] implementing the ambiguous operator in D
Hey, this question on SO makes for a good challenge: http://stackoverflow.com/questions/3608834/is-it-possible-to-generically-implement-the-amb-operator-in-d The amb operator does this: amb([1, 2]) * amb([3, 4, 5]) == amb([3, 4, 5, 6, 8, 10]) amb([hello, world]) ~ amb([qwerty]) == amb([helloqwerty, worldqwerty]) amb([hello, world]) ~ qwerty == amb([helloqwerty, worldqwerty]) amb([hello, very long string]).length = amb([5, 16]) (I find the guy examples much more comprehensible that the articles he links to) Are people interested in trying this? Peter, can we discuss your solution here? Philippe
Re: [Slight OT] TDPL in Russia
On Wed, 01 Sep 2010 15:34:00 -0400, Nick Sabalausky a...@a.a wrote: Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.victz4b5eav...@localhost.localdomain... The only measurable factor for good art is how many people use it/buy it. That's not a bad point - I can't think of many other metrics for art. Quality certainly can positively influence popularity. But I think we have to be careful not to conflate popularity with quality too much. Similar to the old saying: What's popular is not always right. What's right is not always popular. PHP is wildly popular, but for anyone actually familiar with a variety of languages, the quality is undeniably poor, so again, we have to be careful with assuming connections between popularity and quality. Imagine if you had to pay for it ;) For-sale software, books, movies do rather well, so I'm inclined to believe they are pretty good. There are also some open source/free materials that do rather well, but they are not nearly as common as free materials that are crappy. My point was that for-sale art by far outperforms freely available art in popularity and usage. When you get paid to make something, you can do it more often, you get better at it, and your quality of work goes up. I'm not disagreeing with the phenomenon you describe, but I think there are other contrary factors in play as well: - For-sale anything tends to have more marketing behind it than free (because if you're trying to get money for it, you're more motivated to get it out in front of people), so that can be a factor in the popularity/usage of for-sale things. If you're trying to sell your paintings, you're more likely to try to go as as many art fairs as you can, get business cards made out to hand out, get a spot and display that people will really notice, push your website, etc. If your work is free, you have less reason to do all that, which in turn, works against popularity and usage. There is that part of it. Some companies can sell whatever they want because of marketing, i.e. Microsoft. But one thing that for-sale art does is weed out the unpopular artists. Make a crappy product, and many people won't buy your next one. Look how hard Vista hit Microsoft despite their huge marketing machine. As far as free software advertisement though, most of that is negated by google these days :) Just yesterday I wanted to find a tool that diff'd mysql database schemas so I could sync one to the other. In about 10 minutes I found 2-3 candidates that were free and I didn't use any of them, because they seemed unfinished, or required installing other stuff just to get it to work. What I ended up using is advise on a forum that said to just diff the results of the mysqldump. But I think you would agree the truly great free products/software don't have a problem with marketing because growth today is viral when someone finds something that is awesome, free or not. - Free stuff is more likely to be a labor of love (because if you're not getting paid for it, why else bother if not because you truly care?), while for-sale tends to involve people who just don't give a crap about anything but the paycheck. They know something will sell as-is, so why waste the resources making it as good as they can make it, like the labor of love people would do? I think most good products are labors of love, even ones that are not free. There are many cases that are not, and are just there for the money, but those usually aren't as successful. As you say, not as much effort is put into those. But if something is good, and people will pay for it, why wouldn't you want to charge for it so you can continue doing it? I don't understand the thought process that necessarily links love for a job or quality of art to working for free. I love programming, but love or not, it would just be a toy hobby if I had to spend the majority of my day doing something else in order to support myself and my family. Businessmen have long ago learned that, contrary to the old saying, If you build a better mousetrap, the world will NOT beat a path to your door. Especially if the world doesn't even know you've done so. They'll just keep using their inferior, but popular, mousetraps. But if you can *convince* them you've built a better one, regardless of whether or not it's actualy true, then they *will*, metaphorically, beat a path to your door. Yes, there are plenty examples of that. -Steve
Re: Bug 3999 and 4261
Jonathan M Davis jmdavisp...@gmail.com wrote in message news:mailman.38.1283370572.858.digitalmar...@puremagic.com... You can think of it a bit like static. Static is used for different things in different contexts (even though most contexts are quite similar - IIRC, there's a way to define static in C++ which fits all of its uses in C++, though D adds some more that don't fit that definitition), but it doesn't really cause any confusion. enum is the same way. Sure, from the standpoint of language purity, manifest constants shouldn't be declared using enum, but the reality of the matter is that it works just fine. Static is a little bit better in that the uses of it at least have some connection to the dictionary meaning of static, even if perhaps a little distant. But there's just no way to stretch the dictionary meaning of enumeration to include manifest constants. Like everyone else, I can at least live with it, but I look forward to the day the linker issue is fixed so we can finally mutilate/destroy/kill it, dead, dead, dead with extreme prejudice in favor of immutable. It's a stain - doesn't really cause a problem, but boy is it ever UGLY.
Re: Bug 3999 and 4261
Static is a little bit better in that the uses of it at least have some connection to the dictionary meaning of static, even if perhaps a little distant. But there's just no way to stretch the dictionary meaning of enumeration to include manifest constants. Like everyone else, I can at least live with it, but I look forward to the day the linker issue is fixed so we can finally mutilate/destroy/kill it, dead, dead, dead with extreme prejudice in favor of immutable. It's a stain - doesn't really cause a problem, but boy is it ever UGLY. Float is not floating and double is not doubling, are they next? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: std.mixins
Torarin torar...@gmail.com wrote in message news:mailman.37.1283370434.858.digitalmar...@puremagic.com... It says: If a.fun(b, c, d) is seen but fun is not a member of a's type, D rewrites that as fun(a, b, c, d) and tries that as well. So I guess it's possible it won't work with numerical types because they can never have members. That's not the way I interpret that. If 'a' is a numeric primitive type and can never have members, then 'fun' can never be a member of 'a', therefore the rewritten version should always get tried. Unfortunately, at the moment, D2 is actually a little *further* from that universal ideal than D1 is: Regression(2.020) Array member call syntax can't find matches in current class http://d.puremagic.com/issues/show_bug.cgi?id=4525 When I converted some D1 code to D2 recently, I actually had to *remove* many of my array-member-call-syntax calls because of that bug.
Re: Reporting TDPL bugs in Bugzilla
user wrote: To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. Thats ridiclous. The only purpose for prioriting these bugs is- you fail at compiler construction. The language is so full of shit.. why not be more honest? you had over 10 years of time to develop basic foundations but its still a amateurish attempt at language design. Tell me about another language which is so much work in progress after 10 years of development. They are all so stable. If I want I can build a 'E' language and fix all your legacy bugs. D is nowhere near perfection. The bug #1 in your bugzilla was 'just give up already'. Someone marked it wontfix. Is it just me, or spam bots suddenly became incredibly clever?
Re: Reporting TDPL bugs in Bugzilla
If they were clever they wouldn't target an audience of programmers. :) On Wed, Sep 1, 2010 at 10:23 PM, Stanislav Blinov stanislav.bli...@gmail.com wrote: user wrote: To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. Thats ridiclous. The only purpose for prioriting these bugs is- you fail at compiler construction. The language is so full of shit.. why not be more honest? you had over 10 years of time to develop basic foundations but its still a amateurish attempt at language design. Tell me about another language which is so much work in progress after 10 years of development. They are all so stable. If I want I can build a 'E' language and fix all your legacy bugs. D is nowhere near perfection. The bug #1 in your bugzilla was 'just give up already'. Someone marked it wontfix. Is it just me, or spam bots suddenly became incredibly clever?
Re: Bug 3999 and 4261
so s...@so.do wrote in message news:op.videg00w7dt...@so-pc... Static is a little bit better in that the uses of it at least have some connection to the dictionary meaning of static, even if perhaps a little distant. But there's just no way to stretch the dictionary meaning of enumeration to include manifest constants. Like everyone else, I can at least live with it, but I look forward to the day the linker issue is fixed so we can finally mutilate/destroy/kill it, dead, dead, dead with extreme prejudice in favor of immutable. It's a stain - doesn't really cause a problem, but boy is it ever UGLY. Float is not floating and double is not doubling, are they next? Float (short for floating point): The decimal point can float around as the value changes (not a literal use of float, but there's nothing wrong with metaphoric uses of words, even in ordinary speech). This type is named in contrast to the fixed-point arithmetic that was often used as an old-school optimization (where the decimal point was always at a fixed location, for example, the high 16-bits may have been the whole-number part, and the low 16-bits may have been the decimal part). Double: This one's easy: It's double the size of a float.
Re: [D.typesystem] Static (CT) enforce anybody?
On Wed, Sep 1, 2010 at 16:28, Justin Johansson n...@spam.com wrote: On 01/09/10 22:49, Steven Schveighoffer wrote: Compile time checks are only available for compile time values. Yes, Steve is right. Also, you cannot throw exceptions at CT. But you can use 'static assert(...)' to force the evaluation of an assertion at CT. Thanks Steve, I'm returning to bomb bay to think about this. (See my 'Dark Star' post for interpretation) Why do I think that half the reason you asked this question was to be able to post this reply? ;) Philippe
Re: Bug 3999 and 4261
so: Another taste discussion? Nope. - Steven Schveighoffer: And I think if you have an idea to try and fix it, you might as well know now, it will never happen. There I was explaining something better to Daniel Gibson. The purpose of the enhancement request 3999 has nothing to do with a request for a different keyword. - I think now I have presented my point as well as I can, and people have given comments and opinions. I'd like to Walter or/and Andrei to express their opinion about the bug 3999 :-) Bye, bearophile
Re: [D.typesystem] Static (CT) enforce anybody?
Philippe Sigaud: Yes, Steve is right. Also, you cannot throw exceptions at CT. This is a temporary limitation :-) Bye, bearophile
Re: Bug 3999 and 4261
On Wednesday, September 01, 2010 12:59:01 Nick Sabalausky wrote: Jonathan M Davis jmdavisp...@gmail.com wrote in message news:mailman.33.1283368612.858.digitalmar...@puremagic.com... Personally, I don't really care about using enum the way it is. Having enums freely converting to and from their base type is more of a concern, though I'm not sure how much that really does or doesn't matter. I find it to be a pain nearly every time I need to convert one to a string. I wasn't even aware that there was a way. If I had to guess, I would assume that it involves stringof, but I'd have to try it. Now, assuming that that's the case, it would be pretty easy to write a template function which takes the enum type and the value to stringify, and it returns the string version of that enum value (or throws if it's not a valid value for that enum type). I can see how having it as a distinct type would be more desirable for that though, since then you could likely just use stringof on it directly. - Jonathan M Davis
Re: Bug 3999 and 4261
Float (short for floating point): The decimal point can float around
as
the value changes (not a literal use of float, but there's nothing
wrong
with metaphoric uses of words, even in ordinary speech). This type is
named
in contrast to the fixed-point arithmetic that was often used as an
old-school optimization (where the decimal point was always at a fixed
location, for example, the high 16-bits may have been the whole-number
part,
and the low 16-bits may have been the decimal part).
Double: This one's easy: It's double the size of a float.
I know what they are, but at the same time was expecting you to get the
point :)
When you need a compile-time type in C/C++ mostly you don't need a type,
just :
enum { value = 10 }; // Also, this is suggested over const
Coming from C/C++ enum constants are pretty straightforward as
compile-time constants.
And please, it is only 4 letters. (In case you missed, they are e, n, u,
m. They are the 4 best looking
characters on every editor!)
This reminds me the retro case, where most argue against and making up
names such like reverseAndSomeOtherUglyNonsense.
Anyone here got trouble understanding what enum is and what it does? No,
It wasn't the case in retro either.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Reporting TDPL bugs in Bugzilla
Stanislav Blinov schrieb: user wrote: To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. To everyone reporting inconsistencies between Andrei's book and the compiler -- please include TDPL or [tdpl] in the bug title, to make it easier to search for them. These bugs have high priority. Thats ridiclous. The only purpose for prioriting these bugs is- you fail at compiler construction. The language is so full of shit.. why not be more honest? you had over 10 years of time to develop basic foundations but its still a amateurish attempt at language design. Tell me about another language which is so much work in progress after 10 years of development. They are all so stable. If I want I can build a 'E' language and fix all your legacy bugs. D is nowhere near perfection. The bug #1 in your bugzilla was 'just give up already'. Someone marked it wontfix. Is it just me, or spam bots suddenly became incredibly clever? You call that clever? O_o
Re: std.mixins
On Wed, Sep 1, 2010 at 22:18, Nick Sabalausky a...@a.a wrote: Regression(2.020) Array member call syntax can't find matches in current class http://d.puremagic.com/issues/show_bug.cgi?id=4525 When I converted some D1 code to D2 recently, I actually had to *remove* many of my array-member-call-syntax calls because of that bug. Sh*t. And trying to put Foo somewhere in there doesn't work either. str.Foo.bar(), str.(Foo.bar()). Anyway, that would defeat the purpose which is to get a clean, universal call syntax.
Re: Bug 3999 and 4261
I thought to!string(Enum) already does this? This was the example I
posted in bug report 4261:
import std.conv : to;
import std.stdio: writeln;
void main()
{
enum Foo { Zero, One }
Foo f = Foo.One;
writeln(to!string(f));
}
Prints: One
On Wed, Sep 1, 2010 at 10:50 PM, Jonathan M Davis jmdavisp...@gmail.com wrote:
On Wednesday, September 01, 2010 12:59:01 Nick Sabalausky wrote:
Jonathan M Davis jmdavisp...@gmail.com wrote in message
news:mailman.33.1283368612.858.digitalmar...@puremagic.com...
Personally, I don't really care about using enum the way it is. Having
enums
freely converting to and from their base type is more of a concern,
though I'm
not sure how much that really does or doesn't matter.
I find it to be a pain nearly every time I need to convert one to a string.
I wasn't even aware that there was a way. If I had to guess, I would assume
that
it involves stringof, but I'd have to try it. Now, assuming that that's the
case, it would be pretty easy to write a template function which takes the
enum
type and the value to stringify, and it returns the string version of that
enum
value (or throws if it's not a valid value for that enum type). I can see how
having it as a distinct type would be more desirable for that though, since
then
you could likely just use stringof on it directly.
- Jonathan M Davis
Re: [D.typesystem] Static (CT) enforce anybody?
On Wed, Sep 1, 2010 at 22:37, bearophile bearophileh...@lycos.com wrote: Philippe Sigaud: Yes, Steve is right. Also, you cannot throw exceptions at CT. This is a temporary limitation :-) Really? That means being able to create reference types at CT, that'd be interesting, to say the least. And what code would catch them? Aren't they caught by the runtime?
Re: Reporting TDPL bugs in Bugzilla
Is it just me, or spam bots suddenly became incredibly clever? You call that clever? O_o For a bot. It almost seems as there is some intelligence behind this. Well, a little too almost, maybe.
Re: About removing the new keyword
Why not? There are many examples of operating systems with garbage collector built-in. Era Scarecrow rtcv...@yahoo.com wrote in to use delete. Also since this is a OS building language, i wouldn't expect a garbage collector in that instance at all. So, Delete should just be discouraged, not removed. Era
Re: [D.typesystem] Suggestion for improving OO inheritance models
On Wed, Sep 1, 2010 at 18:13, retard r...@tard.com.invalid wrote: Have you taken a loot at Scala traits already? It would be a great starting point. Scala's traits are great! Implicits in Scala are quite interesting too. Also, Haskell typeclasses I wonder if D can have part of Scala traits functionality with mixins?
Re: std.mixins
On 2010-08-31 03:04, dsimcha wrote: I've been toying for a long time with the idea of a std.mixins for Phobos that would contain meta-implementations of commonly needed boilerplate code for mixing into classes and and structs. I've started to prototype it (http://dsource.org/projects/scrapple/browser/trunk/std_mixins/std_mixins.d). So far I have a mixin for struct comparisons, which is useful if you need a total ordering for use with sorting or binary trees, but don't care exactly how that ordering is defined. I've also got a mixin that converts a class to a Singleton, and uses thread-safe but efficient mechanisms to deal with the __gshared singleton case. I'm also thinking of creating some mixins to allow cloning of arbitrarily complicated object graphs, provided that you don't stray outside of SafeD. Is this worth implementing or will it likely be solved in some other way at some point? Right now I'd just like to milk the D community for ideas. What other pieces of boilerplate code do you find yourself writing often that the standard library should help with? How about adding a static opDispatch (or alias this) that will forward every method call to the instance method. This would allow code like this: Foo.method; // shortcut for the line below Foo.instance.method; -- /Jacob Carlborg
Re: Bug 3999 and 4261
Float (short for floating point): The decimal point can float around as the value changes (not a literal use of float, but there's nothing wrong with metaphoric uses of words, even in ordinary speech). This type is named in contrast to the fixed-point arithmetic that was often used as an old-school optimization (where the decimal point was always at a fixed location, for example, the high 16-bits may have been the whole-number part, and the low 16-bits may have been the decimal part). Double: This one's easy: It's double the size of a float. If you throw 2.7f on a water, does it float or you need to multiply with pi first? Why don't we change double to hmm... doubleTheSizeOfFloat? Lets test it! - manifest doubleTheSizeOfFloat pi=3.14; doubleTheSizeOfFloat f=2.7; if(!floats(f)) multiplyFirstOneWithTheSecondAndAssignToTheFirstParameter(f, pi); // that was the java operator overloading case? Yeh fundamental type but still it is funny! - enum pi=3.14; double f=2.7; if(!floats(f)) f *= pi; -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [D.typesystem] Static (CT) enforce anybody?
On Wednesday, September 01, 2010 13:54:15 Philippe Sigaud wrote: On Wed, Sep 1, 2010 at 22:37, bearophile bearophileh...@lycos.com wrote: Philippe Sigaud: Yes, Steve is right. Also, you cannot throw exceptions at CT. This is a temporary limitation :-) Really? That means being able to create reference types at CT, that'd be interesting, to say the least. And what code would catch them? Aren't they caught by the runtime? Well, according to TDPL, the ultimate goal is to be able to use _all_ of SafeD with CTFE. So, exceptions would be on the list. However, I wouldn't expect CTFE to get that powerful anytime soon. - Jonathan M Davis
Re: Bug 3999 and 4261
On Wednesday, September 01, 2010 13:53:51 Andrej Mitrovic wrote:
I thought to!string(Enum) already does this? This was the example I
posted in bug report 4261:
import std.conv : to;
import std.stdio: writeln;
void main()
{
enum Foo { Zero, One }
Foo f = Foo.One;
writeln(to!string(f));
}
Prints: One
Well, like I said, it never occurred to me that you even could print enums as
strings in D, so I don't know how it's typically done. However, if it's as
simple as that, I don't really see what the problem is. Sure, it would be nice
if they printed as strings by default rather than the generally useless base
type of int or whatever, but using to!string like that is quite straightforward.
- Jonathan M Davis
Re: Bug 3999 and 4261
On 9/1/10 15:35 CDT, bearophile wrote: so: Another taste discussion? Nope. - Steven Schveighoffer: And I think if you have an idea to try and fix it, you might as well know now, it will never happen. There I was explaining something better to Daniel Gibson. The purpose of the enhancement request 3999 has nothing to do with a request for a different keyword. - I think now I have presented my point as well as I can, and people have given comments and opinions. I'd like to Walter or/and Andrei to express their opinion about the bug 3999 :-) I think it's a good enhancement. C++'s good old enum has been instrumental in finding a few bugs and clarifying a few interfaces in a project at work. Based on that experience I'd say that there's a chance more restrictive is better. We need to find a principled way to define semantics though - if we disable comparison it really means we're disabling implicit conversion. Andrei
Re: [D.typesystem] Static (CT) enforce anybody?
Philippe Sigaud: Really? That means being able to create reference types at CT, that'd be interesting, to say the least. And what code would catch them? Aren't they caught by the runtime? I think in Bugzilla there is a patch to use exceptions at CT, but it probably doesn't work and has problems. So I don't know if this limit will be removed. Bye, bearophile
Re: std.mixins
On 2010-09-01 14:52, Torarin wrote: TDPL says it should work for any type. http://d.puremagic.com/issues/show_bug.cgi?id=3382 2010/9/1 Nick Sabalauskya...@a.a: dsimchadsim...@yahoo.com wrote in message news:i5jtdn$1g4...@digitalmars.com... Isn't this a core language feature that's in the spec but is only currently implemented for arrays? I thought eventually uniform function call syntax was coming for classes and structs, too. I've been really wishing for a long time that would actually happen. It's annoying enough not to be able to do it for most types, but then the fact that it's special-cased at all is a bit of a bizarre inconsistency. I'm not completely sure but I think someone said that the float literal syntax (.1 and 1.) is ambiguous with the uniform function call syntax. -- /Jacob Carlborg
Re: [Slight OT] TDPL in Russia
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.vidd20ldeav...@localhost.localdomain... On Wed, 01 Sep 2010 15:34:00 -0400, Nick Sabalausky a...@a.a wrote: PHP is wildly popular, but for anyone actually familiar with a variety of languages, the quality is undeniably poor, so again, we have to be careful with assuming connections between popularity and quality. Imagine if you had to pay for it ;) There's a commerical web-app package for colleges called Blackboard. Hugely, enormously popular among college IT departments (ie, the target buyers). But it's undeniably total crap. Damn thing barely even works at all, and that's not just my observation, but the observation of many students at the colleges that use it. Other commercial things that have been heavily used or popular and I would argue to have been of relatively poor quality (relative to either their price or to competing offerings) even at the time they were either heavily used or well-regarded (though I admit some might be debatable): Oracle DBMS, Lotus Notes, MS Visual SourceSafe, iPod, Cadillac/Oldsmobile, Visual Basic 6, Classic ASP, Flash IDE, Photoshop, XBox 360. But one thing that for-sale art does is weed out the unpopular artists. I don't know, maybe, maybe not. I would argue that there were far more people who very vocally hated NSync, Spice Girls and the Macarena, then there were people who actually liked them. Those music acts were successful for a short while (at least for their labels), but I don't know about popular. Disliking and making fun of them was certainly very, very popular - far more popular than actually listening to them, from everything I could tell. Make a crappy product, and many people won't buy your next one. Look how hard Vista hit Microsoft despite their huge marketing machine. Well, in many ways, Microsoft is unpopular ;) Although they're really a bit of an odd beast: They're heavily hated, but also heavily used. You could say they're both popular and unpopular at the same time. And I don't know about make a crappy product, and many people won't buy your next one: Vista didn't seem to prevent people from buying Win7 en masse. But I think you would agree the truly great free products/software don't have a problem with marketing because growth today is viral when someone finds something that is awesome, free or not. True, but there's still a lot of difficulty in getting that viral ball rolling in the first place, it has to reach a certain critical mass first. D had faced an uphill battle for mindshare for a long time and the viral effect is only now starting to produce results. I think most good products are labors of love, even ones that are not free. Agreed. But if something is good, and people will pay for it, why wouldn't you want to charge for it so you can continue doing it? I don't understand the thought process that necessarily links love for a job or quality of art to working for free. In many cases I agree, but sometimes the market just isn't there, or maybe it's something that would just be very difficult to market as a commercial offering. In those cases getting it used by more than a handful of people (if any) requires it be free. For instance, the market for commercial languages is pretty much dead. D's reference compiler *needed* to be free or else it never would have gotten serious attention. Or it could be a vehicle for something else: Like how MS doesn't even charge for their compilers (just their IDEs and platforms) because their real products are their platforms. Same with Apple and the iTunes software: it's free to help boost iPod and music/video sales. (Of course, there is still room for commercial compilers: like the Intel C/C++ one, because it supposedly produces far better optimized code than the free C/C++ compilers. But a language that doesn't have at least some good free compiler is doomed to failure these days.)
Re: std.mixins
Jacob Carlborg d...@me.com wrote in message news:i5mg57$2sh...@digitalmars.com... On 2010-09-01 14:52, Torarin wrote: TDPL says it should work for any type. http://d.puremagic.com/issues/show_bug.cgi?id=3382 2010/9/1 Nick Sabalauskya...@a.a: dsimchadsim...@yahoo.com wrote in message news:i5jtdn$1g4...@digitalmars.com... Isn't this a core language feature that's in the spec but is only currently implemented for arrays? I thought eventually uniform function call syntax was coming for classes and structs, too. I've been really wishing for a long time that would actually happen. It's annoying enough not to be able to do it for most types, but then the fact that it's special-cased at all is a bit of a bizarre inconsistency. I'm not completely sure but I think someone said that the float literal syntax (.1 and 1.) is ambiguous with the uniform function call syntax. I seem to remember a discussion about it being ambiguous with some proposed inclusing-range syntax. And yes, I can imagine that float syntax also being ambiguous with uniform function call syntax. But I also remember a certain someone (me!...plus some others) saying that .1 and 1. float literals are completely worthless and in the face of ambiguity with *useful* things, they need to DIE DIE DIE!!!
Re: [D.typesystem] Suggestion for improving OO inheritance models
On 2010-09-01 22:44, Philippe Sigaud wrote: On Wed, Sep 1, 2010 at 18:13, retard r...@tard.com.invalid wrote: Have you taken a loot at Scala traits already? It would be a great starting point. Scala's traits are great! Implicits in Scala are quite interesting too. Also, Haskell typeclasses I wonder if D can have part of Scala traits functionality with mixins? You can't use D template mixins to add methods that will overload existing methods. -- /Jacob Carlborg
Re: [D.typesystem] Suggestion for improving OO inheritance models
You mean like this?:
module add_virtual_functions;
import std.stdio : writeln;
void main()
{
test();
}
mixin template Foo()
{
void func()
{
writeln(Foo.func());
}
}
class Bar
{
void func()
{
writeln(Bar.func());
}
}
class Code : Bar
{
mixin Foo;
}
void test()
{
Bar b = new Bar();
b.func(); // calls Bar.func()
Code c = new Code();
c.func(); // calls Code.func()
}
On Wed, Sep 1, 2010 at 11:30 PM, Jacob Carlborg d...@me.com wrote:
On 2010-09-01 22:44, Philippe Sigaud wrote:
On Wed, Sep 1, 2010 at 18:13, retard r...@tard.com.invalid wrote:
Have you taken a loot at Scala traits already? It would be a great
starting point.
Scala's traits are great! Implicits in Scala are quite interesting too.
Also, Haskell typeclasses
I wonder if D can have part of Scala traits functionality with mixins?
You can't use D template mixins to add methods that will overload existing
methods.
--
/Jacob Carlborg
Re: Bug 3999 and 4261
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message
news:mailman.49.1283374449.858.digitalmar...@puremagic.com...
I thought to!string(Enum) already does this? This was the example I
posted in bug report 4261:
import std.conv : to;
import std.stdio: writeln;
void main()
{
enum Foo { Zero, One }
Foo f = Foo.One;
writeln(to!string(f));
}
Prints: One
Does it really work that way now? That must have changed then. I could swear
it wasn't like that before.
Re: Bug 3999 and 4261
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:i5mfji$2qt...@digitalmars.com... I think it's a good enhancement. C++'s good old enum has been instrumental in finding a few bugs and clarifying a few interfaces in a project at work. Based on that experience I'd say that there's a chance more restrictive is better. We need to find a principled way to define semantics though - if we disable comparison it really means we're disabling implicit conversion. ...it really means we're disabling implicit conversion And that's a problem?
Re: [D.typesystem] Suggestion for improving OO inheritance models
Disregard the module name declaration. The original example had the
template mixin create a virtual method, and then you can override it
in the inheriting class.
On Wed, Sep 1, 2010 at 11:39 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
You mean like this?:
module add_virtual_functions;
import std.stdio : writeln;
void main()
{
test();
}
mixin template Foo()
{
void func()
{
writeln(Foo.func());
}
}
class Bar
{
void func()
{
writeln(Bar.func());
}
}
class Code : Bar
{
mixin Foo;
}
void test()
{
Bar b = new Bar();
b.func(); // calls Bar.func()
Code c = new Code();
c.func(); // calls Code.func()
}
On Wed, Sep 1, 2010 at 11:30 PM, Jacob Carlborg d...@me.com wrote:
On 2010-09-01 22:44, Philippe Sigaud wrote:
On Wed, Sep 1, 2010 at 18:13, retard r...@tard.com.invalid wrote:
Have you taken a loot at Scala traits already? It would be a great
starting point.
Scala's traits are great! Implicits in Scala are quite interesting too.
Also, Haskell typeclasses
I wonder if D can have part of Scala traits functionality with mixins?
You can't use D template mixins to add methods that will overload existing
methods.
--
/Jacob Carlborg
Re: [D.typesystem] Suggestion for improving OO inheritance models
Ah nevermind. I didn't realize you've said overload.
On Wed, Sep 1, 2010 at 11:39 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
You mean like this?:
module add_virtual_functions;
import std.stdio : writeln;
void main()
{
test();
}
mixin template Foo()
{
void func()
{
writeln(Foo.func());
}
}
class Bar
{
void func()
{
writeln(Bar.func());
}
}
class Code : Bar
{
mixin Foo;
}
void test()
{
Bar b = new Bar();
b.func(); // calls Bar.func()
Code c = new Code();
c.func(); // calls Code.func()
}
On Wed, Sep 1, 2010 at 11:30 PM, Jacob Carlborg d...@me.com wrote:
On 2010-09-01 22:44, Philippe Sigaud wrote:
On Wed, Sep 1, 2010 at 18:13, retard r...@tard.com.invalid wrote:
Have you taken a loot at Scala traits already? It would be a great
starting point.
Scala's traits are great! Implicits in Scala are quite interesting too.
Also, Haskell typeclasses
I wonder if D can have part of Scala traits functionality with mixins?
You can't use D template mixins to add methods that will overload existing
methods.
--
/Jacob Carlborg
Re: [Challenge] implementing the ambiguous operator in D
On 1/09/10 9:08 PM, Philippe Sigaud wrote: Peter, can we discuss your solution here? Sure, I'd be interested to hear any improvements. Like I said in my answer, I'm still learning D so I'm sure there's many issues. For example, I made no attempt for const-correctness or anything like that (mostly for simplicity). In particular, I'd be interested in knowing if there's a better way to write opDispatch i.e. a way that doesn't use that ugly mixin.
Re: Bug 3999 and 4261
That's how it's described in TDPL, and yes it works.
On Wed, Sep 1, 2010 at 11:38 PM, Nick Sabalausky a...@a.a wrote:
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message
news:mailman.49.1283374449.858.digitalmar...@puremagic.com...
I thought to!string(Enum) already does this? This was the example I
posted in bug report 4261:
import std.conv : to;
import std.stdio: writeln;
void main()
{
enum Foo { Zero, One }
Foo f = Foo.One;
writeln(to!string(f));
}
Prints: One
Does it really work that way now? That must have changed then. I could swear
it wasn't like that before.
Re: Bug 3999 and 4261
so s...@so.do wrote in message news:op.vidgxic47dt...@so-pc... Float (short for floating point): The decimal point can float around as the value changes (not a literal use of float, but there's nothing wrong with metaphoric uses of words, even in ordinary speech). This type is named in contrast to the fixed-point arithmetic that was often used as an old-school optimization (where the decimal point was always at a fixed location, for example, the high 16-bits may have been the whole-number part, and the low 16-bits may have been the decimal part). Double: This one's easy: It's double the size of a float. If you throw 2.7f on a water, does it float or you need to multiply with pi first? Like I said, metaphor. By contrast there's no basis for a metaphor between enumeration and manifest constants. Why don't we change double to hmm... doubleTheSizeOfFloat? Lets test it! Please don't go using strawmen. No one ever said anything about abbreviations being bad.
Re: Bug 3999 and 4261
On 9/1/10 16:39 CDT, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:i5mfji$2qt...@digitalmars.com... I think it's a good enhancement. C++'s good old enum has been instrumental in finding a few bugs and clarifying a few interfaces in a project at work. Based on that experience I'd say that there's a chance more restrictive is better. We need to find a principled way to define semantics though - if we disable comparison it really means we're disabling implicit conversion. ...it really means we're disabling implicit conversion And that's a problem? It's bound to break some code. Andrei
Re: std.mixins
Nick Sabalausky: But I also remember a certain someone (me!...plus some others) saying that .1 and 1. float literals are completely worthless and in the face of ambiguity with *useful* things, they need to DIE DIE DIE!!! See the second part of this (closed) enhancement request of mine :-) http://d.puremagic.com/issues/show_bug.cgi?id=3837 Bye, bearophile
Re: [D.typesystem] Suggestion for improving OO inheritance models
Wed, 01 Sep 2010 23:30:08 +0200, Jacob Carlborg wrote:
On 2010-09-01 22:44, Philippe Sigaud wrote:
On Wed, Sep 1, 2010 at 18:13, retard r...@tard.com.invalid wrote:
Have you taken a loot at Scala traits already? It would be a
great starting point.
Scala's traits are great! Implicits in Scala are quite interesting too.
Also, Haskell typeclasses
I wonder if D can have part of Scala traits functionality with mixins?
You can't use D template mixins to add methods that will overload
existing methods.
I'm afraid D's template mixins are like a poor man's copy/paste macro
system. Scala's approach takes subtyping into account. D 2 took a step
towards traits actually since it allows some implementations contracts
in interfaces. However, Scala is more flexible. Scala's design had the
focus on nice OOP properties the whole time, but D will probably only get
features if implementing them efficiently is a low hanging fruit.
One interesting feature in Scala are the types of objects in this case:
class A {}
trait T {}
class B extends A with T {}
val foo = (new B) : (A with T)
--
I suppose D doesn't allow this:
class A {}
interface T {}
class B : A, T {}
(A T) foo = new B
In Scala the inheritance graph looks like:
Any
|
AnyRef
|
Object
|
A T
| /
A with T
|
B
In D it's just:
Object
|
A T
| /
B
Re: [D.typesystem] Suggestion for improving OO inheritance models
On 9/1/10 16:56 CDT, retard wrote: Wed, 01 Sep 2010 23:30:08 +0200, Jacob Carlborg wrote: On 2010-09-01 22:44, Philippe Sigaud wrote: On Wed, Sep 1, 2010 at 18:13, retardr...@tard.com.invalid wrote: Have you taken a loot at Scala traits already? It would be a great starting point. Scala's traits are great! Implicits in Scala are quite interesting too. Also, Haskell typeclasses I wonder if D can have part of Scala traits functionality with mixins? You can't use D template mixins to add methods that will overload existing methods. I'm afraid D's template mixins are like a poor man's copy/paste macro system. Scala's approach takes subtyping into account. D 2 took a step towards traits actually since it allows some implementations contracts in interfaces. However, Scala is more flexible. Scala's design had the focus on nice OOP properties the whole time, but D will probably only get features if implementing them efficiently is a low hanging fruit. I agree. Traits are my favorite feature of Scala and probably the main modeling advantage that Scala has over D and other languages. A carefully designed feature for the win. Scala-style mixins aren't very difficult to implement for D, but I'm not sure if something like this would happen soon. Andrei
Re: Bug 3999 and 4261
Andrei: I think it's a good enhancement. Good :-) C++'s good old enum has been instrumental in finding a few bugs and clarifying a few interfaces in a project at work. Based on that experience I'd say that there's a chance more restrictive is better. There is also the experience of the C++0x group of designers, and their enum class. One of the purpose of those enum class is to remove implicit conversions to int: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1719.pdf We need to find a principled way to define semantics though - if we disable comparison it really means we're disabling implicit conversion. I agree. If bug bug 3999 gets accepted in the form I meant, then probably the bug 4261 too may be considered, because then enums aren't ints and the most natural way to print them on default is by name and not by hidden representation value: http://d.puremagic.com/issues/show_bug.cgi?id=4261 It's bound to break some code. Yes, several of the about 25 entries of my 'short list' I have recently shown here are able to break some code. This is why I am showing them here now. I think of those bug reports are more important than the others I have put in Bugzilla because as more and more D2 code gets written, even tiny breaking changes become harder and harder to justify. Bye, bearophile
The new Mono GC
Is it possible to try to replace (or just perform experiments) the D GC with this one? http://developers.sones.de/2010/09/01/taking-the-new-and-shiny-mono-simple-generational-garbage-collector-mono-sgen-for-a-walk/ Delegating the creation and management of the D GC to someone else (the Mono team) sounds like a possible way to have a good enough GC. Bye, bearophile
Re: [OT] Dark Star (1974) - the platinum age of movies
Russel Winder wrote: Extremely serious low budget though -- everyone needs to remember that when watching (1974, so pre Star Wars, and a very, very low budget). Dark Star and the Star Wars prequels prove that big budgets aren't what make a movie, a plot and good writing is.
Re: [OT] Dark Star (1974) - the platinum age of movies
On Thu, 02 Sep 2010 02:05:53 +0300, Walter Bright newshou...@digitalmars.com wrote: Russel Winder wrote: Extremely serious low budget though -- everyone needs to remember that when watching (1974, so pre Star Wars, and a very, very low budget). Dark Star and the Star Wars prequels prove that big budgets aren't what make a movie, a plot and good writing is. If you ignore the Harrison Ford factor, SW is nothing but a soap opera to me... Then you watch Bladerunner, Alien... now they are truly awesome! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Reporting TDPL bugs in Bugzilla
On 01/09/10 21:50, Stanislav Blinov wrote: Is it just me, or spam bots suddenly became incredibly clever? You call that clever? O_o For a bot. It almost seems as there is some intelligence behind this. Well, a little too almost, maybe. I checked and bug #1 isn't actually give up already, but I'm now tempted to file that bug, just so it can get marked wontfix. There's something nice and defiant about that.
Re: [OT] Dark Star (1974) - the platinum age of movies
On Wednesday, September 01, 2010 16:17:42 so wrote: On Thu, 02 Sep 2010 02:05:53 +0300, Walter Bright newshou...@digitalmars.com wrote: Russel Winder wrote: Extremely serious low budget though -- everyone needs to remember that when watching (1974, so pre Star Wars, and a very, very low budget). Dark Star and the Star Wars prequels prove that big budgets aren't what make a movie, a plot and good writing is. If you ignore the Harrison Ford factor, SW is nothing but a soap opera to me... Then you watch Bladerunner, Alien... now they are truly awesome! Actually, he specifically mentioned the prequels, not the original trilogy, so unless Dark Star has Harrison Ford in it (I haven't seen it, but I'm pretty sure that he's not in it), there is no Harrison Ford factor with the movies that he mentioned. I think his point was that while the Star Wars prequels had large budgets, they weren't all that good, while Dark Star was good in spite of having a small budget. So, the budget doesn't necessarily have anything to do with the quality of the movie. - Jonathan M Davis
Re: [Slight OT] TDPL in Russia
Hello Walter, Steven Schveighoffer wrote: I was just employing irony and sarcasm to demonstrate why your arguments were meaningless :) The only measurable factor for good art is how many people use it/buy it. For-sale software, books, movies do rather well, so I'm inclined to believe they are pretty good. There are also some open source/free materials that do rather well, but they are not nearly as common as free materials that are crappy. My point was that for-sale art by far outperforms freely available art in popularity and usage. When you get paid to make something, you can do it more often, you get better at it, and your quality of work goes up. Someone once told me that capitalism doesn't support the arts. I asked him how the Beatles got rich. Oops! There's a subgroup of the theater crowd around here who regard producers as sellouts if their plays actually attract an audience. OTOH try and write a play that no one will watch. I'd be very surprised if it can be done. -- ... IXOYE
Re: [Slight OT] TDPL in Russia
Hello Jonathan, Capitalism definitely supports them. However, if you're dealing with less well-known, less generally-liked stuff, then capitalism isnt't really going to support it. Amazon.com enters, stage right. There's a subgroup of the theater crowd around here who regard producers as sellouts if their plays actually attract an audience. I hear that this sort of thing tends to happen with Indie artists as well. There are fans who like them until they get popular. I guess that there are people who _like_ it when the stuff that they like is niche. And there are people who will buy $5 a cup coffee when they really do like the $.50 stuff better. They are called snobs. -- ... IXOYE
Re: [Slight OT] TDPL in Russia
On Wednesday, September 01, 2010 18:56:03 BCS wrote: OTOH try and write a play that no one will watch. I'd be very surprised if it can be done. LOL. There would always be someone who would want to watch it simply because no one else wants to. - Jonathan M Davis
