www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bartosz about Chapel

reply bearophile <bearophileHUGS lycos.com> writes:
Bartosz talks a bit about the very nicely designed Chapel language:

http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/

(But my appreciation for Chapel design is on other things).

Bye,
bearophile
Nov 07 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/7/2011 5:51 PM, bearophile wrote:

 Bartosz talks a bit about the very nicely designed Chapel language:

 http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/




http://www.reddit.com/r/programming/comments/m3wf5/supercomputing_in_seattle_chapel_language/?already_submitted=true
Nov 07 2011
prev sibling next sibling parent reply Caligo <iteronvexor gmail.com> writes:
On Mon, Nov 7, 2011 at 7:51 PM, bearophile <bearophileHUGS lycos.com> wrote:


 Bartosz talks a bit about the very nicely designed Chapel language:

 http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/

 (But my appreciation for Chapel design is on other things).

 Bye,
 bearophile


Interesting (maybe useless) facts: Chapel has 59 keywords.  D has, I think,
107 keywords.  C++11, I think, 81.  Python has 33.
Nov 07 2011
next sibling parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Tue, 08 Nov 2011 05:39:07 +0100, Caligo <iteronvexor gmail.com> wrote:


 On Mon, Nov 7, 2011 at 7:51 PM, bearophile <bearophileHUGS lycos.com>  
 wrote:


 Bartosz talks a bit about the very nicely designed Chapel language:

 http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/

 (But my appreciation for Chapel design is on other things).

 Bye,
 bearophile


 Interesting (maybe useless) facts: Chapel has 59 keywords.  D has, I  
 think,
 107 keywords.  C++11, I think, 81.  Python has 33.


Interesting, questionably. Useless, indeed.
Nov 08 2011
parent reply Danni Coy <danni.coy gmail.com> writes:
On Wed, Nov 9, 2011 at 10:31 AM, Simen Kj=E6r=E5s <simen.kjaras gmail.com>w=
rote:


 On Tue, 08 Nov 2011 05:39:07 +0100, Caligo <iteronvexor gmail.com> wrote:

  On Mon, Nov 7, 2011 at 7:51 PM, bearophile <bearophileHUGS lycos.com>

 wrote:

  Bartosz talks a bit about the very nicely designed Chapel language:

 http://bartoszmilewski.**wordpress.com/2011/11/07/**
 supercomputing-in-seattle/<http://bartoszmilewski.wordpress.com/2011/11=






/07/supercomputing-in-seattle/>

 (But my appreciation for Chapel design is on other things).

 Bye,
 bearophile


 Interesting (maybe useless) facts: Chapel has 59 keywords.  D has, I
 think,
 107 keywords.  C++11, I think, 81.  Python has 33.


 Interesting, questionably. Useless, indeed.


how many keywords in D are needed because the preprocessor is built into
the language itself?
Nov 09 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2011 2:45 PM, Danni Coy wrote:

 how many keywords in D are needed because the preprocessor is built into the
 language itself?


It's true, people forget about the preprocessor keywords when counting C++
keywords.
Nov 09 2011
next sibling parent reply Caligo <iteronvexor gmail.com> writes:
On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright <newshound2 digitalmars.com>wrote:


 On 11/9/2011 2:45 PM, Danni Coy wrote:


 how many keywords in D are needed because the preprocessor is built into
 the
 language itself?


 It's true, people forget about the preprocessor keywords when counting C++
 keywords.


You're right, I did forget about the preprocessor.  Besides the usual
things in the header files, I always try to avoid macros.

There are about 20 directives, so that puts the keywords count for C++ to
101.  It's still fewer than D.  Does that mean D is more complex than C++?

Python with 33, I think most would agree that is has a very consice
grammer.
Nov 09 2011
next sibling parent Kapps <Kapps NotValidEmail.com> writes:
It means D can do the same thing with more explanatory keywords, yet in 
a more concise way.

On 09/11/2011 7:46 PM, Caligo wrote:

 On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>> wrote:

     On 11/9/2011 2:45 PM, Danni Coy wrote:

         how many keywords in D are needed because the preprocessor is
         built into the
         language itself?


     It's true, people forget about the preprocessor keywords when
     counting C++ keywords.



 You're right, I did forget about the preprocessor.  Besides the usual
 things in the header files, I always try to avoid macros.

 There are about 20 directives, so that puts the keywords count for C++
 to 101.  It's still fewer than D.  Does that mean D is more complex than
 C++?

 Python with 33, I think most would agree that is has a very consice
 grammer.
Nov 09 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2011 5:46 PM, Caligo wrote:

 There are about 20 directives, so that puts the keywords count for C++ to 101.
   It's still fewer than D.  Does that mean D is more complex than C++?


C++ has "unsigned", "long", and "unsigned long" while D has "uint", "long", and 
"ulong". That's one more keyword; does that make D more complex than C++?



 Python with 33, I think most would agree that is has a very consice grammer.


Python lacks a lot of powerful features that are in D.
Nov 09 2011
next sibling parent reply Caligo <iteronvexor gmail.com> writes:
On Wed, Nov 9, 2011 at 8:58 PM, Walter Bright <newshound2 digitalmars.com>wrote:


 On 11/9/2011 5:46 PM, Caligo wrote:


 There are about 20 directives, so that puts the keywords count for C++ to
 101.
  It's still fewer than D.  Does that mean D is more complex than C++?


 C++ has "unsigned", "long", and "unsigned long" while D has "uint",
 "long", and "ulong". That's one more keyword; does that make D more complex
 than C++?


In that example, I prefer the D way.  But, in both cases the different data
types exist because of speed and efficiency.    Semantically, int is more
or less a subset of long, so why do we need separate data types?  We don't,
really, and it's lame to clutter up the semantics of the language like that.

Something like this would have been better, and if I recall this is how
Chapel is doing it:

int(32)  a;  // int
int(64)  b;  // long



  Python with 33, I think most would agree that is has a very consice

 grammer.


 Python lacks a lot of powerful features that are in D.


I know, and I wasn't trying to say that Python is more powerful.
Nov 09 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2011 10:13 PM, Caligo wrote:

 Something like this would have been better, and if I recall this is how Chapel
 is doing it:

 int(32)  a;  // int
 int(64)  b;  // long


I did consider something like that early on, but couldn't get past

1. how ugly it looks after a while

2. the implication that int(17) should work, or int(1), etc.

3. the reality that CPUs tend to have 32 as the optimal size, and 'int' being a 
natural thing to type, it tends to be the default one types in. Otherwise, how 
would you explain that one should use int(32) rather than int(16) for routine 
integer use? It just seems (to me) that it would encourage the use of 
inefficient integer types.

4. I bet the first thing programmers would do with such types is:

    alias int(32) myint;

and then we're in a mismash of non-standard types (this happens too often in C 
where the sizeof(int) is unreliable).

5. I don't need constant reminding that ints are 32 bits.
Nov 10 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:j9g65s$2g1d$1 digitalmars.com...

 3. the reality that CPUs tend to have 32 as the optimal size, and 'int' 
 being a natural thing to type, it tends to be the default one types in. 
 Otherwise, how would you explain that one should use int(32) rather than 
 int(16) for routine integer use? It just seems (to me) that it would 
 encourage the use of inefficient integer types.


FWIW, I read that Chapel also has just plain "int" by itself which is 32 
bits.
Nov 10 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/10/2011 4:25 AM, Nick Sabalausky wrote:

 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:j9g65s$2g1d$1 digitalmars.com...

 3. the reality that CPUs tend to have 32 as the optimal size, and 'int'
 being a natural thing to type, it tends to be the default one types in.
 Otherwise, how would you explain that one should use int(32) rather than
 int(16) for routine integer use? It just seems (to me) that it would
 encourage the use of inefficient integer types.


 FWIW, I read that Chapel also has just plain "int" by itself which is 32
 bits.


:-)
Nov 10 2011
prev sibling parent reply foobar <foo bar.com> writes:
Walter Bright Wrote:


 On 11/9/2011 10:13 PM, Caligo wrote:

 Something like this would have been better, and if I recall this is how Chapel
 is doing it:

 int(32)  a;  // int
 int(64)  b;  // long


 
 I did consider something like that early on, but couldn't get past
 
 1. how ugly it looks after a while
 
 2. the implication that int(17) should work, or int(1), etc.
 
 3. the reality that CPUs tend to have 32 as the optimal size, and 'int' being
a 
 natural thing to type, it tends to be the default one types in. Otherwise, how 
 would you explain that one should use int(32) rather than int(16) for routine 
 integer use? It just seems (to me) that it would encourage the use of 
 inefficient integer types.
 
 4. I bet the first thing programmers would do with such types is:
 
     alias int(32) myint;
 
 and then we're in a mismash of non-standard types (this happens too often in C 
 where the sizeof(int) is unreliable).
 
 5. I don't need constant reminding that ints are 32 bits.


1. This makes sense on 32bit platforms. What about 64bit platforms? 
2. What about int(128), int(16), int(8)?  for the non-default (!= 32) you do
want to know the size. in what way short and byte better? 
3. The default optimal size should indeed have an alias such as 'int'.


A much better scheme IMO is to define as general type and predefine an easy to
remember alias for the default (32). Wait a sec, that's what chapel did.. 
The problem isn't with "int" but rather with the proliferation of the other
types for all the combinations of sign-ness and size.
Nov 10 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/10/2011 12:33 PM, foobar wrote:

 1. This makes sense on 32bit platforms. What about 64bit platforms?


D works fine on 64 bit platforms.



 2. What about int(128), int(16), int(8)?  for the non-default (!= 32) you do
 want to know the size. in what way short and byte better?


Short and byte have many decades of use being 16 bits and 8 bits. I don't know 
anyone who is confused by this.



 3. The default
 optimal size should indeed have an alias such as 'int'.


 A much better scheme IMO is to define as general type and predefine an easy
 to remember alias for the default (32). Wait a sec, that's what chapel did..
 The problem isn't with "int" but rather with the proliferation of the other
 types for all the combinations of sign-ness and size.


I think Chapel has solved a non-existent problem.

It's not like nobody has thought of declaring integers that way before. They 
have, over and over, for decades. It's just that few like the result.

You're also free to add the following to your code:

alias byte int8;
alias short int16;
alias int int32;

If you feel it improves your code, go for it.
Nov 10 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 Short and byte have many decades of use being 16 bits and 8 bits. I don't know 
 anyone who is confused by this.


"byte" and "ubyte" names sometimes cause problems because bytes are usually
unsigned values:
http://en.wikipedia.org/wiki/Byte


The size of the byte has historically been hardware dependent and no definitive
standards exist that mandate the size. The de facto standard of eight bits is a
convenient power of two permitting the values 0 through 255 for one byte.<



names. We have discussed this in past :-)

When I program in D, I take care of keeping often in my mind that "int" is not
an integer number, but a unchecked signed 2-complement 32-bits-wide bit field.
Forgetting it causes several bugs and troubles.

Bye,
bearophile
Nov 10 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/10/2011 4:53 PM, bearophile wrote:


 "ubyte" names. We have discussed this in past :-)


Sorry, but I think this is meaningless trivia.

There's been a lot of agonizing over names in D lately. They are a soul-sucking 
quagmire of wasting time.



 When I program in D, I take care of keeping often in my mind that "int" is
 not an integer number, but a unchecked signed 2-complement 32-bits-wide bit
 field. Forgetting it causes several bugs and troubles.


And when you program in floating point, you have to keep in mind the
limitations 
of the exponent and the mantissa.

And when you write a recursive function, you have to be mindful of stack 
limitations.

There's no escaping what a computer is. In any engineering profession, you've 
got to keep in mind that your design becomes real parts made out of real 
materials, and those materials are far from ideal. Forget that at one's peril.

----

This reminds me of the experience of a good friend of mine, very smart, who 
decided to learn Fortran by reading the DEC Fortran reference manual. He wrote 
his first program, and it worked perfectly the first time (did I say he was
very 
smart?), except for one detail. It ran incredibly slowly.

He poured over his listing and the manual, and could find nothing wrong. 
Finally, he took the listing (back in those days, we worked from paper
listings) 
to my roommate and asked for help.

My roommate looked at it and says, there's your problem. You are writing to a 
file by opening it, appending a single character, then closing it, in a loop. 
Don't you know you're supposed to open the file once, do all the writes, then 
close it?

No, says my friend, the manual said nothing about that, although when you think 
about how the computer must work when writing a file, it is obvious.
Nov 10 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 18:23:35 Walter Bright wrote:

 On 11/10/2011 4:53 PM, bearophile wrote:


 "ubyte" names. We have discussed this in past :-)


 
 Sorry, but I think this is meaningless trivia.
 
 There's been a lot of agonizing over names in D lately. They are a
 soul-sucking quagmire of wasting time.


Names can matter a great deal, but you can pretty much never get them 
completely right. There's always a problem of some sort with them. Sure, sbyte 
would make it clear that it's signed, but we don't have sshort, sint, or 
slong, and _those_ don't cause any confusion. Having sbyte would just make the 
language less consistent, which is _not_ a good thing. There's no point in 
debating it now unless we have a really good reason to change it (which we 
don't). Otherwise, it's just bikeshedding, and it wastes our time.

Bearophile has some good ideas, but he has too many of them for us to ever 
deal with them all even if they were all really good, and many of them are 
incredibly trivial. Obviously, he can suggest as many ideas as he likes, but I 
think that he'd stand a better chance of getting his ideas implemented if he 
presented far fewer of them. It would also take up less of everyone else's 
time. He's a valuable member of the community, but it would be better for 
everyone (him included) if his signal to noise ratio were much higher.

- Jonathan M Davis
Nov 10 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 11/10/2011 9:23 PM, Walter Bright wrote:

 On 11/10/2011 4:53 PM, bearophile wrote:


 "ubyte" names. We have discussed this in past :-)


 Sorry, but I think this is meaningless trivia.

 There's been a lot of agonizing over names in D lately. They are a
 soul-sucking quagmire of wasting time.


Vote++.  Really bad names hurt, but there's no such thing as a perfect 
name.  Any name will be confusing in some context unless it's 
ridiculouslyVerboseAndWastesALotOfSpaceAndIsImpossibleToTypeOrRead. 
Even when names do get confusing, this can be solved by using static 
import for whatever module the most confusion is coming from.  (For 
example, due to its terse naming scheme I usually use static import for 
std.file.)  Typing the fully qualified name resolves any confusion.


 When I program in D, I take care of keeping often in my mind that
 "int" is
 not an integer number, but a unchecked signed 2-complement
 32-bits-wide bit
 field. Forgetting it causes several bugs and troubles.


 And when you program in floating point, you have to keep in mind the
 limitations of the exponent and the mantissa.

 And when you write a recursive function, you have to be mindful of stack
 limitations.

 There's no escaping what a computer is. In any engineering profession,
 you've got to keep in mind that your design becomes real parts made out
 of real materials, and those materials are far from ideal. Forget that
 at one's peril.


Interesting argument and I completely agree.  This illustrates a big 
difference between engineers/programmers/natural scientists and 
mathematicians/computer scientists:  The former view 
equations/theory/models as a convenient approximation of reality, to be 
abandoned when it's no longer useful, and view all abstractions as 
leaky.  To the latter, the theory/equations/models have a life of their own.

D is a language designed by an engineering mind (two if you count 
Andrei, who did his undergrad in EE but his Ph.D. in computer science), 
for engineering minds.  I also have an engineering/natural science 
background and very little formal comp sci or theoretical/abstract 
mathematics training, which might explain D's appeal to me.  Those that 
are into theoretical purity will unavoidably hate the language.  Those 
that care more about being able to abstract away exactly what they want 
to and nothing more will love it.


 ----

 This reminds me of the experience of a good friend of mine, very smart,
 who decided to learn Fortran by reading the DEC Fortran reference
 manual. He wrote his first program, and it worked perfectly the first
 time (did I say he was very smart?), except for one detail. It ran
 incredibly slowly.

 He poured over his listing and the manual, and could find nothing wrong.
 Finally, he took the listing (back in those days, we worked from paper
 listings) to my roommate and asked for help.

 My roommate looked at it and says, there's your problem. You are writing
 to a file by opening it, appending a single character, then closing it,
 in a loop. Don't you know you're supposed to open the file once, do all
 the writes, then close it?

 No, says my friend, the manual said nothing about that, although when
 you think about how the computer must work when writing a file, it is
 obvious.


Again, pretty insightful.  One of the conclusions I've come to in terms 
of pedagogy is that no amount of rote knowledge can ever substitute for 
having a good mental model of a system.  When I was an undergrad the 
biggest difference I noticed between the successful and unsuccessful 
students was that the successful ones would try to form a comprehensive 
mental model of the material, where the unsuccessful students would 
focus on rote memorizing facts and procedures.  Similarly, when I TA'd a 
course a couple years ago, I tried to encourage the professor to ask 
exam questions that were as hard as possible to get by rote (no canned 
procedure would work) but as easy as possible if you had a solid mental 
model of the material.
Nov 10 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/10/2011 7:30 PM, dsimcha wrote:

 Again, pretty insightful. One of the conclusions I've come to in terms of
 pedagogy is that no amount of rote knowledge can ever substitute for having a
 good mental model of a system. When I was an undergrad the biggest difference I
 noticed between the successful and unsuccessful students was that the
successful
 ones would try to form a comprehensive mental model of the material, where the
 unsuccessful students would focus on rote memorizing facts and procedures.
 Similarly, when I TA'd a course a couple years ago, I tried to encourage the
 professor to ask exam questions that were as hard as possible to get by rote
(no
 canned procedure would work) but as easy as possible if you had a solid mental
 model of the material.


I agree with this 100%.

Formula pluggers aren't real engineers. I've encountered many of the former,
who 
produced crap because they were unable to understand the limitations of the 
models the book formulas were based on.

For an example of the non-roteness of a good exam, I remember a question on my 
junior math exam. The lectures had covered fourier transforms, which are based 
on sine and cosine. The exam question was to derive the transforms using the 
hyperbolic sine and cosines. If you didn't get how the transforms were derived, 
and where to change things for the hyperbolics, you were sunk.
Nov 10 2011
parent Russel Winder <russel russel.org.uk> writes:
On Thu, 2011-11-10 at 19:46 -0800, Walter Bright wrote:

 On 11/10/2011 7:30 PM, dsimcha wrote:

 Again, pretty insightful. One of the conclusions I've come to in terms =




of

 pedagogy is that no amount of rote knowledge can ever substitute for ha=




ving a

 good mental model of a system. When I was an undergrad the biggest diff=




erence I

 noticed between the successful and unsuccessful students was that the s=




uccessful

 ones would try to form a comprehensive mental model of the material, wh=




ere the

 unsuccessful students would focus on rote memorizing facts and procedur=




es.

 Similarly, when I TA'd a course a couple years ago, I tried to encourag=




e the

 professor to ask exam questions that were as hard as possible to get by=




 rote (no

 canned procedure would work) but as easy as possible if you had a solid=




 mental

 model of the material.




The is why educators are supposed to worry about pedagogy and
integrative material.  It is well known that rote learning leads to poor
mental models of the material, and that good mental models are what
people need.  Sounds like your professor wasn't interested in education
of students.


 I agree with this 100%.
=20
 Formula pluggers aren't real engineers. I've encountered many of the form=


er, who=20

 produced crap because they were unable to understand the limitations of t=


he=20

 models the book formulas were based on.
=20
 For an example of the non-roteness of a good exam, I remember a question =


on my=20

 junior math exam. The lectures had covered fourier transforms, which are =


based=20

 on sine and cosine. The exam question was to derive the transforms using =


the=20

 hyperbolic sine and cosines. If you didn't get how the transforms were de=


rived,=20

 and where to change things for the hyperbolics, you were sunk.


The point here, and it is a crucial one, is that if you have a good
mental model you can deal with things outside of the things you have met
directly before.  Having a good mental model of things allows for
hypothesis building, for extrapolation and interpolation, basically for
reasoning.

Sadly far too many folk are not even conversant in the the 3 Rs (*).



(*) Anyone who said Reading, 'Riting, and 'Rithmatic, go in the corner
and wear the dunces hat, it's Reading, Recording and Reckoning.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 11 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:j9i4tf$u4s$1 digitalmars.com...

 Vote++.  Really bad names hurt, but there's no such thing as a perfect 
 name.  Any name will be confusing in some context unless it's 
 ridiculouslyVerboseAndWastesALotOfSpaceAndIsImpossibleToTypeOrRead. Even 
 when names do get confusing, this can be solved by using static import for 
 whatever module the most confusion is coming from.  (For example, due to 
 its terse naming scheme I usually use static import for std.file.)  Typing 
 the fully qualified name resolves any confusion.

...........

 Interesting argument and I completely agree.  This illustrates a big 
 difference between engineers/programmers/natural scientists and 
 mathematicians/computer scientists:  The former view 
 equations/theory/models as a convenient approximation of reality, to be 
 abandoned when it's no longer useful, and view all abstractions as leaky. 
 To the latter, the theory/equations/models have a life of their own.

 D is a language designed by an engineering mind (two if you count Andrei, 
 who did his undergrad in EE but his Ph.D. in computer science), for 
 engineering minds.  I also have an engineering/natural science background 
 and very little formal comp sci or theoretical/abstract mathematics 
 training, which might explain D's appeal to me.  Those that are into 
 theoretical purity will unavoidably hate the language.  Those that care 
 more about being able to abstract away exactly what they want to and 
 nothing more will love it.

...........

 Again, pretty insightful.  One of the conclusions I've come to in terms of 
 pedagogy is that no amount of rote knowledge can ever substitute for 
 having a good mental model of a system.  When I was an undergrad the 
 biggest difference I noticed between the successful and unsuccessful 
 students was that the successful ones would try to form a comprehensive 
 mental model of the material, where the unsuccessful students would focus 
 on rote memorizing facts and procedures.  Similarly, when I TA'd a course 
 a couple years ago, I tried to encourage the professor to ask exam 
 questions that were as hard as possible to get by rote (no canned 
 procedure would work) but as easy as possible if you had a solid mental 
 model of the material.


This is a fantastic post, you hit the nail right on the head on all three 
parts, and couldn't have worded any of it better. Strongly agree on all of 
it. This should be framed and hung on the walls at every school. (Well, ok, 
maybe the first part wouldn't be relevent at some schools in some 
disciplines... ;))

In my school experience (both high school and college), the students who 
were well versed in and heavily focused on rote regurgitation were 
consistently the ones with the best grades, and the ones who where therefore 
considered to be "smart" even though they couldn't have reasoned to save 
their lives. That *needs* to change.
Nov 11 2011
next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 11.11.2011, 13:37 Uhr, schrieb Nick Sabalausky <a a.a>:


 In my school experience (both high school and college), the students who
 were well versed in and heavily focused on rote regurgitation were
 consistently the ones with the best grades, and the ones who where  
 therefore
 considered to be "smart" even though they couldn't have reasoned to save
 their lives. That *needs* to change.


I believe this is understood and deliberate and even more diverse. In  
Bavaria/Germany the rule of thumb for tests is:

reproduction (20%) - Learning years and formulas
reorganization (40%) - Still learned knowledge, but with changed  
parameters. In history, from the European colonies in Africa, create a  
ranking of European influences in Africa
transfer (30%) - Apply a learned method to a new field and knowing which  
method will lead to the goal. For example, knowing the details and  
backgrounds of the French revolution, you can appraise why another one  
failed.
new field (10%) - Find a solution in a new field, just from facts given in  
the test itself.

You see, it is all put into laws and regulations. You get test with 40%  
questions that require some sort of reasoning. :)
Nov 11 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2011 4:37 AM, Nick Sabalausky wrote:

 In my school experience (both high school and college), the students who
 were well versed in and heavily focused on rote regurgitation were
 consistently the ones with the best grades, and the ones who where therefore
 considered to be "smart" even though they couldn't have reasoned to save
 their lives. That *needs* to change.


That was true of my high school, but not my college (Caltech). At Caltech, rote 
memorization would get you precisely nowhere. Exams were (by institute policy) 
open book and open note. This did have the interesting effect of forcing the 
profs to come up with exams that could not be completed by rote.

I came to attend Caltech mostly by accident, and it was a most fortunate 
accident. The attitude and culture of Caltech suited my personality almost 
perfectly.

(For another example, professors were not allowed to take attendance at 
lectures, not allowed to make attendance part of the grade, not allowed to 
proctor exams (100% honor system), etc. I loved being treated like an adult for 
the first time.)

One might ask, isn't it easy to cheat under such a system? Yes, it is. But such 
a system had an unexpected effect. The students did not regard themselves as
the 
adversaries of the professors. The students liked the honor system so much that 
if someone did cheat, they'd get ostracized. Ostracism is a powerful and very 
effective means of getting conformance. Almost nobody cheated (to my knowledge).
Nov 11 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:j9jqkb$1sm$1 digitalmars.com...

 On 11/11/2011 4:37 AM, Nick Sabalausky wrote:

 In my school experience (both high school and college), the students who
 were well versed in and heavily focused on rote regurgitation were
 consistently the ones with the best grades, and the ones who where 
 therefore
 considered to be "smart" even though they couldn't have reasoned to save
 their lives. That *needs* to change.


 That was true of my high school, but not my college (Caltech). At Caltech, 
 rote memorization would get you precisely nowhere. Exams were (by 
 institute policy) open book and open note. This did have the interesting 
 effect of forcing the profs to come up with exams that could not be 
 completed by rote.

.....

 (For another example, professors were not allowed to take attendance at 
 lectures, not allowed to make attendance part of the grade, not allowed to 
 proctor exams (100% honor system), etc. I loved being treated like an 
 adult for the first time.)


Wow. I'm genuinely impressed. A college that seems to actually have 
intelligent management. I had become convinced such a thing just simply 
didn't exist (I'm still fairly certain it doesn't exist in Ohio...Hell, I 
refuse to accept the notion that OSU is even a school at all - Football 
franchise (with a drooling, slobbering rabid following)? Yes, definitely. 
Commercial-zoned real-estate developer? Yes, oddly enough. School? 
Absolutely not).

Just to comment on one little aspect of what you said: At all the colleges I 
went to (three of them: A large public party school (BGSU), a small 
highy-regarded private school (John Carroll U), and a community college 
(Lakeland CC) that the locals seem to really like but had major power 
struggles and ego trips (talk about storm in a teacup)), at all of those, 
anytime there was an shool-wide institutionalized rule (which was rare in 
the case of the profs: they were mostly allowed to run amok), it was 
inevitably something idiotic, such as (at LCC and I think JCU IIRC) all 
classes being required to have an official book that the students must 
purchase (typically from the school's own bookstore, naturally). Or (at 
BGSU) first and second year non-local students being required to live 
on-campus *even* when there aren't enough dorms available (heaven forbid 
they should just simply *not* overbook enrollment). They were all total 
revolving-door scams.
Nov 12 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/12/2011 6:29 AM, Nick Sabalausky wrote:

 all
 classes being required to have an official book that the students must
 purchase (typically from the school's own bookstore, naturally).


That's just sad.
Nov 12 2011
prev sibling parent reply bcs <bcs example.com> writes:
On 11/11/2011 10:47 AM, Walter Bright wrote:

 On 11/11/2011 4:37 AM, Nick Sabalausky wrote:

 In my school experience (both high school and college), the students who
 were well versed in and heavily focused on rote regurgitation were
 consistently the ones with the best grades, and the ones who where
 therefore
 considered to be "smart" even though they couldn't have reasoned to save
 their lives. That *needs* to change.


 That was true of my high school, but not my college (Caltech). At
 Caltech, rote memorization would get you precisely nowhere. Exams were
 (by institute policy) open book and open note. This did have the
 interesting effect of forcing the profs to come up with exams that could
 not be completed by rote.

 I came to attend Caltech mostly by accident, and it was a most fortunate
 accident. The attitude and culture of Caltech suited my personality
 almost perfectly.

 (For another example, professors were not allowed to take attendance at
 lectures, not allowed to make attendance part of the grade, not allowed
 to proctor exams (100% honor system), etc. I loved being treated like an
 adult for the first time.)

 One might ask, isn't it easy to cheat under such a system? Yes, it is.
 But such a system had an unexpected effect. The students did not regard
 themselves as the adversaries of the professors. The students liked the
 honor system so much that if someone did cheat, they'd get ostracized.
 Ostracism is a powerful and very effective means of getting conformance.
 Almost nobody cheated (to my knowledge).


The/a solution to the cheating problem at anything but the last set of 
classes is to make the next set of classes *painful* to take if you 
don't know the materiel from the prerequisite. The point of the class 
after all is to teach you the materiel (whatever that amounts to) and if 
you've got the materiel how you got there is irrelevant. That all 
depends however on a carefully tuned definition of "got the materiel".
Nov 12 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/12/2011 9:15 AM, bcs wrote:

 The/a solution to the cheating problem at anything but the last set of classes
 is to make the next set of classes *painful* to take if you don't know the
 materiel from the prerequisite. The point of the class after all is to teach
you
 the materiel (whatever that amounts to) and if you've got the materiel how you
 got there is irrelevant. That all depends however on a carefully tuned
 definition of "got the materiel".


Caltech also had a policy that you could not only place out of any class by 
taking (and passing) the final exam for it, you would even receive *credit* for 
it. I've seen many that did the former, but none other that went as far as the 
latter.

However, very, very few students ever managed to pass those exams without
taking 
the class :-) I never even bothered to try.
Nov 12 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:j9mjc8$2rln$1 digitalmars.com...

 On 11/12/2011 9:15 AM, bcs wrote:

 The/a solution to the cheating problem at anything but the last set of 
 classes
 is to make the next set of classes *painful* to take if you don't know 
 the
 materiel from the prerequisite. The point of the class after all is to 
 teach you
 the materiel (whatever that amounts to) and if you've got the materiel 
 how you
 got there is irrelevant. That all depends however on a carefully tuned
 definition of "got the materiel".


 Caltech also had a policy that you could not only place out of any class 
 by taking (and passing) the final exam for it, you would even receive 
 *credit* for it. I've seen many that did the former, but none other that 
 went as far as the latter.

 However, very, very few students ever managed to pass those exams without 
 taking the class :-) I never even bothered to try.


That's one of the main reasons I lost all respect for schools. With Caltech 
apparently being the one exception, schools never care whether or not you 
know the material (despite what they've convinced themselves). What they 
care about is 1. whether you're shelling out those tuition $Gs, and 2. 
whether you actually went through the class (and played "simon says" all the 
way through).

At all the schools I've been to that allowed testing out:

1. Like you said, they gave no credit.

2. They went to great lengths to prevent you from even *trying* to test out. 
They *officially* allowed testing out, but realistically they never 
*actually* granted permission to try. What they would do is hem and haw and 
try to talk you out of it until you hopefully gave up and went away, and if 
that didn't work, they would just outright deny the opportunity (or come up 
with some obscure rule to hide behind). What make it all the more 
infuriating, and patronizing, is that they would insist they were doing it 
all in the name of "helping" you.

3. Most of the teachers were so bad at what they were doing, and at writing 
good tests, that even if you did luck out and manage to get the opportunity 
to try, there would be a very good chance that even an expert in the field 
wouldn't be able to pass without knowing all the irrelevant details and 
idiosyncrasies of *exactly* how the instructor presented the material.
Nov 13 2011
parent reply Sean Kelly <sean invisibleduck.org> writes:
That hasn't been my experience, even at a community college I attended. I th=
ink it's really up to the teacher though, barring a school like Caltech that=
 actually has policies to encourage better teaching methods. Ironically, som=
e very well-respected schools seem to be big offenders. Berkeley, for exampl=
e, uses scantron tests almost exclusively, from what I understand, and combi=
ned with the drive to achieve, I've heard that cheating there is rampant. It=
's not size though. I attended a CSU that had smaller classes and no standar=
dized testing.=20

Sent from my iPhone

On Nov 13, 2011, at 6:04 AM, "Nick Sabalausky" <a a.a> wrote:


 "Walter Bright" <newshound2 digitalmars.com> wrote in message=20
 news:j9mjc8$2rln$1 digitalmars.com...

 On 11/12/2011 9:15 AM, bcs wrote:

 The/a solution to the cheating problem at anything but the last set of=20=







 classes
 is to make the next set of classes *painful* to take if you don't know=20=







 the
 materiel from the prerequisite. The point of the class after all is to=20=







 teach you
 the materiel (whatever that amounts to) and if you've got the materiel=20=







 how you
 got there is irrelevant. That all depends however on a carefully tuned
 definition of "got the materiel".


=20
 Caltech also had a policy that you could not only place out of any class=20=





 by taking (and passing) the final exam for it, you would even receive=20
 *credit* for it. I've seen many that did the former, but none other that=20=





 went as far as the latter.
=20
 However, very, very few students ever managed to pass those exams without=




=20

 taking the class :-) I never even bothered to try.


=20
 That's one of the main reasons I lost all respect for schools. With Caltec=


h=20

 apparently being the one exception, schools never care whether or not you=20=



 know the material (despite what they've convinced themselves). What they=20=



 care about is 1. whether you're shelling out those tuition $Gs, and 2.=20
 whether you actually went through the class (and played "simon says" all t=


he=20

 way through).
=20
 At all the schools I've been to that allowed testing out:
=20
 1. Like you said, they gave no credit.
=20
 2. They went to great lengths to prevent you from even *trying* to test ou=


t.=20

 They *officially* allowed testing out, but realistically they never=20
 *actually* granted permission to try. What they would do is hem and haw an=


d=20

 try to talk you out of it until you hopefully gave up and went away, and i=


f=20

 that didn't work, they would just outright deny the opportunity (or come u=


p=20

 with some obscure rule to hide behind). What make it all the more=20
 infuriating, and patronizing, is that they would insist they were doing it=


=20

 all in the name of "helping" you.
=20
 3. Most of the teachers were so bad at what they were doing, and at writin=


g=20

 good tests, that even if you did luck out and manage to get the opportunit=


y=20

 to try, there would be a very good chance that even an expert in the field=


=20

 wouldn't be able to pass without knowing all the irrelevant details and=20=



 idiosyncrasies of *exactly* how the instructor presented the material.
=20
=20
Nov 13 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2011 8:15 AM, Sean Kelly wrote:

 That hasn't been my experience, even at a community college I attended. I
 think it's really up to the teacher though, barring a school like Caltech
 that actually has policies to encourage better teaching methods. Ironically,
 some very well-respected schools seem to be big offenders. Berkeley, for
 example, uses scantron tests almost exclusively, from what I understand, and
 combined with the drive to achieve, I've heard that cheating there is
 rampant. It's not size though. I attended a CSU that had smaller classes and
 no standardized testing.


I still have my old exams. I should post them :-)

(I couldn't solve them now. However, that is not to say my education was 
useless. While I've forgotten the details of the classes, the main benefit
which 
has stuck is how to solve seemingly intractable problems, and how to learn how 
to solve them. I.e., it's taught me organized thinking methods.)

Another thing I picked up on at Caltech from the professors was the palpable
joy 
in knowing the material.
Nov 13 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Thu, 2011-11-10 at 19:24 -0800, Jonathan M Davis wrote:
[...]

 Bearophile has some good ideas, but he has too many of them for us to eve=


r=20

 deal with them all even if they were all really good, and many of them ar=


e=20

 incredibly trivial. Obviously, he can suggest as many ideas as he likes, =


but I=20

 think that he'd stand a better chance of getting his ideas implemented if=


 he=20

 presented far fewer of them. It would also take up less of everyone else'=


s=20

 time. He's a valuable member of the community, but it would be better for=


=20

 everyone (him included) if his signal to noise ratio were much higher.


Why don't they get turned into tickets such that work can be scheduled?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.858.1321004063.24802.digitalmars-d puremagic.com...

Why don't they get turned into tickets such that work can be scheduled?


I think most of them are.
Nov 11 2011
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 11.11.2011, 03:23 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:


 There's been a lot of agonizing over names in D lately. They are a  
 soul-sucking quagmire of wasting time.


I hope you see the difference between 'byte' which is confusing, but 100%  
consistent with (u)byte, (u)short, (u)int and (u)long, and other  
discussions about 'inout' which originated from in and out and will  
forever be confused with them. There is also some library functions, like  
clear() which looks like the well known action to remove all elements from  
a container when used with universal function call on  
(associative-)arrays, but has a different purpose.

This is all second-guessing now, but when these things add up, some people  
sensitive to unambiguous naming will put the all on the table. Especially  
since D attracts people from different programming languages, method names  
and keywords may already have two meanings to different people. Others  
names, like clear() are sort of standard and don't work the way of  
least-surprise in D. Things like this must be avoided in the future to  
keep D comprehensible:

http://www.digitalmars.com/d/archives/digitalmars/D/learn/Remove_all_elements_in_an_associative_array_27791.html
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=135001
http://d.puremagic.com/issues/show_bug.cgi?id=5683
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Clear_big_AAs_27256.html
http://d.puremagic.com/issues/show_bug.cgi?id=5816
Nov 11 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2011 5:30 AM, Marco Leise wrote:

 I hope you see the difference between 'byte' which is confusing, but 100%
 consistent with (u)byte, (u)short, (u)int and (u)long, and other discussions
 about 'inout' which originated from in and out and will forever be confused
with
 them. There is also some library functions, like clear() which looks like the
 well known action to remove all elements from a container when used with
 universal function call on (associative-)arrays, but has a different purpose.



I do have to agree that there are two sides to everything.

For example, "immutable" used to be named "invariant". Unfortunately, I had to 
spend endless effort explaining to people about what invariant meant. I found I 
frequently described invariant as meaning immutable. When I said the word 
"immutable", people would get it.

I finally had to accept the inevitable, and change the keyword.
Nov 11 2011
prev sibling parent reply SimonM <user example.net> writes:
On 2011/11/11 02:20 AM, Walter Bright wrote:

 You're also free to add the following to your code:

 alias byte int8;
 alias short int16;
 alias int int32;

 If you feel it improves your code, go for it.


I *almost* wish I could say:

alias size_t int;
Nov 11 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"SimonM" <user example.net> wrote in message 
news:j9ioe3$29tq$1 digitalmars.com...

 On 2011/11/11 02:20 AM, Walter Bright wrote:

 You're also free to add the following to your code:

 alias byte int8;
 alias short int16;
 alias int int32;

 If you feel it improves your code, go for it.


 I *almost* wish I could say:

 alias size_t int;


My experience with C/C++ makes me cringe at that :)
Nov 11 2011
parent SimonM <user example.net> writes:
On 2011/11/11 14:39 PM, Nick Sabalausky wrote:

 "SimonM"<user example.net>  wrote in message
 news:j9ioe3$29tq$1 digitalmars.com...

 On 2011/11/11 02:20 AM, Walter Bright wrote:

 You're also free to add the following to your code:

 alias byte int8;
 alias short int16;
 alias int int32;

 If you feel it improves your code, go for it.


 I *almost* wish I could say:

 alias size_t int;


 My experience with C/C++ makes me cringe at that :)


Oh yeah, and by 'int', I obviously meant 'uint'. Whoops!
Nov 11 2011
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 11.11.2011, 10:06 Uhr, schrieb SimonM <user example.net>:


 On 2011/11/11 02:20 AM, Walter Bright wrote:

 You're also free to add the following to your code:

 alias byte int8;
 alias short int16;
 alias int int32;

 If you feel it improves your code, go for it.


 I *almost* wish I could say:

 alias size_t int;


I know I wrote this before, but I can't hold back now *g*. I use:

alias size_t =E2=84=95;

I think on the move to 64-bit, the native machine word data type (which =
 =

was uint de facto), got left behind a little. size_t is not a keyword an=
d  =

it has an _ in its name. I don't know why _ type names look so odd to me=
.  =

It feels like using some very *special* type, not meant for every day us=
e.  =

So I went for =E2=84=95 bound to AltGr+N in private code.
Nov 11 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.11.2011 13:44, schrieb Marco Leise:

 Am 11.11.2011, 10:06 Uhr, schrieb SimonM <user example.net>:


 On 2011/11/11 02:20 AM, Walter Bright wrote:

 You're also free to add the following to your code:

 alias byte int8;
 alias short int16;
 alias int int32;

 If you feel it improves your code, go for it.


 I *almost* wish I could say:

 alias size_t int;


 I know I wrote this before, but I can't hold back now *g*. I use:

 alias size_t â„•;

 I think on the move to 64-bit, the native machine word data type (which
 was uint de facto), got left behind a little. size_t is not a keyword
 and it has an _ in its name. I don't know why _ type names look so odd
 to me. It feels like using some very *special* type, not meant for every
 day use. So I went for â„• bound to AltGr+N in private code.


That's confusing, as â„• usually is *any* number > 0 (or sometimes >= 0), 
so it's more like bigint (with a restriction to positive numbers) than 
size_t.

(Also none-ascii chars in code outside of strings is bad IMHO)

Cheers,
- Daniel
Nov 11 2011
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/11/2011 09:56 AM, Daniel Gibson wrote:


 (Also none-ascii chars in code outside of strings is bad IMHO)


In English code, right? :)

There are real problems of using the ASCII relatives of Turkish letters:

döndür: return
dondur: freeze
dön: turn
don: underwear
sık: squeeze
sik: (a four-letter word)

Thousands more... :)

Ali
Nov 11 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/11 12:54 PM, Ali Çehreli wrote:

 On 11/11/2011 09:56 AM, Daniel Gibson wrote:

  > (Also none-ascii chars in code outside of strings is bad IMHO)

 In English code, right? :)

 There are real problems of using the ASCII relatives of Turkish letters:

 döndür: return
 dondur: freeze
 dön: turn
 don: underwear
 sık: squeeze
 sik: (a four-letter word)

 Thousands more... :)

 Ali


Cool. Imagine this movie scene. A gangster is naked in a house of 
tolerance. A cop suddenly opens the door, and says: "Dondur! Durma sik! 
Döndür ile giymek don!" Missing the umlauts would quite confuse the 
gangster.


Andrei
Nov 11 2011
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/11/2011 11:06 AM, Andrei Alexandrescu wrote:

 On 11/11/11 12:54 PM, Ali Çehreli wrote:

 On 11/11/2011 09:56 AM, Daniel Gibson wrote:


 (Also none-ascii chars in code outside of strings is bad IMHO)


 In English code, right? :)

 There are real problems of using the ASCII relatives of Turkish letters:

 döndür: return
 dondur: freeze
 dön: turn
 don: underwear
 sık: squeeze
 sik: (a four-letter word)

 Thousands more... :)

 Ali


 Cool. Imagine this movie scene. A gangster is naked in a house of
 tolerance. A cop suddenly opens the door, and says: "Dondur! Durma sik!
 Döndür ile giymek don!" Missing the umlauts would quite confuse the
 gangster.


 Andrei


Ha ha! :)

Sadly though, something similar happened before: Husband kills her 
separated wife after misunderstanding her text message (or something 
like that). Although I can't find a link to the news story now.

Ali
Nov 11 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2011 11:23 AM, Ali Çehreli wrote:

 Sadly though, something similar happened before: Husband kills her separated
 wife after misunderstanding her text message (or something like that). Although
 I can't find a link to the news story now.


Reminds me of a bit in one of those old WW2 documentaries. A british soldier
was 
taught a bit of german. One day, he comes up on a german occupied pillbox and 
orders:

    Raus! Oder ich shiessen  (Come out, or I'll shoot!)

He was mystified by the sounds of laughter coming from the pillbox. Eventually, 
the germans did come out and surrender, and they told him he'd actually said:

    Raus! Oder ich sheissen  (Come out, or I'll shit!)
Nov 11 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.11.2011 20:50, schrieb Walter Bright:

 On 11/11/2011 11:23 AM, Ali Çehreli wrote:

 Sadly though, something similar happened before: Husband kills her
 separated
 wife after misunderstanding her text message (or something like that).
 Although
 I can't find a link to the news story now.


 Reminds me of a bit in one of those old WW2 documentaries. A british
 soldier was taught a bit of german. One day, he comes up on a german
 occupied pillbox and orders:

 Raus! Oder ich shiessen (Come out, or I'll shoot!)

 He was mystified by the sounds of laughter coming from the pillbox.
 Eventually, the germans did come out and surrender, and they told him
 he'd actually said:

 Raus! Oder ich sheissen (Come out, or I'll shit!)


Actually English speaking people tend to confuse "ei" and "ie" all the 
time, like in "Weiner" (supposed to be "Wiener"), Scheiße/Schieße etc

Cheers,
- Daniel
Nov 11 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2011 12:33 PM, Daniel Gibson wrote:

 Actually English speaking people tend to confuse "ei" and "ie" all the time,


Of course, since in German the second letter is pronounced, while in English
the 
first is. I would imagine that Germans learning English would have the opposite 
problem.
Nov 11 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.11.2011 22:03, schrieb Walter Bright:

 On 11/11/2011 12:33 PM, Daniel Gibson wrote:

 Actually English speaking people tend to confuse "ei" and "ie" all the
 time,


 Of course, since in German the second letter is pronounced, while in
 English the first is. I would imagine that Germans learning English
 would have the opposite problem.


In "Wiener" or "schießen" the "e" is not pronounced, it just stretches 
the "i" (like in English "believe").
In "Scheißen" however, both are pronounced, but like "ehh-ihh" but 
"ahh-ihh" (actually like the english "I" in "I suck at explaining the 
German language").
I think in German either the first letter or both are pronounced (but 
maybe there are counter-examples)

Cheers,
- Daniel
Nov 11 2011
prev sibling parent reply =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Fri, 11 Nov 2011 21:33:10 +0100, Daniel Gibson <metalcaedes gmail.com=

  =


wrote:


 Am 11.11.2011 20:50, schrieb Walter Bright:

 On 11/11/2011 11:23 AM, Ali =C3=87ehreli wrote:

 Sadly though, something similar happened before: Husband kills her
 separated
 wife after misunderstanding her text message (or something like that=






).

 Although
 I can't find a link to the news story now.


 Reminds me of a bit in one of those old WW2 documentaries. A british
 soldier was taught a bit of german. One day, he comes up on a german
 occupied pillbox and orders:

 Raus! Oder ich shiessen (Come out, or I'll shoot!)

 He was mystified by the sounds of laughter coming from the pillbox.
 Eventually, the germans did come out and surrender, and they told him=





 he'd actually said:

 Raus! Oder ich sheissen (Come out, or I'll shit!)


 Actually English speaking people tend to confuse "ei" and "ie" all the=


  =


 time, like in "Weiner" (supposed to be "Wiener"), Schei=C3=9Fe/Schie=C3=


=9Fe etc

Not to mention Deimos/Diemos, which popped up here a short while ago. :p=
Nov 11 2011
parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 11.11.2011, 22:34 Uhr, schrieb Simen Kj=C3=A6r=C3=A5s <simen.kjaras g=
mail.com>:


 On Fri, 11 Nov 2011 21:33:10 +0100, Daniel Gibson  =



 <metalcaedes gmail.com> wrote:


 Am 11.11.2011 20:50, schrieb Walter Bright:

 On 11/11/2011 11:23 AM, Ali =C3=87ehreli wrote:

 Sadly though, something similar happened before: Husband kills her
 separated
 wife after misunderstanding her text message (or something like tha=








t).

 Although
 I can't find a link to the news story now.


 Reminds me of a bit in one of those old WW2 documentaries. A british=







 soldier was taught a bit of german. One day, he comes up on a german=







 occupied pillbox and orders:

 Raus! Oder ich shiessen (Come out, or I'll shoot!)

 He was mystified by the sounds of laughter coming from the pillbox.
 Eventually, the germans did come out and surrender, and they told hi=






m

 he'd actually said:

 Raus! Oder ich sheissen (Come out, or I'll shit!)


 Actually English speaking people tend to confuse "ei" and "ie" all th=




e  =


 time, like in "Weiner" (supposed to be "Wiener"), Schei=C3=9Fe/Schie=C3=




=9Fe etc

 Not to mention Deimos/Diemos, which popped up here a short while ago. =


:p

And mysteriously it was me, a German, who made the correction, haha. Ful=
l  =

circle.
Nov 11 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 11.11.2011 19:54, schrieb Ali Çehreli:

 On 11/11/2011 09:56 AM, Daniel Gibson wrote:

  > (Also none-ascii chars in code outside of strings is bad IMHO)

 In English code, right? :)

 There are real problems of using the ASCII relatives of Turkish letters:

 döndür: return
 dondur: freeze
 dön: turn
 don: underwear
 sık: squeeze
 sik: (a four-letter word)

 Thousands more... :)

 Ali


I (almost?) always use english variables, classnames etc, even though 
it's not my native tongue.
And if I, for whatever reason, use non-english names I still stick to 
ascii.
I just image that someone else will want to understand or modify my code 
and he may not speak my language and may not have umlauts and stuff like 
that on his keyboard.

As I said, this does not apply to strings that are displayed to the 
user, obviously.
Nov 11 2011
parent reply bcs <bcs example.com> writes:
On 11/11/2011 12:26 PM, Daniel Gibson wrote:

 Am 11.11.2011 19:54, schrieb Ali Çehreli:

 On 11/11/2011 09:56 AM, Daniel Gibson wrote:


 (Also none-ascii chars in code outside of strings is bad IMHO)


 In English code, right? :)

 There are real problems of using the ASCII relatives of Turkish letters:

 döndür: return
 dondur: freeze
 dön: turn
 don: underwear
 sık: squeeze
 sik: (a four-letter word)

 Thousands more... :)

 Ali


 I (almost?) always use english variables, classnames etc, even though
 it's not my native tongue.
 And if I, for whatever reason, use non-english names I still stick to
 ascii.
 I just image that someone else will want to understand or modify my code
 and he may not speak my language


Why do you assume they will know English?


 and may not have umlauts and stuff like
 that on his keyboard.


Good point.


 As I said, this does not apply to strings that are displayed to the
 user, obviously.
Nov 12 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bcs wrote:

 Why do you assume they will know English?


I've never had a conversation with anyone who didn't know English.

:-P
Nov 12 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/12/2011 9:35 AM, Adam D. Ruppe wrote:

 I've never had a conversation with anyone who didn't know English.

 :-P


I have. There's usually a lot of arm-waving and aaaaahhhhhs and uuuummmms.

When I was in Tokyo, I kept a brochure from my hotel in my pocket. When you got 
into a taxi, just show the brochure to the driver. "Hai!" and straight home!
Nov 12 2011
prev sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 12.11.2011 18:20, schrieb bcs:

 On 11/11/2011 12:26 PM, Daniel Gibson wrote:

 Am 11.11.2011 19:54, schrieb Ali Çehreli:

 On 11/11/2011 09:56 AM, Daniel Gibson wrote:


 (Also none-ascii chars in code outside of strings is bad IMHO)


 In English code, right? :)

 There are real problems of using the ASCII relatives of Turkish letters:

 döndür: return
 dondur: freeze
 dön: turn
 don: underwear
 sık: squeeze
 sik: (a four-letter word)

 Thousands more... :)

 Ali


 I (almost?) always use english variables, classnames etc, even though
 it's not my native tongue.
 And if I, for whatever reason, use non-english names I still stick to
 ascii.
 I just image that someone else will want to understand or modify my code
 and he may not speak my language


 Why do you assume they will know English?


It's taught in schools all over the world and almost anybody who 
programs can at least read english (you're screwed otherwise because 
documentation of languages and (standard-) libs, and the classes etc in 
libraries themselves are usually in english).

Cheers,
- Daniel
Nov 13 2011
parent bcs <bcs example.com> writes:
On 11/13/2011 12:07 PM, Daniel Gibson wrote:

 Am 12.11.2011 18:20, schrieb bcs:

 On 11/11/2011 12:26 PM, Daniel Gibson wrote:

 Am 11.11.2011 19:54, schrieb Ali Çehreli:

 On 11/11/2011 09:56 AM, Daniel Gibson wrote:


 (Also none-ascii chars in code outside of strings is bad IMHO)


 In English code, right? :)

 There are real problems of using the ASCII relatives of Turkish
 letters:

 döndür: return
 dondur: freeze
 dön: turn
 don: underwear
 sık: squeeze
 sik: (a four-letter word)

 Thousands more... :)

 Ali


 I (almost?) always use english variables, classnames etc, even though
 it's not my native tongue.
 And if I, for whatever reason, use non-english names I still stick to
 ascii.
 I just image that someone else will want to understand or modify my code
 and he may not speak my language


 Why do you assume they will know English?


 It's taught in schools all over the world and almost anybody who
 programs can at least read english (you're screwed otherwise because
 documentation of languages and (standard-) libs, and the classes etc in
 libraries themselves are usually in english).

 Cheers,
 - Daniel


I've sat near conversations that were clearly in a language I didn't 
know and where the subject at hand was just as easy to identify. You get 
into a technical field and every third word is Geek no matter what the 
other two are.

I want to put a sketch in a move: two professors walk into a room, have 
a 10 minute heated argument about something and *then* notice they don't 
have any natural language in common.
Nov 14 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Wed, 2011-11-09 at 18:58 -0800, Walter Bright wrote:
[...]

 Python with 33, I think most would agree that is has a very consice gra=




mmer.

=20
 Python lacks a lot of powerful features that are in D.


<<I started to construct a terse reply and it has turned into a bit of
an essay.  Apologies.>>

Can I suggest that relating two languages just by abstract metrics such
as number of keywords and perceived simplicity of grammar is the start
of the slippery road to useless and irrelevant comparison.

Without measurement of the impact on actual software development,
without measurement of expressibility and expressivity, basically
without context and effect, any form of comparison such as number of
keywords is navel gazing with no positive outcome.

No matter the number of keywords and the simplicity of grammar that may,
or may not, be in favour of one language compared to another, trying to
compare a statically typed, native code generating language such as D to
a dynamic bytecode/virtual machine/just-in-time compiler based language
such as Python is like trying to compare a tiger with a boa constrictor.

Statements such as "Python lacks a lot of powerful features that are in
D" are fundamentally useless, just as "D lacks a lot of powerful
features that are in Python" is equally useless, albeit equally true --
possibly.  First of all, without explicit statement of features, the
statements have no foundation to be proven right or wrong, and second
without putting those features into the context of developing systems or
applications software systems, there is no framework for comparison.

I know this forum is about D language community building, and one of the
techniques is to ensure everyone agrees on the common enemies, but to
pick on all languages other than D as "enemy" is to miss the whole point
of the new polyglot world.

On the JVM systems now use Groovy, Scala, Clojure, JRuby, as well as
Java.  In scientific HPC, systems now use Python, Fortran, C++ all
interworking.  Systems comprising static language components (as dynamic
libraries) and dynamic language components are now the norm.  Part of
the rationale for this is the run time MOP of the dynamic languages
which allows for techniques not possible using statically typed
languages, whereas the statically typed, compiled languages generally
run computational code much faster (IO bound code runs slowly
independent of language).

It is a fundamentally wasted exercise to have discussions within the
community slagging off other languages.  No matter how good D is
compared to C++, or any other language, unless D gets traction and take
up, it is a long dead language.

Google is throwing out new languages on a monthly basis just now.  They
make very carefully constructed marketing announcements to ensure
maximum attention and then let the market decide.  Go will likely become
the C beater, albeit with masses of money shoved at it by Google to
ensure usage.  Dart may or may not take off, but if it does it will
decimate the JavaScript market.  Scala is trying to replace Java (silly
concept but...) and people are throwing money at it to do so.

Without a properly financed and orchestrated marketing campaign to push
D out there to the C, C++ and Fortran crowd and/or a group of people who
could be the "killer audience", and then for there to be serious take
up, D remains a 10+ year old niche experiment with no mainline future.

I am now getting more and more requests for Python training from hard
core C++ folk, they are not asking for D training.  So on current
statistics Python is successful and D is not.

I would be very happy to have to construct D training courses because
there was a good client base.  On current evidence I won't hold my
breath.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 10 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/10/2011 12:01 AM, Russel Winder wrote:

Your post has a lot of insightful comments, I'll just take this one:


 Statements such as "Python lacks a lot of powerful features that are in
 D" are fundamentally useless, just as "D lacks a lot of powerful
 features that are in Python" is equally useless, albeit equally true --
 possibly.  First of all, without explicit statement of features, the
 statements have no foundation to be proven right or wrong, and second
 without putting those features into the context of developing systems or
 applications software systems, there is no framework for comparison.


When I wrote that, I was thinking of things D has like support for concurrency, 
immutability and purity. These are outside the static vs dynamic typing issue, 
and so I thought it fair to consider them. I also believe they are powerful and 
important features.
Nov 10 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Thu, 2011-11-10 at 01:31 -0800, Walter Bright wrote:
[...]

 When I wrote that, I was thinking of things D has like support for concur=


rency,=20

 immutability and purity. These are outside the static vs dynamic typing i=


ssue,=20

 and so I thought it fair to consider them. I also believe they are powerf=


ul and=20

 important features.


Concurrency, and it partner in crime parallelism -- which is related but
very different -- is a big issue on which Python currently, more or
less, sucks.  Multiprocessing is a great package and implements
processes and message passing, but is massively heavyweight.  PyPy is
looking to use the lessons of Stackless and STM to remove the GIL, but
Guido seems committed to keeping the GIL in CPython.  PyPy is already 5
times faster than CPython, and with the GIL removed stands to become the
replacement realization of Python for everyone.

Immutability is a weird concept in Python because it does not have the
"variables as labelled boxes holding values" model of variable, it has
"entry in dictionary" model of variables.  If you want to say:

	Math.PI =3D 3

you can: Python allows all symbols (bar two or three weird ones) to be
rebound as and when.  Or to put it another way Python doesn't understand
the word immutability, at least of variables.  Immutability of values is
a different matter:  list values, dict values, and set values are
mutable, all other values are immutable.

Purity is not really something I understand here without some lead in.
I guess I failed to read part of Andrei's book ;-)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 10 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/10/2011 2:00 AM, Russel Winder wrote:

 Purity is not really something I understand here without some lead in.
 I guess I failed to read part of Andrei's book ;-)


A pure function in D is one that has no side effects. It is set by adding the 
keyword "pure" to a function, and is checked by the compiler.

A pure function may not modify any data reachable through its parameters, may 
not read or write to any mutable global state, and can only call functions that 
also are either pure or restrict the variables they modify to those of the 
calling pure function's.

A pure function may allocate data via new, and may throw an exception.
Nov 10 2011
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 10, 2011 03:34:07 Walter Bright wrote:

 On 11/10/2011 2:00 AM, Russel Winder wrote:

 Purity is not really something I understand here without some lead in.
 I guess I failed to read part of Andrei's book ;-)


 
 A pure function in D is one that has no side effects. It is set by adding
 the keyword "pure" to a function, and is checked by the compiler.
 
 A pure function may not modify any data reachable through its parameters,
 may not read or write to any mutable global state, and can only call
 functions that also are either pure or restrict the variables they modify
 to those of the calling pure function's.
 
 A pure function may allocate data via new, and may throw an exception.


That's not really true anymore thanks to the distinction of strongly pure and 
weakly pure. It's true for strongly pure, but for pure as a whole, all it 
guarantees is that the function doesn't access any mutable global or static 
state and only calls functions which are pure. pure on its own makes _zero_ 
guarantees about the parameters. It's only when the parameters are immutable 
or implicitly convertible to immutable that anything about the parameters is 
guaranteed.

- Jonathan M Davis
Nov 10 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.814.1320912127.24802.digitalmars-d puremagic.com...

It is a fundamentally wasted exercise to have discussions within the
community slagging off other languages.  No matter how good D is
compared to C++, or any other language, unless D gets traction and take
up, it is a long dead language.


But for D to get traction, people need to know how good it is compared to 
other langauges.

Well, either that or just some $$$ bullshit like Issue 9.
Nov 10 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/10/11 2:01 AM, Russel Winder wrote:

 Without a properly financed and orchestrated marketing campaign to push
 D out there to the C, C++ and Fortran crowd and/or a group of people who
 could be the "killer audience", and then for there to be serious take
 up, D remains a 10+ year old niche experiment with no mainline future.


That would help, but I'm not sure that that would be a necessity. There 
are languages that are doing well without massive marketing (Perl, Ruby, 
Python).


 I am now getting more and more requests for Python training from hard
 core C++ folk, they are not asking for D training.  So on current
 statistics Python is successful and D is not.

 I would be very happy to have to construct D training courses because
 there was a good client base.  On current evidence I won't hold my
 breath.


I'm offering training on D in addition to C++ and Machine Learning, but 
so far there were no requests for D.

Anyhow, I think you're making good points (quite self-evident to me). 
One simple amend I'd make is that at the end of the day clearly D must 
be a solid technical offering (something that we've recently made very 
good progress on), and inevitably the quality of the language, 
libraries, and tools, will be compared against competing languages. 
Slagging off other languages for not doing e.g. concurrency or generics 
as well as D does would be a mistake, but presenting concurrency or 
generics as differentiating features of D is definitely a good thing to do.


Andrei
Nov 10 2011
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:j9go3v$arj$1 digitalmars.com...

 On 11/10/11 2:01 AM, Russel Winder wrote:

 Without a properly financed and orchestrated marketing campaign to push
 D out there to the C, C++ and Fortran crowd and/or a group of people who
 could be the "killer audience", and then for there to be serious take
 up, D remains a 10+ year old niche experiment with no mainline future.


 That would help, but I'm not sure that that would be a necessity. There 
 are languages that are doing well without massive marketing (Perl, Ruby, 
 Python).


True but somehow they manage to become famous because there was a killer 
feature
everyone wanted to use. If I recall correctly:

Perl - An easy way to create complex shell scripts and the major language to 
be used for web development (CGI)
Ruby - It only took off because Ruby on Rails
Python - People only started taking it serious after Zope appeared

So it was a bit like JavaScript, where the majority of developers took 
interest in the language because
of some task which was a kind of sales speach for the language.

This is still missing for D, regardless how good the language might be.

--
Paulo
Nov 10 2011
next sibling parent reply J Arrizza <cppgent0 gmail.com> writes:
 True but somehow they manage to become famous because there was a
 killer feature everyone wanted to use. If I recall correctly:

 Perl - An easy way to create complex shell scripts and the major language
 to
 be used for web development (CGI)
 Ruby - It only took off because Ruby on Rails
 Python - People only started taking it serious after Zope appeared


Paulo, with respect, I disagree. A single killer feature does not have
enough breadth to entice a developer community that has large and varied
needs from a language.

To me, it is this that caused the success of these languages in a short
time:

Perl has CPAN
Ruby has gems
Python has PyPi.
Java has the JDK



All of the libraries are huge and, just as importantly, they're organized
(although some better than others).

Depending on your level of cynicism, these libraries show one or more of
the following about a language:

1) In short, if it's good enough for CPAN/gems/PyPi, it's probably good
enough for my little application. Right?

A large library shows a strong, deep maturity of the language itself. You
can not write thousands of varied utilities, tools, application frameworks,
etc. etc. without a well functioning, clean, nearly bug-free language.

All the kinks are worked out. As the library was being written, enough
people bitched about these and those problems and they got fixed. They
complained about the aspects of the language they were facing as they were
writing their piece of the library. All those opinions, all those fixes,
led to a fleshing out and stabilization of the language features. It now
has breadth *and* depth.

2) a plunging chasm of self-serving laziness in the developer community.
Why code it myself? Let someone else do the heavy lifting and then I can
use it and look great...

Example: I need the current price of some mutual funds. Sure I could do it
the old fashioned way and screen scrape some html, blah blah. Or I could go
to CPAN, find the module that does it (and there always is one) and write
three lines of code.  Oh wait I wanted Canadian mutual funds. No problem.
Done.

3) A vote of confidence by many other developers the language is going to
stick around. There are always zealots for any given language, but with a
substantial base of people numbering in the thousands or better tens of
thousands, perhaps it's a safe bet the language will be there in 15 years.
 And they are "voting" by writing lots and lots of code, so it's not just
jaw.


John
Nov 10 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-11 05:35, J Arrizza wrote:

     True but somehow they manage to become famous because there was a
     killer feature everyone wanted to use. If I recall correctly:

     Perl - An easy way to create complex shell scripts and the major
     language to
     be used for web development (CGI)
     Ruby - It only took off because Ruby on Rails
     Python - People only started taking it serious after Zope appeared


 Paulo, with respect, I disagree. A single killer feature does not have
 enough breadth to entice a developer community that has large and varied
 needs from a language.

 To me, it is this that caused the success of these languages in a short
 time:

     Perl has CPAN
     Ruby has gems
     Python has PyPi.
     Java has the JDK



I'm working on a package manager for D:

https://github.com/jacob-carlborg/orbit
https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

-- 
/Jacob Carlborg
Nov 10 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2011-11-11 at 08:53 +0100, Jacob Carlborg wrote:
[...]

=20
 I'm working on a package manager for D:
=20
 https://github.com/jacob-carlborg/orbit
 https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D


What is needed is some direct or indirect resources to allow this work
to happen full time rather than in and out.

Ditto work on build so that there are no hiccups when people want to
intermix C, C++ and D using Make, Autotools, CMake, SCons, Waf,...

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 11 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-11-11 10:32, Russel Winder wrote:

 On Fri, 2011-11-11 at 08:53 +0100, Jacob Carlborg wrote:
 [...]

 I'm working on a package manager for D:

 https://github.com/jacob-carlborg/orbit
 https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D


 What is needed is some direct or indirect resources to allow this work
 to happen full time rather than in and out.

 Ditto work on build so that there are no hiccups when people want to
 intermix C, C++ and D using Make, Autotools, CMake, SCons, Waf,...


I wouldn't have any problem if I could work on this full time, but 
unfortunately I need to make some money to survive.

-- 
/Jacob Carlborg
Nov 11 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2011-11-11 at 16:44 +0100, Jacob Carlborg wrote:
[...]

 I wouldn't have any problem if I could work on this full time, but=20
 unfortunately I need to make some money to survive.


Here lies the problem for projects such as D, until there is resource
for core developers to work on stuff full time, or at least some
reasonably large fixed percentage part time, progress is unpredictable.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 11 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/11 9:54 AM, Russel Winder wrote:

 On Fri, 2011-11-11 at 16:44 +0100, Jacob Carlborg wrote:
 [...]

 I wouldn't have any problem if I could work on this full time, but
 unfortunately I need to make some money to survive.


 Here lies the problem for projects such as D, until there is resource
 for core developers to work on stuff full time, or at least some
 reasonably large fixed percentage part time, progress is unpredictable.


We've been fortunate to have unpredictably good progress for 2011. Also, 
I believe that with better organization alone, the productivity can be 
improved by 30% or more.

Andrei
Nov 11 2011
prev sibling parent Somedude <lovelydear mailmetrash.com> writes:
Le 11/11/2011 05:35, J Arrizza a écrit :


     Perl has CPAN
     Ruby has gems
     Python has PyPi.
     Java has the JDK



 All of the libraries are huge and, just as importantly, they're
 organized (although some better than others).

 Depending on your level of cynicism, these libraries show one or more of
 the following about a language:


Java has the JDK, in itself a very high quality and very complete 
library. But it also has the Apache Foundation for just about everything 
else.

And the Java Community Process for defining new APIs and their evolution.
Python also has the equivalent of the JCP.
The D community is still a bit small for such organisations, but there 
is already some sort of community process, which is a good step in the 
right direction.
Nov 12 2011
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Thu, 2011-11-10 at 20:35 -0800, J Arrizza wrote:

 True but somehow they manage to become famous because there was a
 killer feature everyone wanted to use. If I recall correctly:

 Perl - An easy way to create complex shell scripts and the major langua=




ge

 to
 be used for web development (CGI)
 Ruby - It only took off because Ruby on Rails
 Python - People only started taking it serious after Zope appeared




Not sure about Python and Zope.  Whereas most programmers and their
bosses know about Perl and CGI, and Ruby on Rails, many have never even
heard of Zope.  Python gets is main indirect marketing from being a
nicer language than Perl, and the dynamic language for driving C stuff.
C code base folk generally love Python since it can be used for building
integration and system test suites.

Also of course Python and Lua are the languages that provide the dynamic
plugin support for a huge range of C/C++ systems in the games and
post-production industries.


 Paulo, with respect, I disagree. A single killer feature does not have
 enough breadth to entice a developer community that has large and varied
 needs from a language.


But in developing the reputation it is critical to have a high profile
showcase.  Ruby would not have caught on as it did without Rails.  This
revolutionized Web application development and made Ruby a trendy
language.  Grails put Groovy front and centre in people's minds.  Whilst
Ruby is not making great strides outside the Rails arena, Groovy is now
more used generally in JVM systems that with just Grails.


 To me, it is this that caused the success of these languages in a short
 time:
=20
 Perl has CPAN
 Ruby has gems
 Python has PyPi.
 Java has the JDK



And LaTeX has CTAN.  Certainly CPAN, gems, PyPI are massive resources
for Perl, Ruby and Python, but they are not sole success factors.  With
them success is possible, without them success is unlikely -- though
note Perl was hugely popular which caused CPAN to be created.

Java JDK is a different beast.



It is interesting that there is an explosion of languages on JVM, but

language it is not directly in control of.


 All of the libraries are huge and, just as importantly, they're organized
 (although some better than others).
=20
 Depending on your level of cynicism, these libraries show one or more of
 the following about a language:
=20
 1) In short, if it's good enough for CPAN/gems/PyPi, it's probably good
 enough for my little application. Right?
=20
 A large library shows a strong, deep maturity of the language itself. You
 can not write thousands of varied utilities, tools, application framework=


s,

 etc. etc. without a well functioning, clean, nearly bug-free language.
=20
 All the kinks are worked out. As the library was being written, enough
 people bitched about these and those problems and they got fixed. They
 complained about the aspects of the language they were facing as they wer=


e

 writing their piece of the library. All those opinions, all those fixes,
 led to a fleshing out and stabilization of the language features. It now
 has breadth *and* depth.


This is a strong point: a large quality, extensible library shows a
successful infrastructure.


 2) a plunging chasm of self-serving laziness in the developer community.
 Why code it myself? Let someone else do the heavy lifting and then I can
 use it and look great...
=20
 Example: I need the current price of some mutual funds. Sure I could do i=


t

 the old fashioned way and screen scrape some html, blah blah. Or I could =


go

 to CPAN, find the module that does it (and there always is one) and write
 three lines of code.  Oh wait I wanted Canadian mutual funds. No problem.
 Done.


Why is this wrong?


 3) A vote of confidence by many other developers the language is going to
 stick around. There are always zealots for any given language, but with a
 substantial base of people numbering in the thousands or better tens of
 thousands, perhaps it's a safe bet the language will be there in 15 years=


.

  And they are "voting" by writing lots and lots of code, so it's not just
 jaw.


On the other hand, there is a huge amount of C and Fortran code out
there, so therefore C or Fortran is the language to code in.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 11 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 11.11.2011, 10:29 Uhr, schrieb Russel Winder <russel russel.org.uk>:


 It is interesting that there is an explosion of languages on JVM, but

 language it is not directly in control of.


Just as a historical anecdote: The Delphi inventor (Anders Hejlsberg)  
switched to Microsoft and was a co-inventor of .NET. Besides Delphi.NET  
there are Eiffel, Mercury, IronPython, Nemerle, Oberon ... you name it.  
Maybe I didn't understand what you mean by shedding, though :)
Nov 11 2011
parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2011-11-11 at 15:27 +0100, Marco Leise wrote:
[...]

 Just as a historical anecdote: The Delphi inventor (Anders Hejlsberg) =


=20

 switched to Microsoft and was a co-inventor of .NET. Besides Delphi.NET =


=20

 there are Eiffel, Mercury, IronPython, Nemerle, Oberon ... you name it. =


=20

 Maybe I didn't understand what you mean by shedding, though :)


For example IronPython and IronRuby were projects funded by Microsoft
and languages officially blessed by them for use on .NET.  Microsoft
have now terminated funding, and said to anyone using IronPython or
IronRuby "ok folks you are now on your own, go away".

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 11 2011
parent "Nick Sabalausky" <a a.a> writes:
"Russel Winder" <russel russel.org.uk> wrote in message 
news:mailman.869.1321025163.24802.digitalmars-d puremagic.com...

On Fri, 2011-11-11 at 15:27 +0100, Marco Leise wrote:
[...]

 Just as a historical anecdote: The Delphi inventor (Anders Hejlsberg)
 switched to Microsoft and was a co-inventor of .NET. Besides Delphi.NET
 there are Eiffel, Mercury, IronPython, Nemerle, Oberon ... you name it.
 Maybe I didn't understand what you mean by shedding, though :)


For example IronPython and IronRuby were projects funded by Microsoft
and languages officially blessed by them for use on .NET.  Microsoft
have now terminated funding, and said to anyone using IronPython or
IronRuby "ok folks you are now on your own, go away".


I think it's a good idea, anytime you have official blessing/funding from 
big business (even if it's an internal project), or heck, anytime you have 
*any* heavy reliance on some company big or small, to assume the possibility 
that status could go away at any minute. I don't mean this as a jab at 
either big business or any sanctioned projects like IronPython/Ruby, it just 
seems to be the nature of things: Sometimes a company will loose interest in 
something, or even flip 180, at the drop of a hat.

It's not just MS. Apple caught flack for doing that with Darwin (from what 
I've heard, anyway). Paint Shop Pro was (accidentially or deliberately, I 
don't know) driven into the ground when Corel bought JASC. I'm sure there's 
lots of other such stories with other companies.

For good reasons or not, it just happens sometimes. It's great to be able to 
take advantage of some outside help when it's available. But it's best to be 
prepared (to whatever extent possible) for it to dissapear without warning, 
just in case.

FWIW, a corrilarly to that (that I picked up from Joel on Software, IIRC, 
and tend to agree with) is: Don't rely on externals for anything 
mission-critical.
Nov 11 2011
prev sibling next sibling parent J Arrizza <cppgent0 gmail.com> writes:
On Fri, Nov 11, 2011 at 1:29 AM, Russel Winder <russel russel.org.uk> wrote:


 Paulo, with respect, I disagree. A single killer feature does not have
 enough breadth to entice a developer community that has large and varied
 needs from a language.


 But in developing the reputation it is critical to have a high profile
 showcase.  Ruby would not have caught on as it did without Rails.


Yes, I agree. But Rails is not a language feature, it is a set of modules.
But the reason it exists at all is because of the push within the language
community to create a repository (they were mimicking CPAN).



  With them success is possible, without them success is unlikely -- though
 note Perl was hugely popular which caused CPAN to be created.



True it was successful prior to CPAN, but Perl was one of the first
languages available when the web first appeared. In fact it set the stage:
now a language *has* to have an associated repository.

Why is this wrong?


It isn't wrong at all. The "market " for D - i.e. the developers - is
fragmented. To make it popular requires all of the market segments to be
addressed. One of those segments wants everything done for them. That can't
happen effectively for those folks without a central repository.



 On the other hand, there is a huge amount of C and Fortran code out
 there, so therefore C or Fortran is the language to code in.



Yes, and true for C++ too, but it's not coordinated.

I'm willing to bet Jacob's centralized repository is going to have a strong
impact on D's popularity. First it will serve as a focal point for D
contributors and second it will serve as a magnet for new users of D. Each
will build on the other with a snowball effect. Anything and everything put
in there is going to be beneficial to D's popularity. At some point the
breadth of the repository will tip project decisions in favor of using D.
And that will see the snowball turn into an avalanche.

Now to Paulo's point, one of those packages will be the killer app that
causes D to go wildly successful. Will it be a web framework like Rails or
CGI? Perhaps. But it could be something else. Here's my wish:
   - a replacement for X11 on ARM processors running embedded linux
   - a fully functional windowing library using native D that rides on top
of it and that is easy to configure, build and install

That combination would become bigger than Rails simply in terms of the
number of processors it runs on.
Nov 11 2011
prev sibling next sibling parent reply Danni Coy <danni.coy gmail.com> writes:
 Now to Paulo's point, one of those packages will be the killer app that
 causes D to go wildly successful. Will it be a web framework like Rails or
 CGI? Perhaps. But it could be something else. Here's my wish:
    - a replacement for X11 on ARM processors running embedded linux
    - a fully functional windowing library using native D that rides on top
 of it and that is easy to configure, build and install





Isn't that more or less what Wayland is (minus the D bit)?
I am pretty sure that Qt,Gtk and there respective D bindings will run on
top of it.



 Nov 11 2011



  parent  Johannes Pfau <spam example.com>  writes:


Danni Coy wrote:

 Now to Paulo's point, one of those packages will be the killer app
 that causes D to go wildly successful. Will it be a web framework
 like Rails or CGI? Perhaps. But it could be something else. Here's
 my wish:
    - a replacement for X11 on ARM processors running embedded linux
    - a fully functional windowing library using native D that rides
 on top of it and that is easy to configure, build and install





Isn't that more or less what Wayland is (minus the D bit)?
I am pretty sure that Qt,Gtk and there respective D bindings will run
on top of it.


Yes, that's basically wayland, although the situation on embedded socs
is a little crappy. Wayland needs the new DRM graphics driver
architecture, but almost all embedded systems still use simple
framebuffers + custom extensions for acceleration. TI and Samsung are
currently developing DRM drivers for OMAP4 and Tegra though.

BTW: Wayland is meant to be a library, the current display server is
only the reference implementation. If you wanted, you could write
bindings for the wayland library and write a display server in D.
-- 
Johannes Pfau



 Nov 12 2011



prev sibling  parent  J Arrizza <cppgent0 gmail.com>  writes:


On Fri, Nov 11, 2011 at 1:37 PM, Danni Coy <danni.coy gmail.com> wrote:


 Isn't that more or less what Wayland is (minus the D bit)?


 I am pretty sure that Qt,Gtk and there respective D bindings will run on
 top of it.


Perhaps it is.

Unfortunately I may have muddied the waters a little. My point is that
predicting the killer app is difficult. It may end being a web framework.
It may be a windowing library. Or not.

A better strategy is to make the repository easy to add to for contributors
and easy to use for people using it. If there is going to be a popular
app/utility/framework that comes out of that, it will happen. The greater
the variety and depth, the better.

John



 Nov 11 2011



prev sibling next sibling parent reply Caligo <iteronvexor gmail.com>  writes:


 Without a properly financed and orchestrated marketing campaign to push
 D out there to the C, C++ and Fortran crowd and/or a group of people who
 could be the "killer audience", and then for there to be serious take
 up, D remains a 10+ year old niche experiment with no mainline future.


That's like going back 20 years and telling Linus "without a properly
financed and orchestrated marketing campaign to push Linux out there..." ,
you get my drift.

Money and marketing are important, specially when you are developing
a proprietary system.  You can have a shit product, but with enough
marketing you can make people believe it's not shit; Microsoft has done it,
same with Sun and Java.

If D fails, it's not because of lack of money or marketing, but because of
lack of a healthy and growing community.  A healthy community is what all
successful open source projects have in common.  Moving to Github was a
step in the right direction, but it's not enough, and the people in charge
don't seem to have a clue as to how to build a community.  How many new
developers have joined the development of D/Phobos in the last year?  I bet
very few.  They haven't even fixed the link to that old site, and it's been
like that for far too long.

Where is "D/Phobos Developer's Guide" page?



 Nov 10 2011



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 11/10/2011 7:06 PM, Caligo wrote:

 Where is "D/Phobos Developer's Guide" page?


Andrei and I have talked about writing one, but it will help a lot if you would 
contribute a draft.



 Nov 10 2011



  parent  Caligo <iteronvexor gmail.com>  writes:


--20cf3079b74e88d3f604b1722b0b
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 10, 2011 at 9:47 PM, Walter Bright
<newshound2 digitalmars.com>wrote:


 On 11/10/2011 7:06 PM, Caligo wrote:


 Where is "D/Phobos Developer's Guide" page?


 Andrei and I have talked about writing one, but it will help a lot if you
 would contribute a draft.


Done.

Since I'm not a D developer, there is a lot that I had to leave blank, but
it's a draft nonetheless (maybe an outline).

It's loosely based on Python Dev Guide, and it uses Sphinx.  Change to
'ddevguide' and run 'make html', and you should end up with HTML files in
the build directory.

Whatever section I could not complete, I left TODO notes.  Read those and
complete the section if you can.

I hope the attachment goes through.
<http://sphinx.pocoo.org/>

--20cf3079b74e88d3f604b1722b0b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Nov 10, 2011 at 9:47 PM, Walter =
Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">=
newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex;">
<div class=3D"im">On 11/10/2011 7:06 PM, Caligo wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

</blockquote>
<br></div>
Andrei and I have talked about writing one, but it will help a lot if you w=
ould contribute a draft.<br>




 you should end up with HTML files in the build directory.<br>
<br>Whatever section I could not complete, I left TODO notes.=A0 Read those=
 and complete the section if you can.<br><br>I hope the attachment goes thr=
ough.<br><a href=3D"http://sphinx.pocoo.org/"></a>=20

--20cf3079b74e88d3f604b1722b0b--



 Nov 11 2011



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/10/11 9:06 PM, Caligo wrote:

 If D fails, it's not because of lack of money or marketing, but because
 of lack of a healthy and growing community.  A healthy community is what
 all successful open source projects have in common.  Moving to Github
 was a step in the right direction, but it's not enough, and the people
 in charge don't seem to have a clue as to how to build a community.  How
 many new developers have joined the development of D/Phobos in the last
 year?


Probably more than in any other year, particularly if you factor in 
their respective productivity. We have a process in place for reviewing 
and voting standard library components, which has worked quite well. 
Community participation has increased by leaps and bounds. Only dmd has 
enjoyed 506 pull requests in less than 10 months. That's an average of 
1.7 per calendar day before counting Walter's own contributions. Phobos 
is trailing close with 323 pull requests in the same amount of time.

I'd be the first to admit that a lot more is needed and that the 
existing progress didn't happen because of some good leadership, but 
Walter and I are recognizing we need to increasingly take the role of 
organizers and we plan to make some significant moves soon.


 I bet very few.  They haven't even fixed the link to that old
 site, and it's been like that for far too long.


What link?


 Where is "D/Phobos Developer's Guide" page?


I hope we'll have that soon, among other articles and papers. I'm not 
even sure that particular one is among the most important documents to 
have. Good articles are very important for publicizing D and attracting 
new users, and we don't have yet a culture that nourishes publishing.


Andrei



 Nov 10 2011



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2011-11-11 05:56, Andrei Alexandrescu wrote:

 On 11/10/11 9:06 PM, Caligo wrote:

 Where is "D/Phobos Developer's Guide" page?


 I hope we'll have that soon, among other articles and papers. I'm not
 even sure that particular one is among the most important documents to
 have. Good articles are very important for publicizing D and attracting
 new users, and we don't have yet a culture that nourishes publishing.


 Andrei


I think it's important. As far as I know, there is nothing on the 
d-p-l.org site that says we have a process for reviewing and voting on 
modules for Phobos. That's just one example.

-- 
/Jacob Carlborg



 Nov 10 2011



prev sibling  parent reply SimonM <user example.net>  writes:


On 2011/11/11 06:56 AM, Andrei Alexandrescu wrote:

 On 11/10/11 9:06 PM, Caligo wrote:

 I bet very few. They haven't even fixed the link to that old
 site, and it's been like that for far too long.


 What link?


I think he's probably referring to http://www.digitalmars.com/d/2.0/ 
which should preferrably redirect to http://d-programming-language.org/.

I always need to keep a bookmark to the .org site, because if I just 
Google "D" I only get to the digitalmars site, and it doesn't provide 
any link to the .org site.



 Nov 11 2011



  parent reply Caligo <iteronvexor gmail.com>  writes:


On Fri, Nov 11, 2011 at 2:59 AM, SimonM <user example.net> wrote:


 On 2011/11/11 06:56 AM, Andrei Alexandrescu wrote:


 On 11/10/11 9:06 PM, Caligo wrote:


 I bet very few. They haven't even fixed the link to that old
 site, and it's been like that for far too long.


 What link?


 I think he's probably referring to
http://www.digitalmars.com/d/**2.0/<http://www.digitalmars.com/d/2.0/>which
should preferrably redirect to
 http://d-programming-language.**org/ <http://d-programming-language.org/>.

 I always need to keep a bookmark to the .org site, because if I just
 Google "D" I only get to the digitalmars site, and it doesn't provide any
 link to the .org site.


yes, that's what I mean. I don't even know why that old site still exists.
Walter said he would get it fixed:

http://www.digitalmars.com/d/archives/digitalmars/D/Why_I_m_hesitating_to_switch_to_D_139517.html#N139559



 Nov 11 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.856.1321003915.24802.digitalmars-d puremagic.com...

 On Fri, Nov 11, 2011 at 2:59 AM, SimonM <user example.net> wrote:


 On 2011/11/11 06:56 AM, Andrei Alexandrescu wrote:


 On 11/10/11 9:06 PM, Caligo wrote:


 I bet very few. They haven't even fixed the link to that old
 site, and it's been like that for far too long.


 What link?


 I think he's probably referring to 
 http://www.digitalmars.com/d/**2.0/<http://www.digitalmars.com/d/2.0/>which 
 should preferrably redirect to
 http://d-programming-language.**org/ 
 <http://d-programming-language.org/>.

 I always need to keep a bookmark to the .org site, because if I just
 Google "D" I only get to the digitalmars site, and it doesn't provide any
 link to the .org site.


 yes, that's what I mean. I don't even know why that old site still exists.
 Walter said he would get it fixed:

 http://www.digitalmars.com/d/archives/digitalmars/D/Why_I_m_hesitating_to_switch_to_D_139517.html#N139559


I think before that happens, d-p-l.org needs to have a link for the 
changelog. There may be other pages, too, that are still only accessible via 
digitalmars.com.



 Nov 11 2011



prev sibling  parent reply Russel Winder <russel russel.org.uk>  writes:


On Thu, 2011-11-10 at 21:06 -0600, Caligo wrote:
[...]

 That's like going back 20 years and telling Linus "without a properly
 financed and orchestrated marketing campaign to push Linux out there..." =


,

 you get my drift.


No I don't, but I think you are trivializing my point by trying to make
it appear spurious.

Linux only really became popular due to distributions such as Red Hat,
Debian, Slackware, etc.  Resources were pumped into them to make them
work.  Not direct financing and marketing but indirect financing and
marketing.  The Red Hat and Debian campaigns have clearly been
successful -- even though Linux has a trivial install base compared to
Windows on client machines, it dominates on server machines (and is the
only OS on my equipment of any sort).=20


 Money and marketing are important, specially when you are developing
 a proprietary system.  You can have a shit product, but with enough
 marketing you can make people believe it's not shit; Microsoft has done i=


t,

 same with Sun and Java.


I won't disagree with you on Microsoft.  Nor in it's latter days Sun's
business strategy. Java is a different matter.  It has problems, but it
has undoubtedly revolutionized software.  Java is a waning language just
now, though Java 8, if it comes soon and gets it right, could revitalize
it.  But Java per se is not real issue, it is the JVM that is a core
product of future software.  Groovy, Scala, JRuby, Jython, Clojure,
Fantom, Ceylon, Mirah, Kotlin,...  The JVM-sphere is a melting pot of
enthusiasm, gentle (but sometimes otherwise, sadly) competition, and a
huge and positive desire to succeed.  Backed up by a lot of direct and
indirect resourcing that allows things to happen without the stress of
relying only on volunteer labour.

Clearly there are static and dynamic languages here.  For the dynamic
languages the main thrust of marketing is the line "more expressive than
Java, interworks with Java and the libraries, gives you a runtime MOP".
For the static languages the general line is "less verbose than Java,
more expressive than Java, interworks with Java, can gradually replace
Java".

The core strategy has not been to argue for throwing Java out but much
more for keeping what there is but side-lining Java as a future
development language.

Turning to the Fortran, C, Go, C++, D end of things, all arguments are
"replace do not interwork".  Go is the classic example of this.  Trying
to use C written libraries from Go is painful, so there is a huge effort
to effectively replace all the C and C++ infrastructure code out there
with Go infrastructure.  With the direct and indirect resources from
Google and others this is happening, and at a phenomenal rate.

Although D can interwork with C and C++ written libraries, the
perception of those out there who are not directly part of the D
community, is the D is a language for revolutionary replacement of C++
rather than evolutionary replacement of C++, i.e. C++/D is an one or the
other choice.  No matter how wrong this might be, it is the perception,
and that is what matters.


 If D fails, it's not because of lack of money or marketing, but because o=


f

 lack of a healthy and growing community.  A healthy community is what all
 successful open source projects have in common.  Moving to Github was a
 step in the right direction, but it's not enough, and the people in charg=


e

 don't seem to have a clue as to how to build a community.  How many new
 developers have joined the development of D/Phobos in the last year?  I b=


et

 very few.  They haven't even fixed the link to that old site, and it's be=


en

 like that for far too long.


I say it is not that black and white.  A healthy, vibrant, expanding
community is a precursor to success.  Ruby saw this, Groovy saw this.
You also need a successful showcase (I refuse to use the term "killer
app" as that has all the wrong connotations).  Ruby had Rails, Groovy
had Grails.  The you need the non-volunteer resources to continue the
drive into the mainstream.  Ruby attracted the entrepreneurs, spawned
GitHub, Heroku, etc.  Groovy attracted SpringSource, BSkyB, and got
recognized as core enterprise toolkit.

Only when the resources got put into things did the phase change from
peripheral to core happen.  D is currently a potential waiting for a
resourcing.  It needs a showcase.


 Where is "D/Phobos Developer's Guide" page?


Perhaps more importantly, where is the material showing C and C++
programmers how they can start writing D in their current systems and
slowly move to D in an incremental way to great benefit in development
speed with no loss of performance?

Scala, Ceylon, Kotlin, etc. will succeed exactly because they offer
things not in Java and yet systems can be written in a mix of any and
all of the languages.

Groovy, JRuby, Jython, etc. are succeeding because they offer forms of
expression not available in static langauges and yet can interwork with
all the languages that sit on the JVM.

D has to do this with C and C++ so as to be able to be used in an
incremental and insurgent way.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Nov 11 2011



  parent  Paulo Pinto <pjmlp progtools.org>  writes:


Quite right.

On 11.11.2011 10:14, Russel Winder wrote:

 On Thu, 2011-11-10 at 21:06 -0600, Caligo wrote:
 [...]

 That's like going back 20 years and telling Linus "without a properly
 financed and orchestrated marketing campaign to push Linux out there..." ,
 you get my drift.


 No I don't, but I think you are trivializing my point by trying to make
 it appear spurious.

 Linux only really became popular due to distributions such as Red Hat,
 Debian, Slackware, etc.  Resources were pumped into them to make them
 work.  Not direct financing and marketing but indirect financing and
 marketing.  The Red Hat and Debian campaigns have clearly been
 successful -- even though Linux has a trivial install base compared to
 Windows on client machines, it dominates on server machines (and is the
 only OS on my equipment of any sort).


 Money and marketing are important, specially when you are developing
 a proprietary system.  You can have a shit product, but with enough
 marketing you can make people believe it's not shit; Microsoft has done it,
 same with Sun and Java.


 I won't disagree with you on Microsoft.  Nor in it's latter days Sun's
 business strategy. Java is a different matter.  It has problems, but it
 has undoubtedly revolutionized software.  Java is a waning language just
 now, though Java 8, if it comes soon and gets it right, could revitalize
 it.  But Java per se is not real issue, it is the JVM that is a core
 product of future software.  Groovy, Scala, JRuby, Jython, Clojure,
 Fantom, Ceylon, Mirah, Kotlin,...  The JVM-sphere is a melting pot of
 enthusiasm, gentle (but sometimes otherwise, sadly) competition, and a
 huge and positive desire to succeed.  Backed up by a lot of direct and
 indirect resourcing that allows things to happen without the stress of
 relying only on volunteer labour.

 Clearly there are static and dynamic languages here.  For the dynamic
 languages the main thrust of marketing is the line "more expressive than
 Java, interworks with Java and the libraries, gives you a runtime MOP".
 For the static languages the general line is "less verbose than Java,
 more expressive than Java, interworks with Java, can gradually replace
 Java".

 The core strategy has not been to argue for throwing Java out but much
 more for keeping what there is but side-lining Java as a future
 development language.

 Turning to the Fortran, C, Go, C++, D end of things, all arguments are
 "replace do not interwork".  Go is the classic example of this.  Trying
 to use C written libraries from Go is painful, so there is a huge effort
 to effectively replace all the C and C++ infrastructure code out there
 with Go infrastructure.  With the direct and indirect resources from
 Google and others this is happening, and at a phenomenal rate.

 Although D can interwork with C and C++ written libraries, the
 perception of those out there who are not directly part of the D
 community, is the D is a language for revolutionary replacement of C++
 rather than evolutionary replacement of C++, i.e. C++/D is an one or the
 other choice.  No matter how wrong this might be, it is the perception,
 and that is what matters.


 If D fails, it's not because of lack of money or marketing, but because of
 lack of a healthy and growing community.  A healthy community is what all
 successful open source projects have in common.  Moving to Github was a
 step in the right direction, but it's not enough, and the people in charge
 don't seem to have a clue as to how to build a community.  How many new
 developers have joined the development of D/Phobos in the last year?  I bet
 very few.  They haven't even fixed the link to that old site, and it's been
 like that for far too long.


 I say it is not that black and white.  A healthy, vibrant, expanding
 community is a precursor to success.  Ruby saw this, Groovy saw this.
 You also need a successful showcase (I refuse to use the term "killer
 app" as that has all the wrong connotations).  Ruby had Rails, Groovy
 had Grails.  The you need the non-volunteer resources to continue the
 drive into the mainstream.  Ruby attracted the entrepreneurs, spawned
 GitHub, Heroku, etc.  Groovy attracted SpringSource, BSkyB, and got
 recognized as core enterprise toolkit.

 Only when the resources got put into things did the phase change from
 peripheral to core happen.  D is currently a potential waiting for a
 resourcing.  It needs a showcase.


 Where is "D/Phobos Developer's Guide" page?


 Perhaps more importantly, where is the material showing C and C++
 programmers how they can start writing D in their current systems and
 slowly move to D in an incremental way to great benefit in development
 speed with no loss of performance?

 Scala, Ceylon, Kotlin, etc. will succeed exactly because they offer
 things not in Java and yet systems can be written in a mix of any and
 all of the languages.

 Groovy, JRuby, Jython, etc. are succeeding because they offer forms of
 expression not available in static langauges and yet can interwork with
 all the languages that sit on the JVM.

 D has to do this with C and C++ so as to be able to be used in an
 incremental and insurgent way.





 Nov 11 2011



prev sibling next sibling parent  Kagamin <spam here.lot>  writes:


Caligo Wrote:


 You're right, I did forget about the preprocessor.  Besides the usual
 things in the header files, I always try to avoid macros.
 
 There are about 20 directives, so that puts the keywords count for C++ to
 101.  It's still fewer than D.  Does that mean D is more complex than C++?
 
 Python with 33, I think most would agree that is has a very consice
 grammer.


If a language doesn't have `abstract`, `out` or `pure` it's fail rather than
win.



 Nov 09 2011



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.805.1320889624.24802.digitalmars-d puremagic.com...

 There are about 20 directives, so that puts the keywords count for C++ to
 101.  It's still fewer than D.  Does that mean D is more complex than C++?


Of course not. There's obviously a lot more to language complexity than 
number of keywords.



 Nov 10 2011



prev sibling  parent reply Somedude <lovelydear mailmetrash.com>  writes:


Le 10/11/2011 02:46, Caligo a écrit :

 On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>> wrote:

     On 11/9/2011 2:45 PM, Danni Coy wrote:

         how many keywords in D are needed because the preprocessor is
         built into the
         language itself?


     It's true, people forget about the preprocessor keywords when
     counting C++ keywords.



 You're right, I did forget about the preprocessor.  Besides the usual
 things in the header files, I always try to avoid macros.

 There are about 20 directives, so that puts the keywords count for C++
 to 101.  It's still fewer than D.  Does that mean D is more complex than
 C++?

 Python with 33, I think most would agree that is has a very consice
 grammer.


I tend to believe D is conceptually more complex than C++. Which means 
it allows for more expressivity. But it has far fewer warts and a 
simpler syntax.
I believe it takes as much time to learn D than to learn C++ (i.e at 
least 6 months), but you end up writing more secure and more powerful code.



 Nov 12 2011



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 11/12/2011 04:47 PM, Somedude wrote:

 Le 10/11/2011 02:46, Caligo a écrit :

 On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright
 <newshound2 digitalmars.com <mailto:newshound2 digitalmars.com>> wrote:

 On 11/9/2011 2:45 PM, Danni Coy wrote:

 how many keywords in D are needed because the preprocessor is
 built into the
 language itself?


 It's true, people forget about the preprocessor keywords when
 counting C++ keywords.



 You're right, I did forget about the preprocessor. Besides the usual
 things in the header files, I always try to avoid macros.

 There are about 20 directives, so that puts the keywords count for C++
 to 101. It's still fewer than D. Does that mean D is more complex than
 C++?

 Python with 33, I think most would agree that is has a very consice
 grammer.


 I tend to believe D is conceptually more complex than C++. Which means
 it allows for more expressivity.


What makes you think it is conceptually more complex? Most features that 
make D more expressive than C++ are conceptually very simple. And what 
is conceptually simple in D is usually also implemented in a simple way 
(as opposed to C++).



 But it has far fewer warts and a simpler syntax.
 I believe it takes as much time to learn D than to learn C++ (i.e at
 least 6 months), but you end up writing more secure and more powerful code.


I'd claim that nobody fully understands C++. On the other hand, one gets 
quite close to fully understanding D in a relatively short time span.



 Nov 12 2011



  parent reply Somedude <lovelydear mailmetrash.com>  writes:


Le 12/11/2011 17:27, Timon Gehr a écrit :

 I tend to believe D is conceptually more complex than C++. Which means
 it allows for more expressivity.


 What makes you think it is conceptually more complex? Most features that
 make D more expressive than C++ are conceptually very simple. And what
 is conceptually simple in D is usually also implemented in a simple way
 (as opposed to C++).


I think D's type system is more advanced and more detailed than C++ or 
as any C derived language. This takes a while to grok. Of course, I 
guess at the beginning one can program in D with only a subset of the 
language.


 But it has far fewer warts and a simpler syntax.
 I believe it takes as much time to learn D than to learn C++ (i.e at
 least 6 months), but you end up writing more secure and more powerful
 code.


 I'd claim that nobody fully understands C++. On the other hand, one gets
 quite close to fully understanding D in a relatively short time span.


I agree with your claim for C++. Still, D2 is a "big" language.



 Nov 12 2011



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 11/12/2011 09:05 PM, Somedude wrote:

 Le 12/11/2011 17:27, Timon Gehr a écrit :

 I tend to believe D is conceptually more complex than C++. Which means
 it allows for more expressivity.


 What makes you think it is conceptually more complex? Most features that
 make D more expressive than C++ are conceptually very simple. And what
 is conceptually simple in D is usually also implemented in a simple way
 (as opposed to C++).


 I think D's type system is more advanced and more detailed than C++ or
 as any C derived language. This takes a while to grok. Of course, I
 guess at the beginning one can program in D with only a subset of the
 language.


Ok, I see. Probably we are missing a nice tutorial about the type 
qualifiers (const/immutable/shared/inout) ?

Or is there another type system feature that takes a while to grok?


 But it has far fewer warts and a simpler syntax.
 I believe it takes as much time to learn D than to learn C++ (i.e at
 least 6 months), but you end up writing more secure and more powerful
 code.


 I'd claim that nobody fully understands C++. On the other hand, one gets
 quite close to fully understanding D in a relatively short time span.


 I agree with your claim for C++. Still, D2 is a "big" language.


Oh, yes it is quite big. But I don't think it is very complex.



 Nov 12 2011



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:j9mtth$d26$1 digitalmars.com...

 On 11/12/2011 09:05 PM, Somedude wrote:

 Le 12/11/2011 17:27, Timon Gehr a écrit :

 I tend to believe D is conceptually more complex than C++. Which means
 it allows for more expressivity.


 What makes you think it is conceptually more complex? Most features that
 make D more expressive than C++ are conceptually very simple. And what
 is conceptually simple in D is usually also implemented in a simple way
 (as opposed to C++).


 I think D's type system is more advanced and more detailed than C++ or
 as any C derived language. This takes a while to grok. Of course, I
 guess at the beginning one can program in D with only a subset of the
 language.


 Ok, I see. Probably we are missing a nice tutorial about the type 
 qualifiers (const/immutable/shared/inout) ?

 Or is there another type system feature that takes a while to grok?


I'd imagine D's type system might sometimes seem more complex than it is 
simply because highly complex types involving fancy templates are used so 
much more. And, of course, they're used more because D makes it so much 
easier to use them.

And then, there's also complexities that are for the better. For example, 
C++ AFAIK doesn't have IFTI. IFTI *is* an additional set of 
rules/complexities *in the language*, but they're complexities that make the 
language easier to use. SImilar thing with the implicit conversion rules for 
primitive types: The rules for that are somewhat complicated, but they 
usually make using the language easier and safer.



 Nov 13 2011



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 11/13/2011 03:13 PM, Nick Sabalausky wrote:

 "Timon Gehr"<timon.gehr gmx.ch>  wrote in message
 news:j9mtth$d26$1 digitalmars.com...

 On 11/12/2011 09:05 PM, Somedude wrote:

 Le 12/11/2011 17:27, Timon Gehr a écrit :

 I tend to believe D is conceptually more complex than C++. Which means
 it allows for more expressivity.


 What makes you think it is conceptually more complex? Most features that
 make D more expressive than C++ are conceptually very simple. And what
 is conceptually simple in D is usually also implemented in a simple way
 (as opposed to C++).


 I think D's type system is more advanced and more detailed than C++ or
 as any C derived language. This takes a while to grok. Of course, I
 guess at the beginning one can program in D with only a subset of the
 language.


 Ok, I see. Probably we are missing a nice tutorial about the type
 qualifiers (const/immutable/shared/inout) ?

 Or is there another type system feature that takes a while to grok?


 I'd imagine D's type system might sometimes seem more complex than it is
 simply because highly complex types involving fancy templates are used so
 much more. And, of course, they're used more because D makes it so much
 easier to use them.


Maybe, I don't know.


 And then, there's also complexities that are for the better. For example,
 C++ AFAIK doesn't have IFTI. IFTI *is* an additional set of
 rules/complexities *in the language*, but they're complexities that make the
 language easier to use. SImilar thing with the implicit conversion rules for
 primitive types: The rules for that are somewhat complicated, but they
 usually make using the language easier and safer.


C++ allows instantiating function templates without explicitly giving 
the type parameters. Or what exactly do you think C++ does not have?



 Nov 13 2011



  parent  "Nick Sabalausky" <a a.a>  writes:


"Timon Gehr" <timon.gehr gmx.ch> wrote in message 
news:j9oorj$obn$1 digitalmars.com...

 On 11/13/2011 03:13 PM, Nick Sabalausky wrote:

 And then, there's also complexities that are for the better. For example,
 C++ AFAIK doesn't have IFTI. IFTI *is* an additional set of
 rules/complexities *in the language*, but they're complexities that make 
 the
 language easier to use. SImilar thing with the implicit conversion rules 
 for
 primitive types: The rules for that are somewhat complicated, but they
 usually make using the language easier and safer.


 C++ allows instantiating function templates without explicitly giving the 
 type parameters. Or what exactly do you think C++ does not have?


Hmm, I guess my C++ is just really rusty.



 Nov 13 2011



prev sibling  parent  Danni Coy <danni.coy gmail.com>  writes:


On Thu, Nov 10, 2011 at 11:46 AM, Caligo <iteronvexor gmail.com> wrote:


 On Wed, Nov 9, 2011 at 5:20 PM, Walter Bright
<newshound2 digitalmars.com>wrote:


 On 11/9/2011 2:45 PM, Danni Coy wrote:


 how many keywords in D are needed because the preprocessor is built into
 the
 language itself?


 It's true, people forget about the preprocessor keywords when counting
 C++ keywords.


 You're right, I did forget about the preprocessor.  Besides the usual
 things in the header files, I always try to avoid macros.

 There are about 20 directives, so that puts the keywords count for C++ to
 101.  It's still fewer than D.  Does that mean D is more complex than C++?


Do keywords like unittest make the language more or less complex? (to use
one that isn't in C++).



Python with 33, I think most would agree that is has a very consice

 grammer.

 Being a dynamic language python would not have keywords for data types


right?
That has to be a large part of the difference. That said I do have to say
that Python does feel very concise.



 Nov 09 2011



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2011-11-09 23:45, Danni Coy wrote:

 On Wed, Nov 9, 2011 at 10:31 AM, Simen Kjærås <simen.kjaras gmail.com
 <mailto:simen.kjaras gmail.com>> wrote:

     On Tue, 08 Nov 2011 05:39:07 +0100, Caligo <iteronvexor gmail.com
     <mailto:iteronvexor gmail.com>> wrote:

         On Mon, Nov 7, 2011 at 7:51 PM, bearophile
         <bearophileHUGS lycos.com <mailto:bearophileHUGS lycos.com>> wrote:

             Bartosz talks a bit about the very nicely designed Chapel
             language:

             http://bartoszmilewski.__wordpress.com/2011/11/07/__supercomputing-in-seattle/
             <http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/>

             (But my appreciation for Chapel design is on other things).

             Bye,
             bearophile


         Interesting (maybe useless) facts: Chapel has 59 keywords.  D
         has, I think,
         107 keywords.  C++11, I think, 81.  Python has 33.


     Interesting, questionably. Useless, indeed.


 how many keywords in D are needed because the preprocessor is built into
 the language itself?


A couple of extra, but we also reuse some existing once, i.e. "static if".

-- 
/Jacob Carlborg



 Nov 09 2011



prev sibling next sibling parent  foobar <foo bar.com>  writes:


Caligo Wrote:


 On Mon, Nov 7, 2011 at 7:51 PM, bearophile <bearophileHUGS lycos.com> wrote:
 

 Bartosz talks a bit about the very nicely designed Chapel language:

 http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/

 (But my appreciation for Chapel design is on other things).

 Bye,
 bearophile


 
 Interesting (maybe useless) facts: Chapel has 59 keywords.  D has, I think,
 107 keywords.  C++11, I think, 81.  Python has 33.
 
 <br><br><div class="gmail_quote">On Mon, Nov 7, 2011 at 7:51 PM, bearophile
<span dir="ltr">&lt;<a
href="mailto:bearophileHUGS lycos.com">bearophileHUGS lycos.com</a>&gt;</span>
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
 Bartosz talks a bit about the very nicely designed Chapel language:<br>
 <br>
 <a href="http://bartoszmilewski.wordpress.com/2011/11/07/superco
puting-in-seattle/" target="_blank">http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/</a><br>
 <br>
 (But my appreciation for Chapel design is on other things).<br>
 <br>
 Bye,<br>

 </font></blockquote></div><br><div>Interesting (maybe useless) facts: Chapel
has 59 keywords.  D has, I think, 107 keywords.  C++11, I think, 81.  Python
has 33.</div>
 


Smalltalk has 5. How many does lisp have? brainfuck? whiltespace? 

Many people (me included) consider smalltalk to be one of the friendliest
languages to use. It really is like talking with the computer. 
Measuring keyword count is wrong. what should be measured is *what* keywords
are used and ease of expressiveness the language provides. 
On such a scale, Small talk would be best and APL would probably be worst with
C+ a tight competition for 2nd worst. 

Regarding D, it's far better than c++ but still much further from smalltalk,
python, and other very readable languages.
Last comment, to all those who keep character/word counts and try to shorten
words - code is read 1000 as much as written so readability is many orders of
magnitude more important  than conciseness. Best example is c+= "=0" for
abstract/pure virtual. 



 Nov 09 2011



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 11/7/2011 8:39 PM, Caligo wrote:

 Interesting (maybe useless) facts: Chapel has 59 keywords.  D has, I think, 107
 keywords.  C++11, I think, 81.  Python has 33.


We all know the joke that C uses 'static' for everything in order to conserve 
keyword use. (D, ahem, does that a bit, too.)



 Nov 10 2011



prev sibling next sibling parent reply Caligo <iteronvexor gmail.com>  writes:


On Mon, Nov 7, 2011 at 7:51 PM, bearophile <bearophileHUGS lycos.com> wrote:


 Bartosz talks a bit about the very nicely designed Chapel language:

 http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/

 (But my appreciation for Chapel design is on other things).

 Bye,
 bearophile


I haven't looked at Chapel in depth, but I would like to see sample code
where it shows its generics is better than D's.



 Nov 07 2011



  parent  Norbert Nemec <Norbert Nemec-online.de>  writes:


On 08.11.2011 05:40, Caligo wrote:

 On Mon, Nov 7, 2011 at 7:51 PM, bearophile<bearophileHUGS lycos.com>  wrote:


 Bartosz talks a bit about the very nicely designed Chapel language:

 http://bartoszmilewski.wordpress.com/2011/11/07/supercomputing-in-seattle/

 (But my appreciation for Chapel design is on other things).

 Bye,
 bearophile


 I haven't looked at Chapel in depth, but I would like to see sample code
 where it shows its generics is better than D's.


I am not quite sure, but I think this is the issue of "concept" (that 
were discussed for and then dropped from C++11).

As I understand it, D does indeed offer the same functionality in the 
form of template parameter constraints. Still, the formalism of template 
constraints offers so much flexibility that it is difficult to ensure 
clear error messages for the user while keeping the code clear and 
simple as well.



 Nov 13 2011



prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Friday, November 11, 2011 09:34:07 Russel Winder wrote:

 On Thu, 2011-11-10 at 19:24 -0800, Jonathan M Davis wrote:
 [...]
 

 Bearophile has some good ideas, but he has too many of them for us to
 ever deal with them all even if they were all really good, and many of
 them are incredibly trivial. Obviously, he can suggest as many ideas as
 he likes, but I think that he'd stand a better chance of getting his
 ideas implemented if he presented far fewer of them. It would also take
 up less of everyone else's time. He's a valuable member of the
 community, but it would be better for everyone (him included) if his
 signal to noise ratio were much higher.


 Why don't they get turned into tickets such that work can be scheduled?


He creates tons of them (both bug reports and enhancement requests). Probably 
a third of the reports in bugzilla come from him (maybe more; someone tallied 
it a few months back, but I don't remember the exact percentage). They can't 
possibly all be addressed. And many of his requests involve major changes that 
have no chance of happening. He'd stand a much better chance of getting some 
of his ideas implemented if he just focused on a few of them, but the sheer 
number of them means that there's no way that very many of them are going to 
be implemented, regardless of their merit.

- Jonathan M Davis



 Nov 11 2011



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/11/11 3:39 AM, Jonathan M Davis wrote:

 On Friday, November 11, 2011 09:34:07 Russel Winder wrote:

 On Thu, 2011-11-10 at 19:24 -0800, Jonathan M Davis wrote:
 [...]


 Bearophile has some good ideas, but he has too many of them for us to
 ever deal with them all even if they were all really good, and many of
 them are incredibly trivial. Obviously, he can suggest as many ideas as
 he likes, but I think that he'd stand a better chance of getting his
 ideas implemented if he presented far fewer of them. It would also take
 up less of everyone else's time. He's a valuable member of the
 community, but it would be better for everyone (him included) if his
 signal to noise ratio were much higher.


 Why don't they get turned into tickets such that work can be scheduled?


 He creates tons of them (both bug reports and enhancement requests). Probably
 a third of the reports in bugzilla come from him (maybe more; someone tallied
 it a few months back, but I don't remember the exact percentage). They can't
 possibly all be addressed. And many of his requests involve major changes that
 have no chance of happening. He'd stand a much better chance of getting some
 of his ideas implemented if he just focused on a few of them, but the sheer
 number of them means that there's no way that very many of them are going to
 be implemented, regardless of their merit.

 - Jonathan M Davis


If there were many meritory ideas, we'd have a completely different 
issue on our hands. The problem here is just signal to noise ratio.

Andrei



 Nov 11 2011



prev sibling  parent reply Russel Winder <russel russel.org.uk>  writes:


On Fri, 2011-11-11 at 01:39 -0800, Jonathan M Davis wrote:

 On Friday, November 11, 2011 09:34:07 Russel Winder wrote:


[...]

 Why don't they get turned into tickets such that work can be scheduled?


=20
 He creates tons of them (both bug reports and enhancement requests). Prob=


ably=20

 a third of the reports in bugzilla come from him (maybe more; someone tal=


lied=20

 it a few months back, but I don't remember the exact percentage). They ca=


n't=20

 possibly all be addressed. And many of his requests involve major changes=


 that=20

 have no chance of happening. He'd stand a much better chance of getting s=


ome=20

 of his ideas implemented if he just focused on a few of them, but the she=


er=20

 number of them means that there's no way that very many of them are going=


 to=20

 be implemented, regardless of their merit.


Ah, OK.  So exactly the opposite of my original surmise.  Sadly a
surfeit of effectively useless reports is worse that too few.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Nov 11 2011



  parent reply Tobias Pankrath <tobias pankrath.net>  writes:


Russel Winder wrote:


 On Fri, 2011-11-11 at 01:39 -0800, Jonathan M Davis wrote:

 On Friday, November 11, 2011 09:34:07 Russel Winder wrote:


 [...]

 Why don't they get turned into tickets such that work can be scheduled?


 
 He creates tons of them (both bug reports and enhancement requests).
 Probably a third of the reports in bugzilla come from him (maybe more;
 someone tallied it a few months back, but I don't remember the exact
 percentage). They can't possibly all be addressed. And many of his
 requests involve major changes that have no chance of happening. He'd
 stand a much better chance of getting some of his ideas implemented if he
 just focused on a few of them, but the sheer number of them means that
 there's no way that very many of them are going to be implemented,
 regardless of their merit.


 
 Ah, OK.  So exactly the opposite of my original surmise.  Sadly a
 surfeit of effectively useless reports is worse that too few.
 


But how is bearophile going to know, which of his ideas are good and bad, 
if he doesn't share them?

I'd say, the core dmd devs (or bearophile himself) should rank the reports 
or mark them "won't fix" after discussion. 

After all an issue tracker is for keeping track of issues, that are not to 
be solved right now. It's like saying "you shouldn't report all this bugs,
because we don't have enough developer to fix them.".



 Nov 11 2011



  parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Friday, November 11, 2011 10:51:31 Tobias Pankrath wrote:

 Russel Winder wrote:

 On Fri, 2011-11-11 at 01:39 -0800, Jonathan M Davis wrote:

 On Friday, November 11, 2011 09:34:07 Russel Winder wrote:


 [...]
 

 Why don't they get turned into tickets such that work can be
 scheduled?>> 


 He creates tons of them (both bug reports and enhancement requests).
 Probably a third of the reports in bugzilla come from him (maybe more;
 someone tallied it a few months back, but I don't remember the exact
 percentage). They can't possibly all be addressed. And many of his
 requests involve major changes that have no chance of happening. He'd
 stand a much better chance of getting some of his ideas implemented if
 he just focused on a few of them, but the sheer number of them means
 that there's no way that very many of them are going to be
 implemented, regardless of their merit.


 
 Ah, OK.  So exactly the opposite of my original surmise.  Sadly a
 surfeit of effectively useless reports is worse that too few.


 
 But how is bearophile going to know, which of his ideas are good and bad,
 if he doesn't share them?
 
 I'd say, the core dmd devs (or bearophile himself) should rank the reports
 or mark them "won't fix" after discussion.
 
 After all an issue tracker is for keeping track of issues, that are not to
 be solved right now. It's like saying "you shouldn't report all this bugs,
 because we don't have enough developer to fix them.".


Bugs are one thing. Enhancement requests are another thing entirely. He seems 
to post an enhancement request for everything that passes his fancy even 
briefly. If he thought them through more, then there would likely be fewer. It 
would also help if you didn't keep making suggestions that involve major 
breaking changes unless he had a _really_ solid argument for why we need them 
(e.g. changing byte to sbyte). If he has some solid ideas to share, then 
that's great, but the sheer number of ideas (be they good or bad) that he has 
makes it so that each of them has a high chance of being ignored.

- Jonathan M Davis



 Nov 11 2011