www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Open source dmd on Reddit!

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/82ck4/digitalmars_d_now_open_source/

http://www.reddit.com/r/programming/comments/82cgp/new_release_of_the_d_programming_language_now/
Mar 05 2009
next sibling parent reply hasen <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/82ck4/digitalmar
_d_now_open_source/ 
 
 
 http://www.reddit.com/r/programming/comments/82cgp/new_release_of_the_d_progr
mming_language_now/ 
 
Wow there's a big fuss over there about it not being /really/ open source, Can you explain (to the ignorant likes of me) what is constraining you from changing the license?
Mar 05 2009
next sibling parent reply grauzone <none example.net> writes:
hasen wrote:
 Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/82ck4/digitalmar
_d_now_open_source/ 


 http://www.reddit.com/r/programming/comments/82cgp/new_release_of_the_d_progr
mming_language_now/ 
Wow there's a big fuss over there about it not being /really/ open source,
To us, this doesn't really matter. The important thing is that we can build the compiler itself, and can debug it if it craps up (which happens often, sorry Walter). For example, now we might be able to find out on which piece of code exactly it segfaults when compiling. Oh, and remember the libc issues. Now users affected by this problem can compile their own binary. When we want a completely free compiler for ideological reasons or for unrestricted redistribution, there's still LDC. LDC connects the free (GPL'ed) frontend with the free LLVM backend. Also, I thought open source != free software.
 Can you explain (to the ignorant likes of me) what is constraining you 
 from changing the license?
Mar 05 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 To us, this doesn't really matter. The important thing is that we can 
 build the compiler itself, and can debug it if it craps up (which 
 happens often, sorry Walter). For example, now we might be able to find 
 out on which piece of code exactly it segfaults when compiling. Oh, and 
 remember the libc issues. Now users affected by this problem can compile 
 their own binary.
Making the source available deals with the following: 1. people can be assured there's no hanky-panky going on in the code - no spyware, trojans, back doors, phone homing, etc. 2. if there's a serious problem, users can apply a patch themselves rather than wait around for me 3. if Digital Mars vanishes in a puff of greasy black smoke, users depending on dmd are not left holding the bag 4. makes custom ports the user cares about but nobody else does possible 5. engineers are curious and like to peek under the hood <g>. 6. hopefully it will make finding and correcting problems faster as people can build it with symbolic debug info, and submit patches 7. allow for two way feedback on it, which should improve the quality What it doesn't do is: 1. allow redistribution without getting an additional license from D.M. What I should also say is the back end was built without ever expecting it to be open source, hence the comments are generally notes to myself. It's pretty dense, not very attractive, and full of bad style and detritus. However, it does work. I also need to point out that in various places there are contributions by Pat Nelson (initial elf work), Mike Cote and John Micco (inline assembler). The instruction scheduler is based on ideas of Steve Russell's.
Mar 05 2009
parent Gregor Richards <Richards codu.org> writes:
Walter Bright wrote:
 3. if Digital Mars vanishes in a puff of greasy black smoke, users 
 depending on dmd are not left holding the bag
 
Without redistribution rights, yes they are. All they can do is say "Anybody who was lucky enough to download DMD before Digital Mars exploded, you can apply these patches. Everybody else, too bad." - Gregor Richards
Mar 07 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
grauzone wrote:
 hasen wrote:
 Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/82ck4/digitalmar
_d_now_open_source/ 


 http://www.reddit.com/r/programming/comments/82cgp/new_release_of_the_d_progr
mming_language_now/ 
Wow there's a big fuss over there about it not being /really/ open source,
To us, this doesn't really matter. The important thing is that we can build the compiler itself, and can debug it if it craps up (which happens often, sorry Walter). For example, now we might be able to find out on which piece of code exactly it segfaults when compiling. Oh, and remember the libc issues. Now users affected by this problem can compile their own binary. When we want a completely free compiler for ideological reasons or for unrestricted redistribution, there's still LDC. LDC connects the free (GPL'ed) frontend with the free LLVM backend. Also, I thought open source != free software.
Correct. Those guys don't know what open source is, apparently. And it's free, too. BTW, I think it's legal to distribute patches. As long as digitalmars.com stays online, you can distribute an updated compiler, just by telling everyone to download the code from digitalmars, then apply the patches. This would allow development to continue if Walter was captured by Martians. So I don't think the license is very restrictive at all.
 
 Can you explain (to the ignorant likes of me) what is constraining you 
 from changing the license?
Mar 06 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 BTW, I think it's legal to distribute patches. As long as 
 digitalmars.com stays online, you can distribute an updated compiler, 
 just by telling everyone to download the code from digitalmars, then 
 apply the patches.
Yes, that would be perfectly legal as I understand it.
Mar 06 2009
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 05 Mar 2009 23:25:04 +0100, grauzone wrote:

 hasen wrote:
 Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/82ck4/
digitalmars_d_now_open_source/
 http://www.reddit.com/r/programming/comments/82cgp/
new_release_of_the_d_programming_language_now/

 Wow there's a big fuss over there about it not being /really/ open
 source,
To us, this doesn't really matter. The important thing is that we can build the compiler itself, and can debug it if it craps up (which happens often, sorry Walter). For example, now we might be able to find out on which piece of code exactly it segfaults when compiling. Oh, and remember the libc issues. Now users affected by this problem can compile their own binary. When we want a completely free compiler for ideological reasons or for unrestricted redistribution, there's still LDC. LDC connects the free (GPL'ed) frontend with the free LLVM backend. Also, I thought open source != free software.
 Can you explain (to the ignorant likes of me) what is constraining you
 from changing the license?
Open Source = Free really has to do with how you define open source. And the definition that most OSS advocates use can be found on wikipedia http://en.wikipedia.org/wiki/Open_Source_Definition "1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. " So it basically needs to be free in all senses of the word. I disagree but many others seem to hold this view. I don't know why they don't just call it "free software."
Mar 06 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Jesse Phillips" <jessekphillips gmail.com> wrote in message 
news:gosuaj$2qdu$1 digitalmars.com...
 So it basically needs to be free in all senses of the word. I disagree
 but many others seem to hold this view. I don't know why they don't just
 call it "free software."
IIRC, Once upon a time, it was like that. "Open source" meant "source is available at no cost". "Free-as-in-freedom software" meant "A superset of 'open-source', plus other freedoms such as redistro." I think a lot of the people that got into the Linux/OSS/Slashdot/etc scenes in the last few years never actually learned the difference and thus go running around equating "open source" with GPL/zlib/BSD/etc.
Mar 06 2009
parent Gregor Richards <Richards codu.org> writes:
Nick Sabalausky wrote:
 "Jesse Phillips" <jessekphillips gmail.com> wrote in message 
 news:gosuaj$2qdu$1 digitalmars.com...
 So it basically needs to be free in all senses of the word. I disagree
 but many others seem to hold this view. I don't know why they don't just
 call it "free software."
IIRC, Once upon a time, it was like that. "Open source" meant "source is available at no cost". "Free-as-in-freedom software" meant "A superset of 'open-source', plus other freedoms such as redistro." I think a lot of the people that got into the Linux/OSS/Slashdot/etc scenes in the last few years never actually learned the difference and thus go running around equating "open source" with GPL/zlib/BSD/etc.
Uhhhhh, no. The Open Source Definition, created by the Open Source Initiative which effectively created the term in 1998 (there was no real use of the term before then), requires redistribution, etc, and the term Open Source is trademarked. It's in violation of their trademark to use the term to describe anything that doesn't follow the definition, which is roughly equivalent to what FSF describes as Free Software (modulo a few quirks) The reason that people equate the term with those particular licenses is because those particular licenses are approved by the OSI, so you can't possibly run into any troubles using the term referring to them. But software for which the source is readable but not redistributable is NOT Open Source. - Gregor Richards
Mar 07 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
hasen wrote:
 Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/82ck4/digitalmar
_d_now_open_source/ 


 http://www.reddit.com/r/programming/comments/82cgp/new_release_of_the_d_progr
mming_language_now/ 
Wow there's a big fuss over there about it not being /really/ open source,
Seems kind of silly to me. The big deal with the full source for DMD being available is that if DigitalMars disappears in a puff of smoke tomorrow, customers have a means of preserving their investment in the language. This can be a big deal for corporate users.
Mar 05 2009
next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Fri, Mar 6, 2009 at 4:42 AM, Sean Kelly <sean invisibleduck.org> wrote:
 hasen wrote:
 Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/82ck4/digitalmars_d_now_op=
en_source/
 http://www.reddit.com/r/programming/comments/82cgp/new_release_of_the_d=
_programming_language_now/
 Wow there's a big fuss over there about it not being /really/ open sourc=
e,
 Seems kind of silly to me. =C2=A0The big deal with the full source for DM=
D being
 available is that if DigitalMars disappears in a puff of smoke tomorrow,
 customers have a means of preserving their investment in the language. =
=C2=A0This
 can be a big deal for corporate users.
I'm not sure I see the big value here. If Digital Mars indeed went up in smoke some day, how will the source help? They're still not allowed to do anything but "personal use" with it... Or am I missing something ? -Tomas
Mar 05 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Tomas Lindquist Olsen wrote:
 On Fri, Mar 6, 2009 at 4:42 AM, Sean Kelly <sean invisibleduck.org> wrote:
 hasen wrote:
 Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/82ck4/digitalmars_d_now_open_source/


 http://www.reddit.com/r/programming/comments/82cgp/new_release_of_the_d_programming_language_now/
Wow there's a big fuss over there about it not being /really/ open source,
Seems kind of silly to me. The big deal with the full source for DMD being available is that if DigitalMars disappears in a puff of smoke tomorrow, customers have a means of preserving their investment in the language. This can be a big deal for corporate users.
I'm not sure I see the big value here. If Digital Mars indeed went up in smoke some day, how will the source help? They're still not allowed to do anything but "personal use" with it...
If they're just building apps then all they need it for is "personal use."
Mar 05 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Sean Kelly wrote:
 The big deal with the full source for DMD being available is that if
 DigitalMars disappears in a puff of smoke tomorrow, customers have a
 means of preserving their investment in the language.
I just hope Walter survives!
Mar 05 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Georg Wrede wrote:
 Sean Kelly wrote:
 The big deal with the full source for DMD being available is that if
 DigitalMars disappears in a puff of smoke tomorrow, customers have a
 means of preserving their investment in the language.
I just hope Walter survives!
Well yeah. But that's the sort of question that comes up when evaluating technology for a large project. It's a big selling point for Linux, etc, over Windows, for example as well.
Mar 05 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Seems kind of silly to me.  The big deal with the full source for DMD 
 being available is that if DigitalMars disappears in a puff of smoke 
 tomorrow, customers have a means of preserving their investment in the 
 language.  This can be a big deal for corporate users.
Back in the 80's when I started out in the compiler business, we'd often get companies calling us up with: "we really like your compiler, but there's one little issue, it needs to be modified to do X. If it does X, we'd buy 1000/5000/10000 copies!" So I'd modify it to do X, and breathlessly contact them: "it does X now! where's the P.O? We're ready to ship!" Then they'd hem and haw a bit, and say: "X is cool, great, yeah, but we really also need Y!" It became clear after a while that they never had any intention of buying any copies. There are a lot of possible reasons why they were jerking our chain, but the strategy we came up with was: "sure, we'd love to do X for you, our consulting rates are $$$ and we estimate xxx hours to do the job. We need a down payment to start work." If they were serious, no problem, we did good business with them. The ones who were jerking us around for whatever reason went away. There are people who won't use D, ever, no matter what we do, even if it spit out gold bars and ended world hunger. But they won't say that, they'll just sit on the sidelines and throw potshots. It comes with the territory of building a disruptive technology. The ones I listen to are the ones who *are* using D and have some sweat equity in it.
Mar 05 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 06 Mar 2009 08:51:57 +0300, Walter Bright <newshound1 digitalmars.com>
wrote:

[snip]
 The ones I listen to are the ones who *are* using D and have some sweat  
 equity in it.
http://www.micropoll.com/akira/mpresult/539369-138652
Mar 06 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:
 On Fri, 06 Mar 2009 08:51:57 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 [snip]
 The ones I listen to are the ones who *are* using D and have some 
 sweat equity in it.
http://www.micropoll.com/akira/mpresult/539369-138652
<g>
Mar 06 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Denis Koroskin wrote:
 On Fri, 06 Mar 2009 08:51:57 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 [snip]
 The ones I listen to are the ones who *are* using D and have some 
 sweat equity in it.
http://www.micropoll.com/akira/mpresult/539369-138652
Bipolar folks the Americans. All of the states are either 100% for or against...
Mar 06 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Georg Wrede wrote:
 Denis Koroskin wrote:
 On Fri, 06 Mar 2009 08:51:57 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 [snip]
 The ones I listen to are the ones who *are* using D and have some 
 sweat equity in it.
http://www.micropoll.com/akira/mpresult/539369-138652
Bipolar folks the Americans. All of the states are either 100% for or against...
Don't forget arrogant. They don't care what the rest of the world thinks, which is why the map only shows the US ;). (My vote isn't on there...)
Mar 06 2009
parent reply Don <nospam nospam.com> writes:
Frits van Bommel wrote:
 Georg Wrede wrote:
 Denis Koroskin wrote:
 On Fri, 06 Mar 2009 08:51:57 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 [snip]
 The ones I listen to are the ones who *are* using D and have some 
 sweat equity in it.
http://www.micropoll.com/akira/mpresult/539369-138652
Bipolar folks the Americans. All of the states are either 100% for or against...
Don't forget arrogant. They don't care what the rest of the world thinks, which is why the map only shows the US ;). (My vote isn't on there...)
It told me I live in Bayern! (I don't).
Mar 07 2009
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Don wrote:
 
 It told me I live in Bayern! (I don't).
It got the specific location wrong for me too (wrong province, but close).
Mar 08 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Seems kind of silly to me.  The big deal with the full source for DMD 
 being available is that if DigitalMars disappears in a puff of smoke 
 tomorrow, customers have a means of preserving their investment in the 
 language.  This can be a big deal for corporate users.
Back in the 80's when I started out in the compiler business, we'd often get companies calling us up with: "we really like your compiler, but there's one little issue, it needs to be modified to do X. If it does X, we'd buy 1000/5000/10000 copies!" So I'd modify it to do X, and breathlessly contact them: "it does X now! where's the P.O? We're ready to ship!" Then they'd hem and haw a bit, and say: "X is cool, great, yeah, but we really also need Y!" It became clear after a while that they never had any intention of buying any copies. There are a lot of possible reasons why they were jerking our chain, but the strategy we came up with was: "sure, we'd love to do X for you, our consulting rates are $$$ and we estimate xxx hours to do the job. We need a down payment to start work." If they were serious, no problem, we did good business with them. The ones who were jerking us around for whatever reason went away. There are people who won't use D, ever, no matter what we do, even if it spit out gold bars and ended world hunger. But they won't say that, they'll just sit on the sidelines and throw potshots. It comes with the territory of building a disruptive technology. The ones I listen to are the ones who *are* using D and have some sweat equity in it.
"Can't live without bitfields! Give me bitfields and I'll lift the Earth!" "Here they are, std.bitmanip. Well-defined and more portable and flexible than C's." "Meh, don't like the definition syntax." Andrei
Mar 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the Earth!"
 
 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."
 
 "Meh, don't like the definition syntax."
Classic.
Mar 06 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-03-06 14:35:59 -0500, Walter Bright <newshound1 digitalmars.com> said:

 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the Earth!"
 
 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."
 
 "Meh, don't like the definition syntax."
Classic.
Well, he certainly has a point. Compare this: mixin(bitfields!( uint, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable. Does it matter much? Not to me; I rarely use bit fields. If I were using them a lot, perhaps I'd be more concerned. While I don't care very much about bitfields, that "mixin(tmpl!(...))" syntax is awful. "mixin tmpl!(...)" is better, but has too many limitations, and it isn't always clear for the user which one should be used. Couldn't D2 get a better syntax for mixins? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 06 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Michel Fortin escribió:
 On 2009-03-06 14:35:59 -0500, Walter Bright <newshound1 digitalmars.com> 
 said:
 
 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the 
 Earth!"

 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."

 "Meh, don't like the definition syntax."
Classic.
Well, he certainly has a point. Compare this: mixin(bitfields!( uint, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable. Does it matter much? Not to me; I rarely use bit fields. If I were using them a lot, perhaps I'd be more concerned. While I don't care very much about bitfields, that "mixin(tmpl!(...))" syntax is awful. "mixin tmpl!(...)" is better, but has too many limitations, and it isn't always clear for the user which one should be used. Couldn't D2 get a better syntax for mixins?
Well, now the \ is character if free: \bitfields( unit, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1, ); But I think it looks ugly: the \ is "lambda" in some languages and this also reminds me of LaTeX... :-P
Mar 06 2009
parent reply grauzone <none example.net> writes:
Ary Borenszweig wrote:
 Michel Fortin escribió:
 On 2009-03-06 14:35:59 -0500, Walter Bright 
 <newshound1 digitalmars.com> said:

 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the 
 Earth!"

 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."

 "Meh, don't like the definition syntax."
Classic.
Well, he certainly has a point. Compare this: mixin(bitfields!( uint, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable. Does it matter much? Not to me; I rarely use bit fields. If I were using them a lot, perhaps I'd be more concerned. While I don't care very much about bitfields, that "mixin(tmpl!(...))" syntax is awful. "mixin tmpl!(...)" is better, but has too many limitations, and it isn't always clear for the user which one should be used. Couldn't D2 get a better syntax for mixins?
Well, now the \ is character if free: \bitfields( unit, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1, ); But I think it looks ugly: the \ is "lambda" in some languages and this also reminds me of LaTeX... :-P
String mixins are awful in the first place. The only thing that could save this kind of thing are AST macros.
Mar 06 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from grauzone (none example.net)'s article
 Ary Borenszweig wrote:
 Michel Fortin escribió:
 On 2009-03-06 14:35:59 -0500, Walter Bright
 <newshound1 digitalmars.com> said:

 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the
 Earth!"

 "Here they are, std.bitmanip. Well-defined and more portable and
 flexible than C's."

 "Meh, don't like the definition syntax."
Classic.
Well, he certainly has a point. Compare this: mixin(bitfields!( uint, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable. Does it matter much? Not to me; I rarely use bit fields. If I were using them a lot, perhaps I'd be more concerned. While I don't care very much about bitfields, that "mixin(tmpl!(...))" syntax is awful. "mixin tmpl!(...)" is better, but has too many limitations, and it isn't always clear for the user which one should be used. Couldn't D2 get a better syntax for mixins?
Well, now the \ is character if free: \bitfields( unit, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1, ); But I think it looks ugly: the \ is "lambda" in some languages and this also reminds me of LaTeX... :-P
String mixins are awful in the first place. The only thing that could save this kind of thing are AST macros.
????????????? String mixins are an absolute godsend. I mean really, how much more general a metaprogramming facility could you possibly ask for than the ability to generate arbitrary D code at compile time? Of course they can get ugly, so there should be better ways to do things that are done frequently (regular templates accomplish this), but last I checked, bit fields are not an everyday run-of-the-mill programming type of feature. As a more general comment, of course syntax and readability count for frequently used features, but there's only so much pretty syntax available, and simplicity of the core language is a virtue. If certain things in D are going to have ugly syntax, they may as well be niche features like bit fields.
Mar 06 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:got0ff$28r4$1 digitalmars.com...
 == Quote from grauzone (none example.net)'s article
 String mixins are awful in the first place. The only thing that could
 save this kind of thing are AST macros.
Both Murphey's law and the law of D bitfields dictate that we're all going to end up hating AST macros when they finally show up ;)
 ????????????? String mixins are an absolute godsend.  I mean really, how 
 much more
 general a metaprogramming facility could you possibly ask for than the 
 ability to
 generate arbitrary D code at compile time?  Of course they can get ugly, 
 so there
 should be better ways to do things that are done frequently (regular 
 templates
 accomplish this), but last I checked, bit fields are not an everyday
 run-of-the-mill programming type of feature.

 As a more general comment, of course syntax and readability count for 
 frequently
 used features, but there's only so much pretty syntax available, and 
 simplicity of
 the core language is a virtue.  If certain things in D are going to have 
 ugly
 syntax, they may as well be niche features like bit fields.
My thought is that it's absolutely great to have string mixins, but they should never be thought of as anything more than a clumbsy substitute (athough notably less clumbsy than a preprocessor macro) for a real language feature to accomplish the same task (or possibly an AST macro).
Mar 06 2009
parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 "dsimcha" <dsimcha yahoo.com> wrote in message 
 news:got0ff$28r4$1 digitalmars.com...
 == Quote from grauzone (none example.net)'s article
 String mixins are awful in the first place. The only thing that could
 save this kind of thing are AST macros.
Both Murphey's law and the law of D bitfields dictate that we're all going to end up hating AST macros when they finally show up ;)
 ????????????? String mixins are an absolute godsend.  I mean really, how 
 much more
 general a metaprogramming facility could you possibly ask for than the 
 ability to
 generate arbitrary D code at compile time?  Of course they can get ugly, 
 so there
 should be better ways to do things that are done frequently (regular 
 templates
 accomplish this), but last I checked, bit fields are not an everyday
 run-of-the-mill programming type of feature.

 As a more general comment, of course syntax and readability count for 
 frequently
 used features, but there's only so much pretty syntax available, and 
 simplicity of
 the core language is a virtue.  If certain things in D are going to have 
 ugly
 syntax, they may as well be niche features like bit fields.
My thought is that it's absolutely great to have string mixins, but they should never be thought of as anything more than a clumbsy substitute (athough notably less clumbsy than a preprocessor macro) for a real language feature to accomplish the same task (or possibly an AST macro).
Sure, they're open to _severe_ abuse, but for the case when they are used to generate source code (eg, from a DSL), they are absolutely perfect, and not a hack at all. In that particular scenario, they are much better than AST macros could ever be. They're a replacement for creating a text file, adding a line to your makefile in order to invoke a program to read the text file and spit out a d source file, then add another line in the makefile to compile that d file, then link it in, and try to integrate the whole thing seamlessly. They're a beautiful solution to a really ugly problem. It's not fair to regard them simply as a hack to get around language limitations.
Mar 09 2009
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
 Sure, they're open to _severe_ abuse, but for the case when they are 
 used to generate source code (eg, from a DSL), they are absolutely 
 perfect, and not a hack at all. In that particular scenario, they are 
 much better than AST macros could ever be.
 
 They're a replacement for creating a text file, adding a line to your 
 makefile in order to invoke a program to read the text file and spit out 
 a d source file, then add another line in the makefile to compile that d 
 file, then link it in, and try to integrate the whole thing seamlessly. 
 They're a beautiful solution to a really ugly problem.
 
 It's not fair to regard them simply as a hack to get around language 
 limitations.
Walter - please add this perfect description to the mixin page ;-)
Mar 09 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 They're a replacement for creating a text file, adding a line to your 
 makefile in order to invoke a program to read the text file and spit out 
 a d source file, then add another line in the makefile to compile that d 
 file, then link it in, and try to integrate the whole thing seamlessly. 
 They're a beautiful solution to a really ugly problem.
If you look at the dmd source, there are some sub-builds in there the only purpose of which is to spit out C source code which is then compiled into dmd.
Mar 09 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2009-03-06 14:35:59 -0500, Walter Bright <newshound1 digitalmars.com> 
 said:
 
 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the 
 Earth!"

 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."

 "Meh, don't like the definition syntax."
Classic.
Well, he certainly has a point. Compare this: mixin(bitfields!( uint, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable.
(Just to clarify: to me the humor of the situation was that someone who considered bitfields an absolute prerequisite for language adoption subsequently found the syntax excuse to bail out. Essentially the hypothetical user was fabricating one pretext after another to rationalize their pre-made decision to not try D -- an absolute classic attitude when it comes about acquiring new programming languages.) About the syntax itself - definitions are few and uses are many. In addition the D solution: (a) guarantees data layout; (b) offers symbolic limits, e.g. x_max and x_min are automatically added as enums; (c) checks for overflow, which is essential for small bitfields; (d) offers a way to manipulate the fields wholesale by using the concatenation of all their names, e.g. xyzflag; (e) suggests that there are other cool things that can be done within the language, not by adding features to it. Hopefully that makes up for the more loaded syntax.
 Does it matter much? Not to me; I rarely use bit fields. If I were using 
 them a lot, perhaps I'd be more concerned.
I am using them here and there - even in Phobos - and they work very well.
 While I don't care very much about bitfields, that "mixin(tmpl!(...))" 
 syntax is awful. "mixin tmpl!(...)" is better, but has too many 
 limitations, and it isn't always clear for the user which one should be 
 used. Couldn't D2 get a better syntax for mixins?
I agree it should. Andrei
Mar 06 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gossg8$2qj8$1 digitalmars.com...
 Michel Fortin wrote:
 On 2009-03-06 14:35:59 -0500, Walter Bright <newshound1 digitalmars.com> 
 said:

 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the 
 Earth!"

 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."

 "Meh, don't like the definition syntax."
Classic.
Well, he certainly has a point. Compare this: mixin(bitfields!( uint, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable.
(Just to clarify: to me the humor of the situation was that someone who considered bitfields an absolute prerequisite for language adoption subsequently found the syntax excuse to bail out. Essentially the hypothetical user was fabricating one pretext after another to rationalize their pre-made decision to not try D -- an absolute classic attitude when it comes about acquiring new programming languages.)
I have a different theory that's based on my own experience from other languages/software/products/brands/etc. that I've disliked in the past: People come across a language (or anything else), see two or three things they really don't like, and think "Meh, not worth bothering to switch if I'd just be trading one set of complaints for another. I'll just stick with what I'm already using, but to be helpful, I'll point out the issues I have with it." If those issues were fixed at the time they said that, they probably would switch, but obviously it can't change instantaneously like that. So the things they disliked about it stick in their mind and leave them with a generally bad impression of the language (or product) for a few months or a couple years. Then, it finally gets fixed, but by that point they simply no longer care. Basically, it's the old "first impression" thing with a few wrinkles.
 About the syntax itself - definitions are few and uses are many. In 
 addition the D solution:

 (a) guarantees data layout;

 (b) offers symbolic limits, e.g. x_max and x_min are automatically added 
 as enums;

 (c) checks for overflow, which is essential for small bitfields;

 (d) offers a way to manipulate the fields wholesale by using the 
 concatenation of all their names, e.g. xyzflag;
These are all things that could be done with the old C-style syntax, provided it was built into the language. But of course, that strategy has it's own downsides, too.
 (e) suggests that there are other cool things that can be done within the 
 language, not by adding features to it.

 Hopefully that makes up for the more loaded syntax.

 Does it matter much? Not to me; I rarely use bit fields. If I were using 
 them a lot, perhaps I'd be more concerned.
I am using them here and there - even in Phobos - and they work very well.
Provided that they aren't as crappy as the ones in C, bitfields can be immensely useful for anything really low-level, like embedded systems, drivers, firmware, or packed data formats for network or file I/O (ie, "systems programming" stuff). Anything higher-level then that, though, and their usefulness certainly does seem to diminish.
 While I don't care very much about bitfields, that "mixin(tmpl!(...))" 
 syntax is awful. "mixin tmpl!(...)" is better, but has too many 
 limitations, and it isn't always clear for the user which one should be 
 used. Couldn't D2 get a better syntax for mixins?
I agree it should.
That would certainly be very nice.
Mar 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 Provided that they aren't as crappy as the ones in C, bitfields can be 
 immensely useful for anything really low-level, like embedded systems, 
 drivers, firmware, or packed data formats for network or file I/O (ie, 
 "systems programming" stuff). Anything higher-level then that, though, and 
 their usefulness certainly does seem to diminish.
I've written a lot of bit twiddling code. Bitfields are not immensely useful. They're at best a trivial convenience, and often result in poor code generation as compared with using bit masking operations.
Mar 06 2009
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Walter Bright wrote:
 Nick Sabalausky wrote:
 Provided that they aren't as crappy as the ones in C, bitfields can be 
 immensely useful for anything really low-level, like embedded systems, 
 drivers, firmware, or packed data formats for network or file I/O (ie, 
 "systems programming" stuff). Anything higher-level then that, though, 
 and their usefulness certainly does seem to diminish.
I've written a lot of bit twiddling code. Bitfields are not immensely useful. They're at best a trivial convenience, and often result in poor code generation as compared with using bit masking operations.
Bit fields are much less useful than they once were...because there's less need to pack storage tightly. The times I've really wanted to use named bit fields was when I was packing numbers into a word for export (usually to disk), or reading conversely. They were, indeed, only a convenience...but they were a significant convenience. I suppose that such occasions still arise when one is interacting with foreign code. But I don't like the syntax that D choose for this feature. (See my suggestions earlier in this thread as to what I would consider an improvement.) I'm much more interested in the general comments about what constitutes good syntax than in the specific commentary around bitfields. Perhaps there just *ISN'T* a good way to do templates & mixins. The syntaxes that I have encountered previously, including D's, have caused me to avoid all but the simplest cases of using them. I admit that they appear quite powerful (not really using them I can't say more than that), but they're UGLY. Well, habituation can change ones aesthetic sense, so that's not really objective. They look ugly to me at the present time, as they have for the past year. An additional problem is that generics are crippled when one of the basic types is desired as a parameter. Say you want a tree with keys sorted by uint. It should be possible to just write a generic sorted tree and specify the key. But Objects and ints have incompatible comparison mechanisms. The obvious fix to this would be to have the basic types all respond to, e.g., opCmp. Apparently, however, this would have significant costs. But the lack of this kind of mechanism renders templates significantly less useful to me than they would otherwise be. As always, these are relatively trivial problems. The major problem is the lack of libraries, and there doesn't seem to be any way around that except time. But the division between tango and phobos isn't making solving that any easier. (I'm afraid that I can't bring myself to trust tangobos. It always seems to be mentioned with a "you can use this until you really convert to tango" kind of comment.)
Mar 07 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Charles Hixson wrote:
 Walter Bright wrote:
 I've written a lot of bit twiddling code. Bitfields are not immensely 
 useful. They're at best a trivial convenience, and often result in 
 poor code generation as compared with using bit masking operations.
Bit fields are much less useful than they once were...because there's less need to pack storage tightly. The times I've really wanted to use named bit fields was when I was packing numbers into a word for export (usually to disk), or reading conversely. They were, indeed, only a convenience...but they were a significant convenience. I suppose that such occasions still arise when one is interacting with foreign code.
I think bitfields are very useful on today's architectures, where memory bandwidth is scarce and processor ops (masking etc.) are virtually free. Whenever I have a struct that I pass around by value in speed-sensitive code, I use bitfields if applicable.
 But I don't like the syntax that D choose for this feature.  (See my 
 suggestions earlier in this thread as to what I would consider an 
 improvement.)
 
 I'm much more interested in the general comments about what constitutes 
 good syntax than in the specific commentary around bitfields.
 
 Perhaps there just *ISN'T* a good way to do templates & mixins.  The 
 syntaxes that I have encountered previously, including D's, have caused 
 me to avoid all but the simplest cases of using them.  I admit that they 
 appear quite powerful (not really using them I can't say more than 
 that), but they're UGLY.  Well, habituation can change ones aesthetic 
 sense, so that's not really objective.  They look ugly to me at the 
 present time, as they have for the past year.
 
 An additional problem is that generics are crippled when one of the 
 basic types is desired as a parameter.  Say you want a tree with keys 
 sorted by uint.  It should be possible to just write a generic sorted 
 tree and specify the key.  But Objects and ints have incompatible 
 comparison mechanisms.  The obvious fix to this would be to have the 
 basic types all respond to, e.g., opCmp.  Apparently, however, this 
 would have significant costs.  But the lack of this kind of mechanism 
 renders templates significantly less useful to me than they would 
 otherwise be.
What happened to a < b? I don't quite get it. Andrei
Mar 07 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Charles Hixson wrote:
 Perhaps there just *ISN'T* a good way to do templates & mixins.  The 
 syntaxes that I have encountered previously, including D's, have caused 
 me to avoid all but the simplest cases of using them.  I admit that they 
 appear quite powerful (not really using them I can't say more than 
 that), but they're UGLY.  Well, habituation can change ones aesthetic 
 sense, so that's not really objective.  They look ugly to me at the 
 present time, as they have for the past year.
templates and mixins were designed fairly independently of each other, without much of any existing practice to see how it should be done, so it's not a big surprise that they may not fit together that nicely.
 As always, these are relatively trivial problems.  The major problem is 
 the lack of libraries, and there doesn't seem to be any way around that 
 except time.  But the division between tango and phobos isn't making 
 solving that any easier.  (I'm afraid that I can't bring myself to trust 
 tangobos.  It always seems to be mentioned with a "you can use this 
 until you really convert to tango" kind of comment.)
Sean Kelly has put together druntime, which provides a common root for phobos and tango so they can work together.
Mar 07 2009
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Andrei Alexandrescu wrote:
 Michel Fortin wrote:
 On 2009-03-06 14:35:59 -0500, Walter Bright 
 <newshound1 digitalmars.com> said:

 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the 
 Earth!"

 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."

 "Meh, don't like the definition syntax."
Classic.
Well, he certainly has a point. Compare this: mixin(bitfields!( uint, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable.
(Just to clarify: to me the humor of the situation was that someone who considered bitfields an absolute prerequisite for language adoption subsequently found the syntax excuse to bail out. Essentially the hypothetical user was fabricating one pretext after another to rationalize their pre-made decision to not try D -- an absolute classic attitude when it comes about acquiring new programming languages.) About the syntax itself - definitions are few and uses are many. In addition the D solution: (a) guarantees data layout; (b) offers symbolic limits, e.g. x_max and x_min are automatically added as enums; (c) checks for overflow, which is essential for small bitfields; (d) offers a way to manipulate the fields wholesale by using the concatenation of all their names, e.g. xyzflag; (e) suggests that there are other cool things that can be done within the language, not by adding features to it. Hopefully that makes up for the more loaded syntax.
 Does it matter much? Not to me; I rarely use bit fields. If I were 
 using them a lot, perhaps I'd be more concerned.
I am using them here and there - even in Phobos - and they work very well.
 While I don't care very much about bitfields, that "mixin(tmpl!(...))" 
 syntax is awful. "mixin tmpl!(...)" is better, but has too many 
 limitations, and it isn't always clear for the user which one should 
 be used. Couldn't D2 get a better syntax for mixins?
I agree it should. Andrei
I'm glad that they're there. And I'm glad that they work. But I really hate the syntax, and am glad I've never needed to use them. MUCH better would have been: mixin(bitfields!(" uint, x, 2, int, y, 3, uint, z, 2, bool, flag, 1 ") even better would have been: mixin(bitfields!(" uint x : 2, int y : 3, uint z : 2, bool flag : 1 ") The bitfield battle isn't one I'm involved with, and I rarely comment on syntax...but this is, to my mind, a much nicer syntax. Moving the quote marks to a pre-existing boundary location and removing them internally is a large gain. There is a small further gain in specifying the bit-field as a type-name : length string. The colon is a slightly better delimiter to use here than the comma, as the comma is being used as the separator between individual bit field specifications. A further gain is that it's more similar to a form already known by many people. I'm not a compiler writer, so I don't know if this would have been difficult. I just know that looking at it *I* find it much more readable. Another step might have been to allow the entire string to end with a comma, thus: mixin(bitfields!(" uint x : 2, int y : 3, uint z : 2, bool flag : 1, ") so that it would be easier to shuffle the fields during development. This has it's pluses and minuses, but by and large I think it's optional presence would be a benefit.
Mar 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Charles Hixson wrote:
 mixin(bitfields!("
      uint x :  2,
      int  y :  3,
      uint z :  2,
      bool flag : 1,
      ")
 so that it would be easier to shuffle the fields during development. 
 This has it's pluses and minuses, but by and large I think it's optional 
 presence would be a benefit.
That's a pretty neat idea. It's not difficult to implement, and it could possibly placate a few naysayers. And it's not ambiguous with the existing syntax either, so at least for a while both might be supported. One improvement from the language could come from dropping the parens requirement for mixin, in which case: mixin bitfields!" uint x : 2, int y : 3, uint z : 2, bool flag : 1, "; Andrei
Mar 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 One improvement from the language could come from dropping the parens 
 requirement for mixin, in which case:
 
  mixin bitfields!"
       uint x :  2,
       int  y :  3,
       uint z :  2,
       bool flag : 1,
       ";
Have to resolve the ambiguity with template mixins for that to work.
Mar 07 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 One improvement from the language could come from dropping the parens
 requirement for mixin, in which case:

  mixin bitfields!"
       uint x :  2,
       int  y :  3,
       uint z :  2,
       bool flag : 1,
       ";
Have to resolve the ambiguity with template mixins for that to work.
mixin:blah mixin.blah mixin!blah If you do something like this, I'd just want this to work: mixin!bitfields("uint x : 2") I use mixins with CTFE functions WAY MORE than I use them with templates. Incidentally, writing something that parses the above language for bitfields wouldn't be too hard. I've done something similar for defining properties. -- Daniel
Mar 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 I use mixins with CTFE functions WAY MORE than I use them with templates.
I'm not surprised. I feel the template mixins were probably a mistake.
Mar 07 2009
next sibling parent Jordan Miner <jminer2613 NOSPAM.students.pcci.edu> writes:
Walter Bright Wrote:

 Daniel Keep wrote:
 I use mixins with CTFE functions WAY MORE than I use them with templates.
I'm not surprised. I feel the template mixins were probably a mistake.
I like template mixins and use them. I don't use them much, but they are very useful for events (signals/slots) at least. The signals in Phobos uses template mixins, and I'm writing a GUI library where I'm using events similarly as a template mixin: mixin Event!(whenMouseDown) mouseDown; void whenMouseDown(MouseDownEventArgs e) { } I don't think there is another way to get as nice a syntax, and events are important in a GUI. Though I still wish I could document the mixed-in With CTFE and mixins, I'm not thrilled with passing code around as a string (no syntax highlighting), even though it is really powerful. But I don't think I will mind much in D2 with token strings. Still, finding a better syntax for mixin(string) would be great.
Mar 07 2009
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 I use mixins with CTFE functions WAY MORE than I use them with templates.
I'm not surprised. I feel the template mixins were probably a mistake.
Well, there's really a few things at play here: 1. I use templates for simple forward code generation based on types. I use CTFE for complex code generation that requires parsing or any customisability more involved than specifying what T is. 2. Because of most of this, most of my templates are self-contained while my CTFE is meant to be mixed in to another context. 3. String mixins let me insert functionality and execute it in a single line. If I use a templated function, it doesn't have access to its context. If I mix it in first, then I have to have a second line to invoke it. That is, this:
 mixin(doStuff);
versus
 mixin doStuff;
 _doStuff();
4. An added issue is that there is *no way* to replicate this with templates:
 mixin(`
   private int _storage_foo;
   public int foo() { return _storage_foo; }
   public int foo(int v) { return _storage_foo = v; }
 `);
This is generally an issue where I have a mixin that implements some interface, but needs backend "wiring" exposed in places to the mixin-ing context. Ideally, I'd be able to do this:
 mixin Foo;

 template Foo
 {
     private int _counter_foo;
     mixin private int _storage_foo;
     public int foo() { ++_counter_foo; return _storage_foo; }
     public int foo(int v) { ++_counter_foo; return _storage_foo = v; }
 }
This way, I can specify that the protection attributes are referring to the mixin-ing context, and not to the template itself. I think the major issue is that string mixins represent a superset of template mixin functionality. I wouldn't say they were a mistake: more that they haven't kept pace. At the end of the day, string mixins are indispensable as a "safe" form of text substitution... but they are a still a hack that should, in most cases, be replaced with better language facilities. -- Daniel
Mar 07 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Charles Hixson escribió:
 Andrei Alexandrescu wrote:
 Michel Fortin wrote:
 On 2009-03-06 14:35:59 -0500, Walter Bright 
 <newshound1 digitalmars.com> said:

 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the 
 Earth!"

 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."

 "Meh, don't like the definition syntax."
Classic.
Well, he certainly has a point. Compare this: mixin(bitfields!( uint, "x", 2, int, "y", 3, uint, "z", 2, bool, "flag", 1)); With this: uint x : 2; int y : 3; uint z : 2; bool flag : 1; The second is certainly prettier and more readable.
(Just to clarify: to me the humor of the situation was that someone who considered bitfields an absolute prerequisite for language adoption subsequently found the syntax excuse to bail out. Essentially the hypothetical user was fabricating one pretext after another to rationalize their pre-made decision to not try D -- an absolute classic attitude when it comes about acquiring new programming languages.) About the syntax itself - definitions are few and uses are many. In addition the D solution: (a) guarantees data layout; (b) offers symbolic limits, e.g. x_max and x_min are automatically added as enums; (c) checks for overflow, which is essential for small bitfields; (d) offers a way to manipulate the fields wholesale by using the concatenation of all their names, e.g. xyzflag; (e) suggests that there are other cool things that can be done within the language, not by adding features to it. Hopefully that makes up for the more loaded syntax.
 Does it matter much? Not to me; I rarely use bit fields. If I were 
 using them a lot, perhaps I'd be more concerned.
I am using them here and there - even in Phobos - and they work very well.
 While I don't care very much about bitfields, that 
 "mixin(tmpl!(...))" syntax is awful. "mixin tmpl!(...)" is better, 
 but has too many limitations, and it isn't always clear for the user 
 which one should be used. Couldn't D2 get a better syntax for mixins?
I agree it should. Andrei
I'm glad that they're there. And I'm glad that they work. But I really hate the syntax, and am glad I've never needed to use them. MUCH better would have been: mixin(bitfields!(" uint, x, 2, int, y, 3, uint, z, 2, bool, flag, 1 ") even better would have been: mixin(bitfields!(" uint x : 2, int y : 3, uint z : 2, bool flag : 1 ")
Why do the parsing yourself if you can leave that to the compiler? Just read the docs, pass the arguments and that's it. Way much easier. You get standard error messages, if you use an IDE you get autocompletion for the parameters, etc. I really don't know why everyone is so obsessed with strings... :-P
Mar 07 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Ary Borenszweig wrote:
 Charles Hixson escribió:
 I'm glad that they're there.  And I'm glad that they work.  But I
 really hate the syntax, and am glad I've never needed to use them. 
 MUCH better would have been:
 mixin(bitfields!("
      uint, x,    2,
      int,  y,    3,
      uint, z,    2,
      bool, flag, 1
      ")

 even better would have been:
 mixin(bitfields!("
      uint x :  2,
      int  y :  3,
      uint z :  2,
      bool flag : 1
      ")
Why do the parsing yourself if you can leave that to the compiler? Just read the docs, pass the arguments and that's it. Way much easier. You get standard error messages, if you use an IDE you get autocompletion for the parameters, etc. I really don't know why everyone is so obsessed with strings... :-P
mixin(cvars! ` int window.width as width = 640; int window.height as height = 480; ` ); and mixin(cvars! ( int, "window.width, width", 640, int, "window.height, height", 480 ) ); are functionally the same, and have almost exactly the same length. Except the first looks cooler and has a more natural syntax. Sometimes, that's important. As for the IDE issue, I'm increasingly of the opinion that this is a shortcoming of IDEs. For example, I've never seen an IDE that got script in HTML right. Certainly not if you change the language being used under it's feet. Maybe it's time IDEs started supporting embedded DSLs as a matter of course. Dunno how, but that's their problem, not mine. :P -- Daniel
Mar 07 2009
parent BLS <windevguy hotmail.de> writes:
Daniel Keep wrote:

 As for the IDE issue, I'm increasingly of the opinion that this is a
 shortcoming of IDEs.  For example, I've never seen an IDE that got
 script in HTML right.
Netbeans 6.5 Björn
Mar 08 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 
 "Can't live without bitfields! Give me bitfields and I'll lift the Earth!"
 
 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."
 
 "Meh, don't like the definition syntax."
Now, now. There. Don't cry. ;-) They might be an unglamorous part of D, and seldom used, but for the guy who ends up needing bitfields, they're a godsend! Like a can opener. You can live weeks without needing one, but when you've got a can, it's not nice to open it with the kitchen knife.
Mar 06 2009
parent reply grauzone <none example.net> writes:
Georg Wrede wrote:
 Andrei Alexandrescu wrote:
 "Can't live without bitfields! Give me bitfields and I'll lift the 
 Earth!"

 "Here they are, std.bitmanip. Well-defined and more portable and 
 flexible than C's."

 "Meh, don't like the definition syntax."
Now, now. There. Don't cry. ;-) They might be an unglamorous part of D, and seldom used, but for the guy who ends up needing bitfields, they're a godsend! Like a can opener. You can live weeks without needing one, but when you've got a can, it's not nice to open it with the kitchen knife.
Creating a can opener on your own is not as trivial as re-implementing bitfields.
Mar 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 Georg Wrede wrote:
 Like a can opener. You can live weeks without needing one, but when 
 you've got a can, it's not nice to open it with the kitchen knife.
Creating a can opener on your own is not as trivial as re-implementing bitfields.
Using a table knife as a chisel should do the job. A kitchen knife is probably too thin and brittle.
Mar 06 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 grauzone wrote:
 Georg Wrede wrote:
 Like a can opener. You can live weeks without needing one, but when 
 you've got a can, it's not nice to open it with the kitchen knife.
Creating a can opener on your own is not as trivial as re-implementing bitfields.
Using a table knife as a chisel should do the job. A kitchen knife is probably too thin and brittle.
Duh! And still I see women use the kitchen knife for such. And of course the "blond thing" (that I see all women do), wrench jobs by default tried with pliers. My mother in law got herself a cutting board -- made of glass.
Mar 07 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Seems kind of silly to me.  The big deal with the full source for DMD 
 being available is that if DigitalMars disappears in a puff of smoke 
 tomorrow, customers have a means of preserving their investment in the 
 language.  This can be a big deal for corporate users.
Back in the 80's when I started out in the compiler business, we'd often get companies calling us up with: "we really like your compiler, but there's one little issue, it needs to be modified to do X. If it does X, we'd buy 1000/5000/10000 copies!" So I'd modify it to do X, and breathlessly contact them: "it does X now! where's the P.O? We're ready to ship!" Then they'd hem and haw a bit, and say: "X is cool, great, yeah, but we really also need Y!" It became clear after a while that they never had any intention of buying any copies. There are a lot of possible reasons why they were jerking our chain, but the strategy we came up with was: "sure, we'd love to do X for you, our consulting rates are $$$ and we estimate xxx hours to do the job. We need a down payment to start work." If they were serious, no problem, we did good business with them. The ones who were jerking us around for whatever reason went away.
Funny. When I was in R&D at a telco we regularly got requests from another department for new features in the system... requests which changed multiple times and occasionally weren't ultimately needed. We finally decided to start billing them for our time at an outrageous rate, and stated that any change, no matter how small, would take at least one full day to complete. It was amazing how quickly they began thinking about their requests before making them. I think you're right that there's simply no point in listening to people who have no investment in what you're working on.
Mar 06 2009
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
I sort of hate to throw myself into the fray, especially since my 
studies have kept me more-or-less detached from D entirely, but ...

I realize people are going to misuse the term Open Source. However, the 
term is NOT generic, and DOES have a specific meaning; it is in fact 
trademarked, and using it to describe software that does not fit the 
Open Source Definition is in violation of the trademark. But more 
importantly than that, it's confusing to the loads of people out here 
who use F/OSS and depend on the freedoms it provides. Without 
redistribution rights, F/OSS is substantially less valuable, as it 
doesn't provide any escape if the original creator loses interest, 
spontaneously combusts, decides he hates giving away his source and 
closes it again, etc, etc, etc.

I understand that the reason the redistribution license isn't fully Open 
Source is for quirkly legal reasons with Walter's license of it, and so 
it's not really anybody's fault. I'm not trying to put any blame 
anywhere for that part.

My only request is that people (or at least Walter) don't describe it 
using the term "Open Source". It's confusing, it's wrong, and it dilutes 
a perfectly meaningful term. Use "source available", "source included", 
"non-redistributable source provided", I don't care, just not the term 
with loaded additional meaning.

  - Gregor Richards

PS: Yes, I realize that there's nothing in the words "open" and "source" 
that suggest all the other stuff. Welcome to English.
Mar 07 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Gregor Richards wrote:
 My only request is that people (or at least Walter) don't describe it 
 using the term "Open Source". It's confusing, it's wrong, and it dilutes 
 a perfectly meaningful term. Use "source available", "source included", 
 "non-redistributable source provided", I don't care, just not the term 
 with loaded additional meaning.
You're right. I didn't call it open source in the changelog for that reason, and the reason this thread is titled the way it is is because of the thread title on reddit. But I still shouldn't have titled this thread that way.
Mar 07 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Gregor Richards wrote:
 I realize people are going to misuse the term Open Source. However, the 
 term is NOT generic, and DOES have a specific meaning; it is in fact 
 trademarked, and using it to describe software that does not fit the 
 Open Source Definition is in violation of the trademark. But more 
 importantly than that, it's confusing to the loads of people out here 
 who use F/OSS and depend on the freedoms it provides. Without 
 redistribution rights, F/OSS is substantially less valuable, as it 
 doesn't provide any escape if the original creator loses interest, 
 spontaneously combusts, decides he hates giving away his source and 
 closes it again, etc, etc, etc.
I've heard the term 'disclosed source' before, in the context of various Microsoft products where the source code is available but not redistributable. It's as good a choice as any.
Mar 07 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Gregor Richards wrote:
 I sort of hate to throw myself into the fray, especially since my 
 studies have kept me more-or-less detached from D entirely, but ...
 
 I realize people are going to misuse the term Open Source. However, the 
 term is NOT generic, and DOES have a specific meaning; it is in fact 
 trademarked, and using it to describe software that does not fit the 
 Open Source Definition is in violation of the trademark. 
Wow! I didn't know that. It's not going to stay that way for long, in fact I'd be surprised if a court case right now didn't rule that it's already become generic. For example, I have never *once* seen it written as "Open Source(TM)". And I've read dozens of GNU sites. But more
 importantly than that, it's confusing to the loads of people out here 
 who use F/OSS and depend on the freedoms it provides. Without 
 redistribution rights, F/OSS is substantially less valuable, as it 
 doesn't provide any escape if the original creator loses interest, 
 spontaneously combusts, decides he hates giving away his source and 
 closes it again, etc, etc, etc.
I had thought that open = !closed. With this release, DMD is definitely not closed source. Your comments imply that there's actually 3 states: open, closed, and inbetween. Which is pretty confusing. (BTW, it's not clear to me that "open source" and "Open Source" are the same).
 
 I understand that the reason the redistribution license isn't fully Open 
 Source is for quirkly legal reasons with Walter's license of it, and so 
 it's not really anybody's fault. I'm not trying to put any blame 
 anywhere for that part.
 
 My only request is that people (or at least Walter) don't describe it 
 using the term "Open Source". It's confusing, it's wrong, and it dilutes 
 a perfectly meaningful term. Use "source available", "source included", 
 "non-redistributable source provided", I don't care, just not the term 
 with loaded additional meaning.
Fair enough.
  - Gregor Richards
 
 PS: Yes, I realize that there's nothing in the words "open" and "source" 
 that suggest all the other stuff. Welcome to English.
That's why you need (TM) or (R) if you want it to keep it as a trademark.
Mar 07 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Don, el  8 de marzo a las 07:39 me escribiste:
 Gregor Richards wrote:
I sort of hate to throw myself into the fray, especially since my studies have 
kept me more-or-less detached from D entirely, but ...
I realize people are going to misuse the term Open Source. However, the term is 
NOT generic, and DOES have a specific meaning; it is in fact trademarked, and 
using it to describe software that does not fit the Open Source Definition is 
in violation of the trademark. 
Wow! I didn't know that. It's not going to stay that way for long, in fact I'd be surprised if a court case right now didn't rule that it's already become generic. For example, I have never *once* seen it written as "Open Source(TM)". And I've read dozens of GNU sites.
I don't know if Open Source is a TM, but I'm sure you can't find information about it in GNU sites =) GNU advocates Free Software instead of Open Source. It's very similar but not the same, Free Sowftware is more "viral".
 But more
importantly than that, it's confusing to the loads of people out here who use 
F/OSS and depend on the freedoms it provides. Without redistribution rights, 
F/OSS is substantially less valuable, as it doesn't provide any escape if the 
original creator loses interest, spontaneously combusts, decides he hates 
giving away his source and closes it again, etc, etc, etc.
I had thought that open = !closed. With this release, DMD is definitely not closed source.
Well, I think it's closed. I just opened a window to peak inside =)
 Your comments imply that there's actually 3 states: open, closed, and
 inbetween.  Which is pretty confusing. (BTW, it's not clear to me that
 "open source" and "Open Source" are the same).
I think Open Source has a well established meaning, whether you like it or not (as well as Free Software). If you use that term with another meaning you are just confusing people (and even pissing off people who try to make a stand with FLOSS). Unless you want to buy some publicity with the fuzz, it's better not to do it =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Algún día los libros desterrarán a la radio y el hombre descubrirá el oculto poder del Amargo Serrano. -- Ricardo Vaporeso. El Bolsón, 1909.
Mar 09 2009
parent reply Don <nospam nospam.com> writes:
Leandro Lucarella wrote:
 Don, el  8 de marzo a las 07:39 me escribiste:
 Gregor Richards wrote:
 I sort of hate to throw myself into the fray, especially since my studies have 
 kept me more-or-less detached from D entirely, but ...
 I realize people are going to misuse the term Open Source. However, the term
is 
 NOT generic, and DOES have a specific meaning; it is in fact trademarked, and 
 using it to describe software that does not fit the Open Source Definition is 
 in violation of the trademark. 
Wow! I didn't know that. It's not going to stay that way for long, in fact I'd be surprised if a court case right now didn't rule that it's already become generic. For example, I have never *once* seen it written as "Open Source(TM)". And I've read dozens of GNU sites.
I don't know if Open Source is a TM, but I'm sure you can't find information about it in GNU sites =) GNU advocates Free Software instead of Open Source. It's very similar but not the same, Free Sowftware is more "viral".
I found it isn't trademarked, actually.
 
 But more
 importantly than that, it's confusing to the loads of people out here who use 
 F/OSS and depend on the freedoms it provides. Without redistribution rights, 
 F/OSS is substantially less valuable, as it doesn't provide any escape if the 
 original creator loses interest, spontaneously combusts, decides he hates 
 giving away his source and closes it again, etc, etc, etc.
I had thought that open = !closed. With this release, DMD is definitely not closed source.
Well, I think it's closed. I just opened a window to peak inside =)
 Your comments imply that there's actually 3 states: open, closed, and
 inbetween.  Which is pretty confusing. (BTW, it's not clear to me that
 "open source" and "Open Source" are the same).
I think Open Source has a well established meaning, whether you like it or not (as well as Free Software). If you use that term with another meaning you are just confusing people (and even pissing off people who try to make a stand with FLOSS). Unless you want to buy some publicity with the fuzz, it's better not to do it =)
Yes. But it's become apparent to me that it's a stupid term. To quote Richard Stallman: ------ However, the obvious meaning for the expression “open source software†is “You can look at the source code,†and most people seem to think that's what it means. That is a much weaker criterion than free software, and much weaker than the official definition of open source. It includes many programs that are neither free nor open source. Since that obvious meaning for “open source†is not the meaning that its advocates intend, the result is that most people misunderstand the term. ------[etc] http://www.gnu.org/philosophy/open-source-misses-the-point.html I'll try to never use the term "open source" again. EVER.
Mar 09 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Don, el 10 de marzo a las 06:43 me escribiste:
 To quote Richard Stallman:
 ------
 However, the obvious meaning for the expression “open source software†is 
 “You can look at the source code,†and most people seem to think that's
what 
 it means. That is a much weaker criterion than free software, and much weaker 
 than the official definition of open source. It includes many programs that
are 
 neither free nor open source.
 
 Since that obvious meaning for “open source†is not the meaning that its 
 advocates intend, the result is that most people misunderstand the term. 
Free Software is a very ambiguous term too (many people think of "free" as in no charge). Unfortunately English is a very crappy language ;)
 ------[etc]
 http://www.gnu.org/philosophy/open-source-misses-the-point.html
 
 I'll try to never use the term "open source" again. EVER.
I think FLOSS (Free/Libre Open Source Software) is the term to use to make all the people happy =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- PENE MUTILADO POR PENETRAR UNA ASPIRADORA -- Crónica TV
Mar 12 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Mar 12, 2009 at 12:46 PM, Leandro Lucarella <llucax gmail.com> wrote:
 Free Software is a very ambiguous term too (many people think of "free" as
 in no charge).

 Unfortunately English is a very crappy language ;)
I think with the absurd preponderance of FLOSS proponents saying "free as in freedom!" the term "free software" really cannot be interpreted as anything *but* FLOSS anymore. Frankly I'm sick of hearing "free as in freedom!" and "libre!" all the goddamn time, I know what is meant :P
Mar 12 2009
next sibling parent reply Don <nospam nospam.com> writes:
Jarrett Billingsley wrote:
 On Thu, Mar 12, 2009 at 12:46 PM, Leandro Lucarella <llucax gmail.com> wrote:
 Free Software is a very ambiguous term too (many people think of "free" as
 in no charge).

 Unfortunately English is a very crappy language ;)
It's a great ball of mud. Fascinating and structureless.
 
 I think with the absurd preponderance of FLOSS proponents saying "free
 as in freedom!" the term "free software" really cannot be interpreted
 as anything *but* FLOSS anymore.  Frankly I'm sick of hearing "free as
 in freedom!" and "libre!" all the goddamn time, I know what is meant
 :P
Yes. It's a lot more obvious in German. frei = liberty, kostenloss = no cost. Maybe they need to change the name to: "Frei Software" <g>. The upshot of all this, though, is it seems there's no term for "source is available" (without necessarily being able to be redistributed).
Mar 12 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 12 Mar 2009 23:01:04 +0300, Don <nospam nospam.com> wrote:

 Jarrett Billingsley wrote:
 On Thu, Mar 12, 2009 at 12:46 PM, Leandro Lucarella <llucax gmail.com>  
 wrote:
 Free Software is a very ambiguous term too (many people think of  
 "free" as
 in no charge).

 Unfortunately English is a very crappy language ;)
It's a great ball of mud. Fascinating and structureless.
  I think with the absurd preponderance of FLOSS proponents saying "free
 as in freedom!" the term "free software" really cannot be interpreted
 as anything *but* FLOSS anymore.  Frankly I'm sick of hearing "free as
 in freedom!" and "libre!" all the goddamn time, I know what is meant
 :P
Yes. It's a lot more obvious in German. frei = liberty, kostenloss = no cost. Maybe they need to change the name to: "Frei Software" <g>. The upshot of all this, though, is it seems there's no term for "source is available" (without necessarily being able to be redistributed).
I always thought Open Source mean just that until I read this very thread. Oh, well.. live and learn. Perhaps, should've named it Free Source Software rather than Open Source.
Mar 12 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Don, el 12 de marzo a las 21:01 me escribiste:
 Jarrett Billingsley wrote:
On Thu, Mar 12, 2009 at 12:46 PM, Leandro Lucarella <llucax gmail.com> wrote:
Free Software is a very ambiguous term too (many people think of "free" as
in no charge).

Unfortunately English is a very crappy language ;)
It's a great ball of mud. Fascinating and structureless.
I think with the absurd preponderance of FLOSS proponents saying "free
as in freedom!" the term "free software" really cannot be interpreted
as anything *but* FLOSS anymore.  Frankly I'm sick of hearing "free as
in freedom!" and "libre!" all the goddamn time, I know what is meant
:P
Yes. It's a lot more obvious in German. frei = liberty, kostenloss = no cost. Maybe they need to change the name to: "Frei Software" <g>. The upshot of all this, though, is it seems there's no term for "source is available" (without necessarily being able to be redistributed).
True. Maybe it's because it's such an unpopular category that nobody cared enough to make up a name and promote it =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Ever tried? Ever failed? - Try again! Fail better!
Mar 12 2009
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
Jarrett Billingsley wrote:
 
 I think with the absurd preponderance of FLOSS proponents saying "free
 as in freedom!" the term "free software" really cannot be interpreted
 as anything *but* FLOSS anymore.  Frankly I'm sick of hearing "free as
 in freedom!" and "libre!" all the goddamn time, I know what is meant
 :P
From the Reddit thread: drayno 5 points 6 days ago Anyone here actually use D for real work? I've always thought it looked well architected, like a better C++, but it seems hampered by the lack of a complete correct FREE implementation. WalterBright 5 points 6 days ago All 3 D compilers, dmd gcd and ldc, are free. Which "free" does drayno mean, and which does Walter?
Mar 12 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Jeff Nowakowski, el 12 de marzo a las 17:48 me escribiste:
 Jarrett Billingsley wrote:
I think with the absurd preponderance of FLOSS proponents saying "free
as in freedom!" the term "free software" really cannot be interpreted
as anything *but* FLOSS anymore.  Frankly I'm sick of hearing "free as
in freedom!" and "libre!" all the goddamn time, I know what is meant
:P
From the Reddit thread: drayno 5 points 6 days ago Anyone here actually use D for real work? I've always thought it looked well architected, like a better C++, but it seems hampered by the lack of a complete correct FREE implementation. WalterBright 5 points 6 days ago All 3 D compilers, dmd gcd and ldc, are free. Which "free" does drayno mean, and which does Walter?
Unless drayno is very dumb (I'm not saying it's not =), I assume he meant free as in freedom, because anybody knows (or should if is interested enough) that even DMD can be downloaded with no charge. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- La esperanza es una amiga que nos presta la ilusión.
Mar 12 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el 12 de marzo a las 14:09 me escribiste:
 On Thu, Mar 12, 2009 at 12:46 PM, Leandro Lucarella <llucax gmail.com> wrote:
 Free Software is a very ambiguous term too (many people think of "free" as
 in no charge).

 Unfortunately English is a very crappy language ;)
I think with the absurd preponderance of FLOSS proponents saying "free as in freedom!" the term "free software" really cannot be interpreted as anything *but* FLOSS anymore. Frankly I'm sick of hearing "free as in freedom!" and "libre!" all the goddamn time, I know what is meant :P
You can say the exact same thing about Open Source, but this thread shows there are people that still need the clarifications =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Cómo ser inconmensurablemente atractivo a la mujer del sexo opuesto. -- Libro de autoayuda de Hector Mesina.
Mar 12 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Unfortunately English is a very crappy language ;)
I think it's a great language, it's just completely unsuitable for computers, which is why we invent computer languages!
Mar 12 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gpbmma$29lj$1 digitalmars.com...
 Leandro Lucarella wrote:
 Unfortunately English is a very crappy language ;)
I think it's a great language, it's just...
I dunno, I'm convinced that if English weren't my native language I'd have never been able to learn it ;) Pseudo-phonetic alphabet, more grammatical exceptions than rules, etc. When I was taking various foreign languages in school, I found Spanish and German to be far more difficult than Japanese largely *because* Japanese is so much more different from English than the others. But then again, I am known for being a bit weird :)
Mar 12 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gpbmma$29lj$1 digitalmars.com...
 Leandro Lucarella wrote:
 Unfortunately English is a very crappy language ;)
I think it's a great language, it's just...
I dunno, I'm convinced that if English weren't my native language I'd have never been able to learn it ;) Pseudo-phonetic alphabet
What do you mean with pseudo-phonetic? How do you pronounce the first letter of "I"? And the first letter of "Incredible"? That doesn't seem to have any logic! :-P I always laugh when I see webpages that try to explain in English how to pronounce words in another language. For example: Come ti chiami? --> KOH-meh tee kee-AH-mee? Piacere di conoscerla --> pyah-CHEH-reh dee koh-noh-SHEHR-lah Comment vous appellez-vous? --> kuh-MAHN vooz ah-puhll-ay VOO? :)
Mar 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:
 How do you pronounce the first letter of "I"? And the first letter of 
 "Incredible"? That doesn't seem to have any logic! :-P
If you work with kids teaching them to read phonetically (rather than look-say), you'll discover that by and large, the phonetic rules work very well. They'll pronounce about 80% of the unfamiliar words reasonably correctly. The words that don't work so well phonetically are often borrow-words from foreign languages or words that have had their pronounciation shift over the years since their spelling was sed. For example, the silent 'e' at the end used to be pronounced.
Mar 12 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gpbpib$2eek$1 digitalmars.com...
 Ary Borenszweig wrote:
 What do you mean with pseudo-phonetic?

 How do you pronounce the first letter of "I"? And the first letter of 
 "Incredible"? That doesn't seem to have any logic! :-P
Yea, that's exactly what I mean. English pretends to be phonetic but really isn't (at least not anymore). But I never truly saw just how non-phonetic it was until I learned the Japanese -kana alphabets. Those alphabets really make English's claim of being phonetic look ridiculous.
 If you work with kids teaching them to read phonetically (rather than 
 look-say), you'll discover that by and large, the phonetic rules work very 
 well. They'll pronounce about 80% of the unfamiliar words reasonably 
 correctly.
It "works" because they hear the phonetic pronunciation that they come up with and realize that it sounds similar to (but not the same as!) some particular word that they know. That clues them in that the word it *sounds like* is probably the word that they're trying to read. You can even hear them going through the process of starting with a phonetic pronunciation and then morphing it into the real word. (Besides, that remaining 20% is still quite a lot.) The same exact thing happens when English speakers learn to read Japanese Katakana and come across an English word written in Katakana (or a romanized version of the Katakana). Most of the time, the Japanese pronunciation is noticeably different from the actual English pronunciation, but when you "hear" the Japanese pronunciation it gives you a good idea of what English word it's trying to approximate. ("terebi", "bideo gaimu", "beisubaaru", etc. Note: I may have the exact spellings of these wrong because I'm unsure of the exact pronunciation. Maybe our resident Japanese-speakers can correct me?)
 The words that don't work so well phonetically are often borrow-words from 
 foreign languages or words that have had their pronounciation shift over 
 the years since their spelling was sed. For example, the silent 'e' at the 
 end used to be pronounced.
That's one thing that's kind of nice about Japanese. Native words and loanwords are written in different alphabets (sort of like uppercase vs lowercase), so unlike English, you generally know if a word is a properly-pronounced native word or a potentially-differently-pronounced loanword. (Not that this is necessarily the original reason for the separate native/foreign alphabets, but it's at least a nice benefit.)
Mar 12 2009
next sibling parent BCS <ao pathlink.com> writes:
Reply to Nick,

 If you work with kids teaching them to read phonetically (rather than
 look-say), you'll discover that by and large, the phonetic rules work
 very well. They'll pronounce about 80% of the unfamiliar words
 reasonably correctly.
 
It "works" because they hear the phonetic pronunciation that they come up with and realize that it sounds similar to (but not the same as!) some particular word that they know. That clues them in that the word it *sounds like* is probably the word that they're trying to read. You can even hear them going through the process of starting with a phonetic pronunciation and then morphing it into the real word. (Besides, that remaining 20% is still quite a lot.)
I think that English can't be spelled phonetically because it isn't pronounced consistently enough. Even if you spelled it 100% correct in the midwest US, the south, southwest, northwest and east, not to mention the UK would still be wrong.
Mar 12 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 That's one thing that's kind of nice about Japanese. Native words and 
 loanwords are written in different alphabets (sort of like uppercase vs 
 lowercase), so unlike English, you generally know if a word is a 
 properly-pronounced native word or a potentially-differently-pronounced 
 loanword. (Not that this is necessarily the original reason for the separate 
 native/foreign alphabets, but it's at least a nice benefit.)
I don't see having 3 alphabets as having some sort of compelling advantage that remotely compares with the cost of learning 3 alphabets and 3 spellings for everything.
Mar 12 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gpc2ik$2t80$1 digitalmars.com...
 Nick Sabalausky wrote:
 That's one thing that's kind of nice about Japanese. Native words and 
 loanwords are written in different alphabets (sort of like uppercase vs 
 lowercase), so unlike English, you generally know if a word is a 
 properly-pronounced native word or a potentially-differently-pronounced 
 loanword. (Not that this is necessarily the original reason for the 
 separate native/foreign alphabets, but it's at least a nice benefit.)
I don't see having 3 alphabets as having some sort of compelling advantage that remotely compares with the cost of learning 3 alphabets and 3 spellings for everything.
Native Japanese words never use the Katakana alphabet, and loanwords never use the Hiragana alphabet (those are the two phonetic alphabets). So in Japanese, each word has at most 2 written forms: one using the non-phonetic Chinese Kanji characters (ie, the third alphabet) and one using just whichever -kana is appropriate. Also, suffixes and articles (ie, not the "magazine" type) are always (to my knowledge) in Hiragana, never one of the other two alphabets. Also, the "two" phonetic Japanese alphabets are really comparable to either uppercase vs lowercase or cursive vs print. So in the same sense that Japanese has three alphabets, we really have four.
Mar 12 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gpc4m6$30nt$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gpc2ik$2t80$1 digitalmars.com...
 Nick Sabalausky wrote:
 That's one thing that's kind of nice about Japanese. Native words and 
 loanwords are written in different alphabets (sort of like uppercase vs 
 lowercase), so unlike English, you generally know if a word is a 
 properly-pronounced native word or a potentially-differently-pronounced 
 loanword. (Not that this is necessarily the original reason for the 
 separate native/foreign alphabets, but it's at least a nice benefit.)
I don't see having 3 alphabets as having some sort of compelling advantage that remotely compares with the cost of learning 3 alphabets and 3 spellings for everything.
Native Japanese words never use the Katakana alphabet, and loanwords never use the Hiragana alphabet (those are the two phonetic alphabets). So in Japanese, each word has at most 2 written forms: one using the non-phonetic Chinese Kanji characters (ie, the third alphabet) and one using just whichever -kana is appropriate. Also, suffixes and articles (ie, not the "magazine" type) are always (to my knowledge) in Hiragana, never one of the other two alphabets. Also, the "two" phonetic Japanese alphabets are really comparable to either uppercase vs lowercase or cursive vs print. So in the same sense that Japanese has three alphabets, we really have four.
Also, I'm not saying that their way is either better or worse overall. I'm just saying that it does at least have certain benefits.
Mar 12 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Mar 12, 2009 at 4:11 PM, Nick Sabalausky <a a.a> wrote:
 "Nick Sabalausky" <a a.a> wrote in message
 news:gpc4m6$30nt$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:gpc2ik$2t80$1 digitalmars.com...
 Nick Sabalausky wrote:
 That's one thing that's kind of nice about Japanese. Native words and
 loanwords are written in different alphabets (sort of like uppercase vs
 lowercase), so unlike English, you generally know if a word is a
 properly-pronounced native word or a potentially-differently-pronounced
 loanword. (Not that this is necessarily the original reason for the
 separate native/foreign alphabets, but it's at least a nice benefit.)
I don't see having 3 alphabets as having some sort of compelling advantage that remotely compares with the cost of learning 3 alphabets and 3 spellings for everything.
Native Japanese words never use the Katakana alphabet, and loanwords never use the Hiragana alphabet (those are the two phonetic alphabets). So in Japanese, each word has at most 2 written forms: one using the non-phonetic Chinese Kanji characters (ie, the third alphabet) and one using just whichever -kana is appropriate. Also, suffixes and articles (ie, not the "magazine" type) are always (to my knowledge) in Hiragana, never one of the other two alphabets. Also, the "two" phonetic Japanese alphabets are really comparable to either uppercase vs lowercase or cursive vs print. So in the same sense that Japanese has three alphabets, we really have four.
Also, I'm not saying that their way is either better or worse overall. I'm just saying that it does at least have certain benefits.
I can tell you that my son is having a much easier time learning to read hiragana than roman letters. He knows his ABCs but he still can't really read much of anything using what he knows. The hiragana on the other hand, once you know 'ka' for instance it's pronounced precisely 'ka' wherever you see it. So he calls them out on all the signs he sees. The only mistake he makes is sometimes reading right to left instead of left to right. But he gets frustrated trying to pronounce English words. The nice thing about hiragana being so easy to learn, is that they can use those as pronunciation guides for kids. So in kids books any non-hiragana word will have "furigana" I think they call it, above the kanji, which are the pronunciation of the kanji written in hiragana. It actually made me think that it would be nice if there were two systems for spelling English words, just for the purpose of making it easier for kids to achieve literacy. I mean one system that is regular, systematic, and compact, in addition to the goofy one we've become accustomed to. --bb --bb
Mar 12 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Bill Baxter escribió:
 On Thu, Mar 12, 2009 at 4:11 PM, Nick Sabalausky <a a.a> wrote:
 "Nick Sabalausky" <a a.a> wrote in message
 news:gpc4m6$30nt$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:gpc2ik$2t80$1 digitalmars.com...
 Nick Sabalausky wrote:
 That's one thing that's kind of nice about Japanese. Native words and
 loanwords are written in different alphabets (sort of like uppercase vs
 lowercase), so unlike English, you generally know if a word is a
 properly-pronounced native word or a potentially-differently-pronounced
 loanword. (Not that this is necessarily the original reason for the
 separate native/foreign alphabets, but it's at least a nice benefit.)
I don't see having 3 alphabets as having some sort of compelling advantage that remotely compares with the cost of learning 3 alphabets and 3 spellings for everything.
Native Japanese words never use the Katakana alphabet, and loanwords never use the Hiragana alphabet (those are the two phonetic alphabets). So in Japanese, each word has at most 2 written forms: one using the non-phonetic Chinese Kanji characters (ie, the third alphabet) and one using just whichever -kana is appropriate. Also, suffixes and articles (ie, not the "magazine" type) are always (to my knowledge) in Hiragana, never one of the other two alphabets. Also, the "two" phonetic Japanese alphabets are really comparable to either uppercase vs lowercase or cursive vs print. So in the same sense that Japanese has three alphabets, we really have four.
Also, I'm not saying that their way is either better or worse overall. I'm just saying that it does at least have certain benefits.
I can tell you that my son is having a much easier time learning to read hiragana than roman letters. He knows his ABCs but he still can't really read much of anything using what he knows. The hiragana on the other hand, once you know 'ka' for instance it's pronounced precisely 'ka' wherever you see it. So he calls them out on all the signs he sees. The only mistake he makes is sometimes reading right to left instead of left to right. But he gets frustrated trying to pronounce English words.
Spanish, French and Italian are also easy in that sense. There's not much choice as to how to pronounce a word. Either a letter is pronounced always the same, or a combination of letters is pronounced always the same. The only gotcha is that many letters may have the same sound, so by hearing the word you might not know how to write it. In the company I work we just finished building a website, chose a name for it, and we still don't know how it is pronounced in English. We only have suppositions. :-P
Mar 12 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Mar 12, 2009 at 7:49 PM, Ary Borenszweig <ary esperanto.org.ar> wrote:
 In the company I work we just finished building a website, chose a name for
 it, and we still don't know how it is pronounced in English. We only have
 suppositions. :-P
"NAY-un" or "NAY-oon" would be by guess.
Mar 12 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gpc2ik$2t80$1 digitalmars.com...
 Nick Sabalausky wrote:
 That's one thing that's kind of nice about Japanese. Native words and 
 loanwords are written in different alphabets (sort of like uppercase vs 
 lowercase), so unlike English, you generally know if a word is a 
 properly-pronounced native word or a potentially-differently-pronounced 
 loanword. (Not that this is necessarily the original reason for the 
 separate native/foreign alphabets, but it's at least a nice benefit.)
I don't see having 3 alphabets as having some sort of compelling advantage that remotely compares with the cost of learning 3 alphabets and 3 spellings for everything.
Native Japanese words never use the Katakana alphabet, and loanwords never use the Hiragana alphabet (those are the two phonetic alphabets).
There are situations in Japanese where you use katakana natively. Onomatopoeia, for instance, and company names. I know that, when introducing someone's name in writing, an author will sometimes follow the kanji version of the name with a phonological representation of the name. Does this typically use hiragana, or would you use katakana for that as well?
Mar 13 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gpbpib$2eek$1 digitalmars.com...
 Ary Borenszweig wrote:
 What do you mean with pseudo-phonetic?

 How do you pronounce the first letter of "I"? And the first letter of 
 "Incredible"? That doesn't seem to have any logic! :-P
Yea, that's exactly what I mean. English pretends to be phonetic but really isn't (at least not anymore). But I never truly saw just how non-phonetic it was until I learned the Japanese -kana alphabets. Those alphabets really make English's claim of being phonetic look ridiculous.
To be fair, English stems from Germanic, and pronunciation has changed tremendously over the years. Chaucer is nearly incomprehensible to most people, and it's just in Middle English.
Mar 13 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 12 Mar 2009 12:59:08 -0700, Walter Bright wrote:


 If you work with kids teaching them to read phonetically (rather than 
 look-say), you'll discover that by and large, the phonetic rules work 
 very well. They'll pronounce about 80% of the unfamiliar words 
 reasonably correctly.
I wound the bandage around the wound. Wind up the window to stop the wind coming in. And of course there's "ghoti" ;-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Mar 12 2009
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 13 Mar 2009 06:57:12 +0100, Derek Parnell <derek psych.ward> wrote:

 On Thu, 12 Mar 2009 12:59:08 -0700, Walter Bright wrote:


 If you work with kids teaching them to read phonetically (rather than
 look-say), you'll discover that by and large, the phonetic rules work
 very well. They'll pronounce about 80% of the unfamiliar words
 reasonably correctly.
I wound the bandage around the wound. Wind up the window to stop the wind coming in. And of course there's "ghoti" ;-)
Ghoti is nothing. In norwegian, we write 'hund' and pronounce it 'bikkje'. :p
Mar 13 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Simen Kjaeraas wrote:
 On Fri, 13 Mar 2009 06:57:12 +0100, Derek Parnell <derek psych.ward> wrote:
 
 On Thu, 12 Mar 2009 12:59:08 -0700, Walter Bright wrote:


 If you work with kids teaching them to read phonetically (rather than
 look-say), you'll discover that by and large, the phonetic rules work
 very well. They'll pronounce about 80% of the unfamiliar words
 reasonably correctly.
I wound the bandage around the wound. Wind up the window to stop the wind coming in. And of course there's "ghoti" ;-)
Ghoti is nothing. In norwegian, we write 'hund' and pronounce it 'bikkje'. :p
Perhaps, but you guys make the best sandwich cheese in the world. Seriously. I <3 jarlsberg. Plus it's fun to say. "Yullsburg, yullsburg. But in Latin, 'jarlsberg' begins with an 'i'..." :D -- Daniel
Mar 13 2009
prev sibling parent Jeff Nowakowski <jeff dilacero.org> writes:
Gregor Richards wrote:
 I realize people are going to misuse the term Open Source. However, the 
 term is NOT generic, and DOES have a specific meaning; it is in fact 
 trademarked, and using it to describe software that does not fit the 
 Open Source Definition is in violation of the trademark.
"Open Source" is NOT trademarked. They tried for it and didn't get it. Instead they got "Open Source Initiative Approved License", which is just a certification label. However, I do agree, open source has a specific meaning which requires freedom to redistribute. -Jeff
Mar 10 2009