• Walter Bright (2/2) Mar 05 2009 http://www.reddit.com/r/programming/comments/82ck4/digitalmars_d_now_ope...
• hasen (4/9) Mar 05 2009 Wow there's a big fuss over there about it not being /really/ open sourc...
• grauzone (11/21) Mar 05 2009 To us, this doesn't really matter. The important thing is that we can
• Walter Bright (22/28) Mar 05 2009 Making the source available deals with the following:
• Gregor Richards (5/8) Mar 07 2009 Without redistribution rights, yes they are. All they can do is say
• Don (9/35) Mar 06 2009 Correct. Those guys don't know what open source is, apparently. And it's...
• Walter Bright (2/6) Mar 06 2009 Yes, that would be perfectly legal as I understand it.
• Jesse Phillips (24/50) Mar 06 2009 new_release_of_the_d_programming_language_now/
• Nick Sabalausky (8/11) Mar 06 2009 IIRC, Once upon a time, it was like that. "Open source" meant "source is...
• Gregor Richards (14/28) Mar 07 2009 Uhhhhh, no. The Open Source Definition, created by the Open Source
• Sean Kelly (5/13) Mar 05 2009 Seems kind of silly to me. The big deal with the full source for DMD
• Tomas Lindquist Olsen (11/26) Mar 05 2009 _programming_language_now/
• Sean Kelly (2/20) Mar 05 2009 If they're just building apps then all they need it for is "personal use...
• Georg Wrede (2/5) Mar 05 2009 I just hope Walter survives!
• Sean Kelly (4/10) Mar 05 2009 Well yeah. But that's the sort of question that comes up when
• Walter Bright (22/26) Mar 05 2009 Back in the 80's when I started out in the compiler business, we'd often...
• Denis Koroskin (3/5) Mar 06 2009 http://www.micropoll.com/akira/mpresult/539369-138652
• Walter Bright (2/11) Mar 06 2009
• Georg Wrede (3/11) Mar 06 2009 Bipolar folks the Americans. All of the states are either 100% for or
• Frits van Bommel (4/16) Mar 06 2009 Don't forget arrogant. They don't care what the rest of the world
• Don (2/19) Mar 07 2009 It told me I live in Bayern! (I don't).
• Frits van Bommel (2/4) Mar 08 2009 It got the specific location wrong for me too (wrong province, but close...
• Andrei Alexandrescu (6/43) Mar 06 2009 "Can't live without bitfields! Give me bitfields and I'll lift the Earth...
• Walter Bright (2/8) Mar 06 2009 Classic.
• Michel Fortin (23/32) Mar 06 2009 Well, he certainly has a point. Compare this:
• Ary Borenszweig (10/48) Mar 06 2009 Well, now the \ is character if free:
• grauzone (3/54) Mar 06 2009 String mixins are awful in the first place. The only thing that could
• dsimcha (11/65) Mar 06 2009 ????????????? String mixins are an absolute godsend. I mean really, how...
• Nick Sabalausky (8/29) Mar 06 2009 Both Murphey's law and the law of D bitfields dictate that we're all goi...
• Don (12/46) Mar 09 2009 Sure, they're open to _severe_ abuse, but for the case when they are
• dennis luehring (1/14) Mar 09 2009 @Walter - please add this perfect description to the mixin page ;-)
• Walter Bright (4/9) Mar 09 2009 If you look at the dmd source, there are some sub-builds in there the
• Andrei Alexandrescu (21/57) Mar 06 2009 (Just to clarify: to me the humor of the situation was that someone who
• Nick Sabalausky (24/80) Mar 06 2009 I have a different theory that's based on my own experience from other
• Walter Bright (4/9) Mar 06 2009 I've written a lot of bit twiddling code. Bitfields are not immensely
• Charles Hixson (34/44) Mar 07 2009 Bit fields are much less useful than they once were...because there's
• Andrei Alexandrescu (7/42) Mar 07 2009 I think bitfields are very useful on today's architectures, where memory...
• Walter Bright (6/19) Mar 07 2009 templates and mixins were designed fairly independently of each other,
• Charles Hixson (38/109) Mar 07 2009 I'm glad that they're there. And I'm glad that they work. But I really...
• Andrei Alexandrescu (13/22) Mar 07 2009 That's a pretty neat idea. It's not difficult to implement, and it could...
• Walter Bright (2/11) Mar 07 2009 Have to resolve the ambiguity with template mixins for that to work.
• Daniel Keep (11/23) Mar 07 2009 mixin:blah
• Walter Bright (2/3) Mar 07 2009 I'm not surprised. I feel the template mixins were probably a mistake.
• Jordan Miner (6/10) Mar 07 2009 I like template mixins and use them. I don't use them much, but they are...
• Daniel Keep (27/47) Mar 07 2009 Well, there's really a few things at play here:
• Ary Borenszweig (6/97) Mar 07 2009 Why do the parsing yourself if you can leave that to the compiler? Just
• Daniel Keep (24/49) Mar 07 2009 mixin(cvars!
• BLS (3/6) Mar 08 2009 Netbeans 6.5
• Georg Wrede (6/13) Mar 06 2009 Now, now. There. Don't cry. ;-)
• grauzone (3/21) Mar 06 2009 Creating a can opener on your own is not as trivial as re-implementing
• Walter Bright (3/9) Mar 06 2009 Using a table knife as a chisel should do the job. A kitchen knife is
• Georg Wrede (5/15) Mar 07 2009 Duh! And still I see women use the kitchen knife for such. And of course...
• Sean Kelly (10/39) Mar 06 2009 Funny. When I was in R&D at a telco we regularly got requests from
• Gregor Richards (24/24) Mar 07 2009 I sort of hate to throw myself into the fray, especially since my
• Walter Bright (5/10) Mar 07 2009 You're right. I didn't call it open source in the changelog for that
• Christopher Wright (4/14) Mar 07 2009 I've heard the term 'disclosed source' before, in the context of various...
• Don (14/42) Mar 07 2009 Wow! I didn't know that. It's not going to stay that way for long, in
• Leandro Lucarella (19/44) Mar 09 2009 I don't know if Open Source is a TM, but I'm sure you can't find
• Don (15/56) Mar 09 2009 Yes. But it's become apparent to me that it's a stupid term.
• Leandro Lucarella (13/27) Mar 12 2009 Free Software is a very ambiguous term too (many people think of "free" ...
• Jarrett Billingsley (6/9) Mar 12 2009 I think with the absurd preponderance of FLOSS proponents saying "free
• Don (7/18) Mar 12 2009 Yes. It's a lot more obvious in German. frei = liberty, kostenloss = no
• Denis Koroskin (4/23) Mar 12 2009 I always thought Open Source mean just that until I read this very threa...
• Leandro Lucarella (10/28) Mar 12 2009 True.
• Jeff Nowakowski (10/16) Mar 12 2009 From the Reddit thread:
• Leandro Lucarella (10/31) Mar 12 2009 Unless drayno is very dumb (I'm not saying it's not =), I assume he mean...
• Leandro Lucarella (10/22) Mar 12 2009 You can say the exact same thing about Open Source, but this thread show...
• Walter Bright (3/4) Mar 12 2009 I think it's a great language, it's just completely unsuitable for
• Nick Sabalausky (8/11) Mar 12 2009 I dunno, I'm convinced that if English weren't my native language I'd ha...
• Ary Borenszweig (10/18) Mar 12 2009 What do you mean with pseudo-phonetic?
• Walter Bright (9/11) Mar 12 2009 If you work with kids teaching them to read phonetically (rather than
• Nick Sabalausky (28/42) Mar 12 2009 Yea, that's exactly what I mean. English pretends to be phonetic but rea...
• BCS (5/18) Mar 12 2009 I think that English can't be spelled phonetically because it isn't pron...
• Walter Bright (4/10) Mar 12 2009 I don't see having 3 alphabets as having some sort of compelling
• Nick Sabalausky (12/22) Mar 12 2009 Native Japanese words never use the Katakana alphabet, and loanwords nev...
• Nick Sabalausky (4/27) Mar 12 2009 Also, I'm not saying that their way is either better or worse overall. I...
• Bill Baxter (20/50) Mar 12 2009 I can tell you that my son is having a much easier time learning to
• Ary Borenszweig (9/47) Mar 12 2009 Spanish, French and Italian are also easy in that sense. There's not
• Jarrett Billingsley (2/5) Mar 12 2009 "NAY-un" or "NAY-oon" would be by guess.
• Christopher Wright (7/22) Mar 13 2009 There are situations in Japanese where you use katakana natively.
• Sean Kelly (4/16) Mar 13 2009 To be fair, English stems from Germanic, and pronunciation has changed
• Derek Parnell (8/12) Mar 12 2009 I wound the bandage around the wound.
• Simen Kjaeraas (2/10) Mar 13 2009 Ghoti is nothing. In norwegian, we write 'hund' and pronounce it 'bikkje...
• Daniel Keep (6/24) Mar 13 2009 Perhaps, but you guys make the best sandwich cheese in the world.
• Jeff Nowakowski (6/10) Mar 10 2009 "Open Source" is NOT trademarked. They tried for it and didn't get it.

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/

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?

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?

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.

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

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?

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.

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

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

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

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.

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

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

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!

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.

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.

"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

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>

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

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

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

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

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

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.

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/

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

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.

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.

"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). 

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.

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

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.

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

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

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.

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

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

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.

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.

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

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.

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

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.

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.

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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!

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?

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.

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.

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!

"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 :)

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?

:)

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.

"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.)

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.

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.

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

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

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

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

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.

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?

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.

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

"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

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

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