www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A summary of D's design principles

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
A coworker asked me where he could find a brief document of D's design 
principles. This was after I'd mentioned the "no function hijacking" stance.

I think it would be a great idea if the up-and-coming 
www.d-programming-language.org contained such a document.

Ideas for what it could contain? I know we discussed this once in the 
past, but couldn't find the discussion.


Andrei
Sep 15 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 A coworker asked me where he could find a brief document of D's design  
 principles. This was after I'd mentioned the "no function hijacking"  
 stance.

 I think it would be a great idea if the up-and-coming  
 www.d-programming-language.org contained such a document.

 Ideas for what it could contain? I know we discussed this once in the  
 past, but couldn't find the discussion.


I'm sure there are parts of it scattered all over digitalmars.com/d/,
and certainly in the newsgroup.
Off the top of my head:

Easy things easy, difficult things possible.

Safe before fast, but fast too.

If it works in C, it works the same or not at all in D.

Sugar is good for you, as is salt. In moderation.

Too much power is not enough. (Where are my macros?!)

Programmers are lazy, so give them what they should use in the
language. (unit testing, ddoc, contracts, versioning, etc...)

-- 
Simen
Sep 15 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Simen kjaeraas:

 Easy things easy, difficult things possible.
 
 Safe before fast, but fast too.
 
 If it works in C, it works the same or not at all in D.
 
 Sugar is good for you, as is salt. In moderation.
 
 Too much power is not enough. (Where are my macros?!)
 
 Programmers are lazy, so give them what they should use in the
 language. (unit testing, ddoc, contracts, versioning, etc...)


This reminds me a lot the Python Zen :-)
Seven possible more:
- It's almost good.
- Practical compilers matter.
- Good syntax mattes.
- Memory layouts matter.
- Compilation speed and reliability count.
- A GC is good for you, except when you need something else.
- High level when possible, low level if necessary.

One of yours fixed:
- If it works in C, it works (almost) the same or not at all in D.

Bye,
bearophile
Sep 15 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:


 One of yours fixed:
 - If it works in C, it works (almost) the same or not at all in D.


Mind giving examples to this one? I thought this was a big no-no.

-- 
Simen
Sep 15 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Simen kjaeraas:


 Mind giving examples to this one? I thought this was a big no-no.


There are few silent differences, among them there are:
- usage of global floating point variables/arrays that in some C programs are
used without initialization, assuming they are set to zero.
- fixed-sized arrays passed around by reference in C and by value in D2.

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=4580

Bye,
bearophile
Sep 15 2010
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:


 Simen kjaeraas:


 Mind giving examples to this one? I thought this was a big no-no.


 There are few silent differences, among them there are:
 - usage of global floating point variables/arrays that in some C  =



 programs are used without initialization, assuming they are set to zer=


o.

 - fixed-sized arrays passed around by reference in C and by value in D=


2.

By Golly=C2=B9, you're right!

Those certainly are worth mentioning, at least the latter. The former
could be seen as bad style, but certainly something someone would do.


=C2=B9) I mostly just wanted an excuse to say 'By Golly')
-- =

Simen
Sep 15 2010
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Wed, 15 Sep 2010 22:19:26 +0200, Simen kjaeraas wrote:


 bearophile <bearophileHUGS lycos.com> wrote:
 

 Simen kjaeraas:


 Mind giving examples to this one? I thought this was a big no-no.


 There are few silent differences, among them there are: - usage of
 global floating point variables/arrays that in some C programs are used
 without initialization, assuming they are set to zero.

 - fixed-sized arrays passed around by reference in C and by value in
 D2.


 
 By Golly¹, you're right!
 
 Those certainly are worth mentioning, at least the latter. The former
 could be seen as bad style, but certainly something someone would do.
 
 
 ¹) I mostly just wanted an excuse to say 'By Golly')



This can be amended by requiring that fixed-size array parameters to 
extern(C) functions be marked as 'ref'.

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=3604

-Lars
Sep 15 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:

 This can be amended by requiring that fixed-size array parameters to 
 extern(C) functions be marked as 'ref'.
 
 See also:
 http://d.puremagic.com/issues/show_bug.cgi?id=3604


Sometimes I translate some C code to D, in this case I have to watch for all
the arrays, and use the ref. To solve this porting problem (and other problems)
I have suggested a -cstyle:
http://d.puremagic.com/issues/show_bug.cgi?id=4580

Bye,
bearophile
Sep 15 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Simen kjaeraas:


 The former could be seen as bad style,


I think this is the relevant passage from the C Standard:

    Objects with static storage duration (3.7.1) shall be zero-initialized
(8.5) before any other initialization takes place. Zero-initialization and
initialization with a constant expression are collectively called static
initialization; all other initialization is dynamic initialization. Objects of
POD [plain old data] types (3.9) with static storage duration initialized with
constant expressions (5.19) shall be initialized before any dynamic
initialization takes place. Objects with static storage duration defined in
namespace scope in the same translation unit and dynamically initialized shall
be initialized in the order in which their definition appears in the
translation unit. [Note:8.5.1 describes the order in which aggregate members
are initialized. The initial- ization of local static objects is described in
6.7.]

So I think a C program that relies on having global floating point
variables/arrays initialized to zero is formally correct.



 but certainly something someone would do.


In one of my D programs translated from C I have had to track down a not easy
to find D1 bug (see enhancement request 4580) caused by the C code assuming
global floating point values set to zero (in D2 signalling NaN may help track
down such bugs).

Bye,
bearophile
Sep 15 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Simen kjaeraas wrote:

 bearophile <bearophileHUGS lycos.com> wrote:
 

 One of yours fixed:
 - If it works in C, it works (almost) the same or not at all in D.


 
 Mind giving examples to this one? I thought this was a big no-no.


I'm curious what bearophile is referring to, too. We've worked hard to ensure 
that C code either produces the same result (as defined behavior in C would) or 
fails to compile.

And I'd add to that that the performance of C code written in D should match or 
exceed performance of the same code compiled with a C compiler.

I'd put this under the heading of "D As A Better C".
Sep 15 2010
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 15 Sep 2010 23:36:48 +0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 Simen kjaeraas wrote:

 bearophile <bearophileHUGS lycos.com> wrote:


 One of yours fixed:
 - If it works in C, it works (almost) the same or not at all in D.


  Mind giving examples to this one? I thought this was a big no-no.


 I'm curious what bearophile is referring to, too. We've worked hard to  
 ensure that C code either produces the same result (as defined behavior  
 in C would) or fails to compile.

 And I'd add to that that the performance of C code written in D should  
 match or exceed performance of the same code compiled with a C compiler.

 I'd put this under the heading of "D As A Better C".


Here is one of the examples (valid C/C++ and D program):

void modify(int foo[4])
{
	foo[0] = 42;
}

int main()
{
	int foo[4];
	modify(foo);
	
	return foo[0]; // returns 0 in D, 42 in C/C++
}
Sep 15 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Denis Koroskin wrote:

 On Wed, 15 Sep 2010 23:36:48 +0400, Walter Bright 
 <newshound2 digitalmars.com> wrote:
 

 Simen kjaeraas wrote:

 bearophile <bearophileHUGS lycos.com> wrote:


 One of yours fixed:
 - If it works in C, it works (almost) the same or not at all in D.


  Mind giving examples to this one? I thought this was a big no-no.


 I'm curious what bearophile is referring to, too. We've worked hard to 
 ensure that C code either produces the same result (as defined 
 behavior in C would) or fails to compile.

 And I'd add to that that the performance of C code written in D should 
 match or exceed performance of the same code compiled with a C compiler.

 I'd put this under the heading of "D As A Better C".


 
 Here is one of the examples (valid C/C++ and D program):
 
 void modify(int foo[4])
 {
     foo[0] = 42;
 }
 
 int main()
 {
     int foo[4];
     modify(foo);
     
     return foo[0]; // returns 0 in D, 42 in C/C++
 }


Yes, you're right. Just disallowing the C declaration syntax in parameters
isn't 
good enough, because the type may be specified by a typedef/alias.
Sep 15 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
One more:

If it runs, it may probably run at compile-time too.

Bye,
bearophile
Sep 15 2010
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking" stance.
 I think it would be a great idea if the up-and-coming
 www.d-programming-language.org contained such a document.
 Ideas for what it could contain? I know we discussed this once in the
 past, but couldn't find the discussion.
 Andrei


1.  Thou shalt not write boilerplate code.  If thou must write boilerplate code,
thy language doth not provide sufficient abstraction capabilities.

2.  We're consenting adults, but we're not suicidal maniacs.  Safety matters,
but
in the end the programmer knows best.

3.  Generic solutions must be as fast as equivalent hand-coded solutions.

4.  If the compiler knows it, there should be an easy way for the programmer to
introspect it.

5.  User defined types must have access to all features of builtin types.

6.  Costly abstractions are a dime a dozen.  Abstractions that can be used in
performance-critical code are a real achievement.

7.  Practicality beats purity.  (Shamelessly stolen from Python, but perhaps
even
more applicable to D.)
Sep 15 2010
prev sibling next sibling parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design 
 principles. This was after I'd mentioned the "no function hijacking" 
 stance.
 
 I think it would be a great idea if the up-and-coming 
 www.d-programming-language.org contained such a document.
 
 Ideas for what it could contain? I know we discussed this once in the 
 past, but couldn't find the discussion.
 
 
 Andrei
 


Here's one:

The machine model should map directly to the hardware of modern
machines. The machine model is inherited from C, but extended with
language support for hardware advances such as SIMD capabilities (in
the form of array operations), precise floating point semantics, and
explicitly shared memory.
Sep 15 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i6r1hn$2uu1$1 digitalmars.com...

A coworker asked me where he could find a brief document of D's design 
principles. This was after I'd mentioned the "no function hijacking" 
stance.

 I think it would be a great idea if the up-and-coming 
 www.d-programming-language.org contained such a document.

 Ideas for what it could contain? I know we discussed this once in the 
 past, but couldn't find the discussion.


- Pragmatism
- Make the "right" thing easy and the "wrong" thing hard.
- Toolbox, not "One best tool" (In D-style, you pick the tool. In non-D 
style, the tool picks YOU!)
Sep 15 2010
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Nick Sabalausky Wrote:


 - Make the "right" thing easy and the "wrong" thing hard.


I believe that is "The easy way is the safe and correct way."
Sep 15 2010
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 09/15/2010 01:58 PM, Andrei Alexandrescu wrote:

 I know we discussed this once in the past, but couldn't find the
 discussion.


Yeah, like 3 months ago:

http://www.digitalmars.com/d/archives/digitalmars/D/The_design_principles_of_D_aka_The_D_Manifesto_111570.html
Sep 15 2010
parent Justin Johansson <no spam.com> writes:
On 16/09/2010 7:17 AM, Jeff Nowakowski wrote:

 On 09/15/2010 01:58 PM, Andrei Alexandrescu wrote:

 I know we discussed this once in the past, but couldn't find the
 discussion.


 Yeah, like 3 months ago:

 http://www.digitalmars.com/d/archives/digitalmars/D/The_design_principles_of_D_aka_The_D_Manifesto_111570.html


It's a honor to be cited.
IIRC that discussion didn't go very deep at that time
apart from the few expected responses.

Cheers
Justin Johansson
Sep 16 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, September 15, 2010 10:58:49 Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.
 
 I think it would be a great idea if the up-and-coming
 www.d-programming-language.org contained such a document.
 
 Ideas for what it could contain? I know we discussed this once in the
 past, but couldn't find the discussion.
 
 
 Andrei


One of the big ones would be that the safe way is the default but that the 
unsafe way is still possible if you need it (a prime example being default 
initialization vs initializing with void).

- Jonathan M Davis
Sep 15 2010
prev sibling next sibling parent reply Simen Kjaeraas <simen.kjaras gmail.com> writes:
Here's a draft of something I'd like to see. I like having the ten


                          == The D Manifesto ==

0. Pragmatism is king.

1. Safe before all, fast before the rest.

2. High level where possible, low level where necessary.

3. If it looks like C, it works like C or never compiles.

4. Easy things easy, difficult things possible.

5. Thou shalt not need to write boilerplate code.

6. Sugar is good for you, as is salt. In moderation.

7. Too much power is almost enough.

8. User-defined types should not be treated differently.

9. What the compiler knows, the programmer can query.

10. What works at run-time, should work at compile-time.




These are runner-ups that I like, but don't feel are as important as
those above, says things that are already said, or just don't 'feel'
right.

11. Avoid magic.

12. The tool does not pick you - you pick the tool.

13. The straight path is safe and correct.

14. The crooked path is passable.

15. We're consenting adults, not suicidal maniacs.

--
Simen
Sep 16 2010
next sibling parent reply Justin Johansson <no spam.com> writes:
On 16/09/2010 8:34 PM, Simen Kjaeraas wrote:

 Here's a draft of something I'd like to see. I like having the ten


                            == The D Manifesto ==


I'm really pleased that the word "Manifesto" is gradually making
its way into this ng.  Let's make this a work in progress, but not
too long or open-ended.  Customers (i.e. potential D users) will
not wait forever.

Cheers
Justin Johansson
Sep 16 2010
parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 09/16/2010 09:51 AM, Justin Johansson wrote:

 I'm really pleased that the word "Manifesto" is gradually making
 its way into this ng.


Not to be confused with The Third Manifesto, which describes the D 
database language.

http://en.wikipedia.org/wiki/The_Third_Manifesto
http://en.wikipedia.org/wiki/D_%28data_language_specification%29
Sep 16 2010
next sibling parent Justin Johansson <no spam.com> writes:
On 16/09/2010 11:24 PM, Jeff Nowakowski wrote:

 On 09/16/2010 09:51 AM, Justin Johansson wrote:

 I'm really pleased that the word "Manifesto" is gradually making
 its way into this ng.


 Not to be confused with The Third Manifesto, which describes the D
 database language.

 http://en.wikipedia.org/wiki/The_Third_Manifesto
 http://en.wikipedia.org/wiki/D_%28data_language_specification%29


Not at all; just an overloading of the letter D and nothing else.

"Manifesto" relates to the public declaration of principals
and intentions according to links found from below.  Pretty
much on topic and I suggest a want for a more formal creed of
the D PL.

http://www.google.com/search?q=define%3Amanifesto
Sep 16 2010
prev sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 16 Sep 2010 15:54:26 +0200, Jeff Nowakowski <jeff dilacero.org>  
wrote:


 On 09/16/2010 09:51 AM, Justin Johansson wrote:

 I'm really pleased that the word "Manifesto" is gradually making
 its way into this ng.


 Not to be confused with The Third Manifesto, which describes the D  
 database language.

 http://en.wikipedia.org/wiki/The_Third_Manifesto
 http://en.wikipedia.org/wiki/D_%28data_language_specification%29


So ours should be The Fourth Manifesto, then?

-- 
Simen
Sep 16 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Simen kjaeraas:

 So ours should be The Fourth Manifesto, then?


Mars Zen :-)

Bye,
bearophile
Sep 16 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Simen Kjaeraas" <simen.kjaras gmail.com> wrote in message 
news:i6stke$o0v$1 digitalmars.com...

 15. We're consenting adults, not suicidal maniacs.


Heh, I love this one :)
Sep 16 2010
parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Thu, Sep 16, 2010 at 21:17, Nick Sabalausky <a a.a> wrote:


 "Simen Kjaeraas" <simen.kjaras gmail.com> wrote in message
 news:i6stke$o0v$1 digitalmars.com...

 15. We're consenting adults, not suicidal maniacs.


 Heh, I love this one :)


That's the 10 commandments in hexadecimal, from 0 to F :-)
That could be fun to number them as we might do it in a D program :-).
Sep 16 2010
prev sibling next sibling parent reply sybrandy <sybrandy gmail.com> writes:
On 09/16/2010 07:04 AM, Simen Kjaeraas wrote:

 Here's a draft of something I'd like to see. I like having the ten


                            == The D Manifesto ==

 0. Pragmatism is king.

 1. Safe before all, fast before the rest.

 2. High level where possible, low level where necessary.

 3. If it looks like C, it works like C or never compiles.

 4. Easy things easy, difficult things possible.

 5. Thou shalt not need to write boilerplate code.

 6. Sugar is good for you, as is salt. In moderation.

 7. Too much power is almost enough.

 8. User-defined types should not be treated differently.

 9. What the compiler knows, the programmer can query.

 10. What works at run-time, should work at compile-time.




 These are runner-ups that I like, but don't feel are as important as
 those above, says things that are already said, or just don't 'feel'
 right.

 11. Avoid magic.

 12. The tool does not pick you - you pick the tool.

 13. The straight path is safe and correct.

 14. The crooked path is passable.

 15. We're consenting adults, not suicidal maniacs.

 --
 Simen


To go along with this, perhaps "Concurrency should be easy and safe"?

Casey
Sep 16 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Thu, 16 Sep 2010 21:38:24 -0400, sybrandy wrote:


 On 09/16/2010 07:04 AM, Simen Kjaeraas wrote:

 Here's a draft of something I'd like to see. I like having the ten





FWIW, if you're picking up one of the most used languages out there, 
their list won't differ that much:


                            == The D Manifesto ==

 0. Pragmatism is king.
 13. The straight path is safe and correct.
 14. The crooked path is passable.




Who wants to write impractical code outside the academia?! The concepts 
are way too abstract. Every member of the community has a different idea 
about this.

Every developer should realize that some languages are toys (build by 
novices), some are proof-of-concept languages for research purposes, some 
are production ready languages for scientific (programming language) 
research. You're just blatantly retarded idiot if you're using these 
unsuitable languages for commercial work. It's not like people such as 
Simon Peyton Jones are complete morons -- their languages have a 
completely different problem domain. What I typically see here is "unlike 
dontlikestupid haskell, d is gooooood. haskell hate hate hate. ivory 
tower hate hate. aarrrgh. hate"


 1. Safe before all, fast before the rest.
 6. Sugar is good for you, as is salt. In moderation.
 7. Too much power is almost enough.
 11. Avoid magic.




The most common priorities are: safety, performance, expressiveness, 
simplicity

I guess:
  1. means safety > performance
  6. means simplicity and expressiveness are in "balance"
  7. means simplicity > expressiveness
  11. means simplicity > expressiveness

So the priorities are

safety > performance > simplicity > expressiveness

Some ML based languages and maybe Scala seem to compete with D here. 



 2. High level where possible, low level where necessary.
 4. Easy things easy, difficult things possible.
 5. Thou shalt not need to write boilerplate code.
 8. User-defined types should not be treated differently.


 (16) "Concurrency should be easy and safe"?


Most modern languages strive for these.



 3. If it looks like C, it works like C or never compiles.




The burden of C's legacy.


 9. What the compiler knows, the programmer can query.




= reflection support


 10. What works at run-time, should work at compile-time.




= metaprogramming support


 12. The tool does not pick you - you pick the tool.




D developer's IQ > 90 ?


 15. We're consenting adults, not suicidal maniacs.




Some future directions for the newsgroup discussion?
Sep 17 2010
next sibling parent Justin Johansson <no spam.com> writes:
On 17/09/2010 10:14 PM, retard wrote:
<cut-previous-crap/>

 12. The tool does not pick you - you pick the tool.




 D developer's IQ>  90 ?


 15. We're consenting adults, not suicidal maniacs.




 Some future directions for the newsgroup discussion?


I don't think you should have even dignified the OP's
post with a response.

No reply is surely a quick answer. :-)
Sep 17 2010
prev sibling next sibling parent reply Gary Whatmore <no spam.spam> writes:
retard Wrote:


 Thu, 16 Sep 2010 21:38:24 -0400, sybrandy wrote:
 

 On 09/16/2010 07:04 AM, Simen Kjaeraas wrote:

 Here's a draft of something I'd like to see. I like having the ten





 
 FWIW, if you're picking up one of the most used languages out there, 
 their list won't differ that much:
 

                            == The D Manifesto ==

 0. Pragmatism is king.
 13. The straight path is safe and correct.
 14. The crooked path is passable.




 
 Who wants to write impractical code outside the academia?! The concepts 
 are way too abstract. Every member of the community has a different idea 
 about this.


Rest of the community agrees this. You fail to don't get it. D is a pragmatic
language. We design features for pragmatic programs.

* Operating systems kernels
* web servers
* virtual machines, and
* compielers are made in D not Java! There is also no haskell OS! Won't ever
coem.


What I typically see here is "unlike 
 dontlikestupid haskell, d is gooooood. haskell hate hate hate. ivory 
 tower hate hate. aarrrgh. hate"


Haskell is just stupid. Their waisting they're time! It's brainwash


 So the priorities are
 
 safety > performance > simplicity > expressiveness
 
 Some ML based languages and maybe Scala seem to compete with D here. 



ML is crap. Its A CS 101 language for noobs. Scala runs on Java machine so its
too slow and not native performance. Scala is also hard to understand!


 

 2. High level where possible, low level where necessary.
 4. Easy things easy, difficult things possible.
 5. Thou shalt not need to write boilerplate code.
 8. User-defined types should not be treated differently.


 (16) "Concurrency should be easy and safe"?


 
 Most modern languages strive for these.


I call that utter bullshit.


 
 D developer's IQ > 90 ?


Your IQ is below zero.

 - G.W.
Sep 17 2010
parent Russel Winder <russel russel.org.uk> writes:
On Fri, 2010-09-17 at 09:36 -0400, Gary Whatmore wrote:
[ . . . ]

I assume you are just trolling, but for the record . . .


 Haskell is just stupid. Their waisting they're time! It's brainwash


Haskell is far from stupid.  You may not like it, but saying it is
stupid is in itself just stupid.

[ . . . ]


 ML is crap. Its A CS 101 language for noobs. Scala runs on Java machine s=


o its too slow and not native performance. Scala is also hard to understand=
!

More nonsensical value judgements.

ML is a fine language, as is OCaml.  If you don't like it then fine.

The issue of Java and Scala performance is not as simple as "it runs on
a VM and is therefore slow".  Anyone who has done any microbenchmarking
or macrobenchmarking will tell you that native language have benefits in
some places and VM+JIT languages have advantages in others.  Blanket
statements come only from people who have not investigated the situation
properly -- clearly this is a blanket statement, and I have investigated
it, and it remains true by inductive logic.

Scala may be hard to understand for people who haven't studied it, but
then so is C++, C, D, Java, Clojure, Groovy, Python, assembly language.

[The rest of the email I am replying to is entirely ignorable being as
it contains only value-judgement statements of no value at all.]

--=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
Sep 17 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:

 FWIW, if you're picking up one of the most used languages out there, 
 their list won't differ that much:


Exactly. Much of that can be summed up as D being intended for professional 
production use, rather than:

1. a teaching tool (Pascal)
2. a research project (Haskell)
3. being focussed on solving one particular problem (Erlang)
4. designed to promote a related product (Flash)
5. designed for kids (Logo)
6. designed for non-programmers (Basic)
7. one paradigm to rule them all (Smalltalk)
8. gee, math is hard (Java)
9. implementing skynet (Lisp)
Sep 17 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Fri, 17 Sep 2010 14:33:30 -0700, Walter Bright wrote:


 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 
 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:
 
 1. a teaching tool (Pascal)
 2. a research project (Haskell)
 3. being focussed on solving one particular problem (Erlang) 4. designed
 to promote a related product (Flash) 5. designed for kids (Logo)
 6. designed for non-programmers (Basic) 7. one paradigm to rule them all
 (Smalltalk) 8. gee, math is hard (Java)
 9. implementing skynet (Lisp)


A funny pic, somewhat related.. (language X, as seen by language Y users)

http://i.imgur.com/1gF1j.jpg
Sep 17 2010
next sibling parent Justin Johansson <no spam.com> writes:
On 18/09/2010 8:09 AM, retard wrote:

 Fri, 17 Sep 2010 14:33:30 -0700, Walter Bright wrote:


 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:

 1. a teaching tool (Pascal)
 2. a research project (Haskell)
 3. being focussed on solving one particular problem (Erlang) 4. designed
 to promote a related product (Flash) 5. designed for kids (Logo)
 6. designed for non-programmers (Basic) 7. one paradigm to rule them all
 (Smalltalk) 8. gee, math is hard (Java)
 9. implementing skynet (Lisp)


 A funny pic, somewhat related.. (language X, as seen by language Y users)

 http://i.imgur.com/1gF1j.jpg


Excellent! Just need another row and column for D!  :-)
Sep 17 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 17/09/2010 23:39, retard wrote:

 Fri, 17 Sep 2010 14:33:30 -0700, Walter Bright wrote:


 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:

 1. a teaching tool (Pascal)
 2. a research project (Haskell)
 3. being focussed on solving one particular problem (Erlang) 4. designed
 to promote a related product (Flash) 5. designed for kids (Logo)
 6. designed for non-programmers (Basic) 7. one paradigm to rule them all
 (Smalltalk) 8. gee, math is hard (Java)
 9. implementing skynet (Lisp)


 A funny pic, somewhat related.. (language X, as seen by language Y users)

 http://i.imgur.com/1gF1j.jpg


retard, this is your best post ever! xP

-- 
Bruno Medeiros - Software Engineer
Oct 21 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Thu, 21 Oct 2010 13:13:54 +0100, Bruno Medeiros wrote:


 On 17/09/2010 23:39, retard wrote:

 Fri, 17 Sep 2010 14:33:30 -0700, Walter Bright wrote:


 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:

 1. a teaching tool (Pascal)
 2. a research project (Haskell)
 3. being focussed on solving one particular problem (Erlang) 4.
 designed to promote a related product (Flash) 5. designed for kids
 (Logo) 6. designed for non-programmers (Basic) 7. one paradigm to rule
 them all (Smalltalk) 8. gee, math is hard (Java) 9. implementing
 skynet (Lisp)


 A funny pic, somewhat related.. (language X, as seen by language Y
 users)

 http://i.imgur.com/1gF1j.jpg


 
 retard, this is your best post ever! xP


That's sad to hear -- I'm conscientiously aiming for bigger and bigger 
disappointments :-)
Oct 21 2010
parent Justin Johansson <no spam.com> writes:
On 22/10/2010 12:26 AM, retard wrote:

 Thu, 21 Oct 2010 13:13:54 +0100, Bruno Medeiros wrote:


 On 17/09/2010 23:39, retard wrote:

 Fri, 17 Sep 2010 14:33:30 -0700, Walter Bright wrote:


 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:

 1. a teaching tool (Pascal)
 2. a research project (Haskell)
 3. being focussed on solving one particular problem (Erlang) 4.
 designed to promote a related product (Flash) 5. designed for kids
 (Logo) 6. designed for non-programmers (Basic) 7. one paradigm to rule
 them all (Smalltalk) 8. gee, math is hard (Java) 9. implementing
 skynet (Lisp)


 A funny pic, somewhat related.. (language X, as seen by language Y
 users)

 http://i.imgur.com/1gF1j.jpg


 retard, this is your best post ever! xP


 That's sad to hear -- I'm conscientiously aiming for bigger and bigger
 disappointments :-)


Take it as a compliment as it one of the few that you will ever get on
this newsgroup.

Kind regards,
Justin
Oct 21 2010
prev sibling parent reply Justin Johansson <no spam.com> writes:
On 21/10/2010 11:13 PM, Bruno Medeiros wrote:

 On 17/09/2010 23:39, retard wrote:

 Fri, 17 Sep 2010 14:33:30 -0700, Walter Bright wrote:


 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:

 1. a teaching tool (Pascal)
 2. a research project (Haskell)
 3. being focussed on solving one particular problem (Erlang) 4. designed
 to promote a related product (Flash) 5. designed for kids (Logo)
 6. designed for non-programmers (Basic) 7. one paradigm to rule them all
 (Smalltalk) 8. gee, math is hard (Java)
 9. implementing skynet (Lisp)


 A funny pic, somewhat related.. (language X, as seen by language Y users)

 http://i.imgur.com/1gF1j.jpg


 retard, this is your best post ever! xP


Yes, it was a good post by retard.
I remember seeing it a few weeks ago.
IIRC D was not in the matrix of pictures
and one wonders how the missing rows/columns
for D should be rendered. :-)
Oct 21 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/10/2010 14:28, Justin Johansson wrote:

 On 21/10/2010 11:13 PM, Bruno Medeiros wrote:

 On 17/09/2010 23:39, retard wrote:

 Fri, 17 Sep 2010 14:33:30 -0700, Walter Bright wrote:


 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:

 1. a teaching tool (Pascal)
 2. a research project (Haskell)
 3. being focussed on solving one particular problem (Erlang) 4.
 designed
 to promote a related product (Flash) 5. designed for kids (Logo)
 6. designed for non-programmers (Basic) 7. one paradigm to rule them
 all
 (Smalltalk) 8. gee, math is hard (Java)
 9. implementing skynet (Lisp)


 A funny pic, somewhat related.. (language X, as seen by language Y
 users)

 http://i.imgur.com/1gF1j.jpg


 retard, this is your best post ever! xP


 Yes, it was a good post by retard.
 I remember seeing it a few weeks ago.
 IIRC D was not in the matrix of pictures
 and one wonders how the missing rows/columns
 for D should be rendered. :-)


I don't think you can have a row/column for D at this stage:
* Non-D programmers are not familiar enough with D to have an opinion of 
it, at least in a "stereotype" sense.
* And as for what D programmers think of other languages, well, it seems 
D attracts programmers from very varied backgrounds (C/C++, Java, 
scripting languages, etc.), so there would likely be wildly varied 
opinions about other languages. Probably the only consistent opinion 
would be about C/C++ (that although useful and powerful, it has immense 
innate shortcomings).

-- 
Bruno Medeiros - Software Engineer
Oct 21 2010
parent Juanjo Alvarez <fake fakeemail.com> writes:
On Thu, 21 Oct 2010 15:26:14 +0100, Bruno Medeiros 
<brunodomedeiros+spam com.gmail> wrote:

 * And as for what D programmers think of other languages, well, it 


seems

I guess D view of C++ could be rendered as an  alcoholic father while 
D view of C++ would be a fashion victim son.
Oct 21 2010
prev sibling next sibling parent sybrandy <sybrandy gmail.com> writes:
On 09/17/2010 05:33 PM, Walter Bright wrote:

 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:

 1. a teaching tool (Pascal)
 2. a research project (Haskell)
 3. being focussed on solving one particular problem (Erlang)
 4. designed to promote a related product (Flash)
 5. designed for kids (Logo)
 6. designed for non-programmers (Basic)
 7. one paradigm to rule them all (Smalltalk)
 8. gee, math is hard (Java)
 9. implementing skynet (Lisp)


Don't forget about this:

10. Creating the universe (Lisp...no, wait, Perl)

http://xkcd.com/224/

Casey
Sep 17 2010
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2010-09-17 at 14:33 -0700, Walter Bright wrote:

 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,=20
 their list won't differ that much:


=20
 Exactly. Much of that can be summed up as D being intended for profession=


al=20

 production use, rather than:
=20
 1. a teaching tool (Pascal)


Java, Python, C++, Alice are the languages of teaching these days.
Pascal died a death when Borland did.


 2. a research project (Haskell)


Haskell stopped being a research project many years ago, Haskell
development now happens in companies (including Microsoft) as much as in
universities and is about creating good examples of software
engineering.  Research languages are things like X10, Chapel, OCaml, C
++.


 3. being focussed on solving one particular problem (Erlang)


Yes but what a problem to have solved:  running the world's telephony
backbone with essentially zero downtime.


 4. designed to promote a related product (Flash)


What's the related product?


 5. designed for kids (Logo)


Actually this example is probably fair.


 6. designed for non-programmers (Basic)


As was Cobol, Fortran, spreadsheets (Visicalc, etc.).  There are
probably more spreadhseet programs out there than any other language:
counting all C, C++, D, and Java programs probably don't even get
close.=20


 7. one paradigm to rule them all (Smalltalk)


Assembly language,  C.


 8. gee, math is hard (Java)


A very large majority of students study computing and computer science
because they are failed mathematicians.  This probably means every
programming language is the way it is because maths is considered hard
by the inventors.


 9. implementing skynet (Lisp)


I wonder why Lisp gets so much flack.  It is unique amongst all
programming languages in that code =3D data is commutative.  This makes
Lisp interesting.  Well perhaps not Common Lisp, but Scheme and Clojure
are.

I think creating lists such as this is very counter-productive as an
approach to trying to promote anything.  It also reflects badly on the
thing being promoted.

--=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
Sep 17 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:

 On Fri, 2010-09-17 at 14:33 -0700, Walter Bright wrote:

 retard wrote:

 FWIW, if you're picking up one of the most used languages out there, 
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for professional 
 production use, rather than:

 1. a teaching tool (Pascal)


 
 Java, Python, C++, Alice are the languages of teaching these days.
 Pascal died a death when Borland did.


Pascal was specifically designed by Wirth as a teaching language (he says so in 
his Report, I can quote it for you if you like!). Java, Python and C++ were
not. 
I know nothing about Alice. Pascal predates Borland's Turbo Pascal by more than 
10 years, and ironically it is TP that brought it back from the dead.



 2. a research project (Haskell)


 
 Haskell stopped being a research project many years ago, Haskell
 development now happens in companies (including Microsoft) as much as in
 universities and is about creating good examples of software
 engineering.  Research languages are things like X10, Chapel, OCaml, C
 ++.


It still was designed as a research project. It even says so in the Haskell 98 
report:

"The committee intended that Haskell would serve as a basis for future research 
in language design, and hoped that extensions or variants of the language would 
appear, incorporating experimental features." -- Haskell98



 3. being focussed on solving one particular problem (Erlang)


 
 Yes but what a problem to have solved:  running the world's telephony
 backbone with essentially zero downtime.


I didn't say it wasn't successful at solving it :-)



 4. designed to promote a related product (Flash)


 
 What's the related product?


I believe it was to sell their (Macromedia) multimedia development environment. 
But if you don't like that, there's Javascript which was developed to push 
Netscape Navigator ahead of Explorer, and Microsoft responded with Vbscript to 
push Explorer.



 5. designed for kids (Logo)


 
 Actually this example is probably fair.
 

 6. designed for non-programmers (Basic)


 
 As was Cobol, Fortran, spreadsheets (Visicalc, etc.).  There are
 probably more spreadhseet programs out there than any other language:
 counting all C, C++, D, and Java programs probably don't even get
 close.


Basic is famous in that its charter specifically was for non-programmers. Cobol 
was designed for managers to be able to understand the code, not to write it (a 
slightly different aim). Was Fortran I really developed for non-programmers, or 
just to make programming easier (which it was wildly successful at)? Visicalc 
programming wasn't specifically developed for non-programmers, it was developed 
as whatever was expedient and easy to implement. It was developed in 6502 
assembler. You're not going to develop a sophisticated language under such a 
constraint.



 7. one paradigm to rule them all (Smalltalk)


 
 Assembly language,  C.


Assembler doesn't have a paradigm, in any case not one that it was designed 
around. C wasn't designed around a single paradigm, either, it was intended as
a 
general purpose language, and was specifically not designed for any particular 
area of application (so says K&R). C was designed to map efficiently to the 
PDP-11 instruction set.



 8. gee, math is hard (Java)


 
 A very large majority of students study computing and computer science
 because they are failed mathematicians.  This probably means every
 programming language is the way it is because maths is considered hard
 by the inventors.


I meant it as an allusion to "gee, C++ is hard". The "gee, math is hard" is an 
infamous quote attributed to one version of the Barbie doll that had a 
pull-to-talk string. Java was originally promoted as a simpler C++.



 9. implementing skynet (Lisp)


 
 I wonder why Lisp gets so much flack.  It is unique amongst all
 programming languages in that code = data is commutative.  This makes
 Lisp interesting.  Well perhaps not Common Lisp, but Scheme and Clojure
 are.


I meant it in the sense that Lisp's original use was to implement Artificial 
Intelligence.



 I think creating lists such as this is very counter-productive as an
 approach to trying to promote anything.  It also reflects badly on the
 thing being promoted.


Sorry, I had hoped it was both funny and to illustrate that there are languages 
that are designed for purposes other than professional application programming. 
It's not bashing a language to say it has a purpose other than D's purpose, 
especially when I can quote the inventor stating such.
Sep 18 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 18 Sep 2010 03:44:30 -0700, Walter Bright wrote:


 Russel Winder wrote:

 On Fri, 2010-09-17 at 14:33 -0700, Walter Bright wrote:

 retard wrote:

 FWIW, if you're picking up one of the most used languages out there,
 their list won't differ that much:


 Exactly. Much of that can be summed up as D being intended for
 professional production use, rather than:

 1. a teaching tool (Pascal)


 
 Java, Python, C++, Alice are the languages of teaching these days.
 Pascal died a death when Borland did.


 
 Pascal was specifically designed by Wirth as a teaching language (he
 says so in his Report, I can quote it for you if you like!). Java,
 Python and C++ were not. I know nothing about Alice. Pascal predates
 Borland's Turbo Pascal by more than 10 years, and ironically it is TP
 that brought it back from the dead.


Yes, Pascal WAS a teaching language. However, probably there are no 
colleges using it these days. Teachers have adopted more recent languages 
during the last 20 years and it makes no sense to compare anything to 
Pascal anymore.

TP and Delphi both brought Pascal back to mainstream. Later an open 
source compiler, FPC, appeared. However, these didn't manage to bring 
Pascal back. It's dead. The mainstream won't start using it anymore.


 2. a research project (Haskell)


 
 Haskell stopped being a research project many years ago, Haskell
 development now happens in companies (including Microsoft) as much as
 in universities and is about creating good examples of software
 engineering.  Research languages are things like X10, Chapel, OCaml, C
 ++.


 
 It still was designed as a research project. It even says so in the
 Haskell 98 report:
 
 "The committee intended that Haskell would serve as a basis for future
 research in language design, and hoped that extensions or variants of
 the language would appear, incorporating experimental features." --
 Haskell98


Something has happened. There are few enterprises using Haskell and the 
GHC compiler is rather stable after years of development effort. There 
are also truckloads of bindings to various libraries and many libraries 
written in Haskell.

I guess it's terribly hard to get rid of the 'ivory tower' stigma. What 
do you think is missing? They have:

 * a good compiler (more mature than dmd)
 * large set of libraries (more than d, seriously more than d2)
 * an active community (larger and more talented than d programmers)
 * research papers (does anyone have any idea if a single academic 
conference paper has ever been written about d?)
 * website (better than digitalmars.com)
 * a well defined language


 4. designed to promote a related product (Flash)


 
 What's the related product?


 
 I believe it was to sell their (Macromedia) multimedia development
 environment. But if you don't like that, there's Javascript which was
 developed to push Netscape Navigator ahead of Explorer, and Microsoft
 responded with Vbscript to push Explorer.


Netscape Navigator is dead. Vbscript is dead. Nowadays the Web 2.0 world 
is using IE 8, Firefox 3.6, Chrome 6, and many other standard compliant 
browsers. The platforms of choice today are Flash 10, Silverlight, Java 
6, and Javascript. Everything else is obsolete.


 

 6. designed for non-programmers (Basic)


 
 As was Cobol, Fortran, spreadsheets (Visicalc, etc.).  There are
 probably more spreadhseet programs out there than any other language:
 counting all C, C++, D, and Java programs probably don't even get
 close.


 
 Basic is famous in that its charter specifically was for
 non-programmers. Cobol was designed for managers to be able to
 understand the code, not to write it (a slightly different aim).


Both Basic and Cobol are dead outside some legacy projects. It's not 
useful to discuss those.


 7. one paradigm to rule them all (Smalltalk)


 
 Assembly language,  C.


 
 Assembler doesn't have a paradigm, in any case not one that it was
 designed around. C wasn't designed around a single paradigm, either, it
 was intended as a general purpose language, and was specifically not
 designed for any particular area of application (so says K&R). C was
 designed to map efficiently to the PDP-11 instruction set.


The inventors of C just didn't realize it's a single paradigm language. 
It's a procedural imperative language, nothing more.
Sep 18 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from retard (re tard.com.invalid)'s article

 2. a research project (Haskell)


 Haskell stopped being a research project many years ago, Haskell
 development now happens in companies (including Microsoft) as much as
 in universities and is about creating good examples of software
 engineering.  Research languages are things like X10, Chapel, OCaml, C
 ++.


 It still was designed as a research project. It even says so in the
 Haskell 98 report:

 "The committee intended that Haskell would serve as a basis for future
 research in language design, and hoped that extensions or variants of
 the language would appear, incorporating experimental features." --
 Haskell98


 Something has happened. There are few enterprises using Haskell and the
 GHC compiler is rather stable after years of development effort. There
 are also truckloads of bindings to various libraries and many libraries
 written in Haskell.
 I guess it's terribly hard to get rid of the 'ivory tower' stigma. What
 do you think is missing? They have:
  * a good compiler (more mature than dmd)
  * large set of libraries (more than d, seriously more than d2)
  * an active community (larger and more talented than d programmers)
  * research papers (does anyone have any idea if a single academic
 conference paper has ever been written about d?)
  * website (better than digitalmars.com)
  * a well defined language


Multiple paradigms are what's missing.  I refuse to consider any language that
adheres so rigidly to a single paradigm as anything more than an ivory tower
research project, no matter what.  In the real world no one paradigm suits every
problem, or even every small subproblem.  I emphasize the small subproblem part
because it implies that using multiple languages isn't they answer.
Sep 18 2010
next sibling parent retard <re tard.com.invalid> writes:
Sat, 18 Sep 2010 15:59:24 +0000, dsimcha wrote:


 == Quote from retard (re tard.com.invalid)'s article

 2. a research project (Haskell)


 Haskell stopped being a research project many years ago, Haskell
 development now happens in companies (including Microsoft) as much
 as in universities and is about creating good examples of software
 engineering.  Research languages are things like X10, Chapel, OCaml,
 C ++.


 It still was designed as a research project. It even says so in the
 Haskell 98 report:

 "The committee intended that Haskell would serve as a basis for
 future research in language design, and hoped that extensions or
 variants of the language would appear, incorporating experimental
 features." -- Haskell98


 Something has happened. There are few enterprises using Haskell and the
 GHC compiler is rather stable after years of development effort. There
 are also truckloads of bindings to various libraries and many libraries
 written in Haskell.
 I guess it's terribly hard to get rid of the 'ivory tower' stigma. What
 do you think is missing? They have:
  * a good compiler (more mature than dmd) * large set of libraries
  (more than d, seriously more than d2) * an active community (larger
  and more talented than d programmers) * research papers (does anyone
  have any idea if a single academic
 conference paper has ever been written about d?)
  * website (better than digitalmars.com) * a well defined language


 
 Multiple paradigms are what's missing.  I refuse to consider any
 language that adheres so rigidly to a single paradigm as anything more
 than an ivory tower research project, no matter what.  In the real world
 no one paradigm suits every problem, or even every small subproblem.  I
 emphasize the small subproblem part because it implies that using
 multiple languages isn't they answer.


Right, that's a reasonable explanation. E.g. Java only supports 
procedural and object-oriented programming. The frameworks and tools 
supplement that with metaprogramming and aspect oriented programming (all 
kinds of code generators such as IDEs). That seems to be enough for most 
developers.
Sep 18 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 18 September 2010 08:59:24 dsimcha wrote:

 == Quote from retard (re tard.com.invalid)'s article
 

 2. a research project (Haskell)


 
 Haskell stopped being a research project many years ago, Haskell
 development now happens in companies (including Microsoft) as much as
 in universities and is about creating good examples of software
 engineering.  Research languages are things like X10, Chapel, OCaml, C
 ++.


 
 It still was designed as a research project. It even says so in the
 Haskell 98 report:
 
 "The committee intended that Haskell would serve as a basis for future
 research in language design, and hoped that extensions or variants of
 the language would appear, incorporating experimental features." --
 Haskell98


 
 Something has happened. There are few enterprises using Haskell and the
 GHC compiler is rather stable after years of development effort. There
 are also truckloads of bindings to various libraries and many libraries
 written in Haskell.
 I guess it's terribly hard to get rid of the 'ivory tower' stigma. What
 
 do you think is missing? They have:
  * a good compiler (more mature than dmd)
  * large set of libraries (more than d, seriously more than d2)
  * an active community (larger and more talented than d programmers)
  * research papers (does anyone have any idea if a single academic
 
 conference paper has ever been written about d?)
 
  * website (better than digitalmars.com)
  * a well defined language


 
 Multiple paradigms are what's missing.  I refuse to consider any language
 that adheres so rigidly to a single paradigm as anything more than an
 ivory tower research project, no matter what.  In the real world no one
 paradigm suits every problem, or even every small subproblem.  I emphasize
 the small subproblem part because it implies that using multiple languages
 isn't they answer.


Except that it's not necessarily the case that one language should be used to 
solve everything. I totally agree that it's generally better to have a general 
purpose language that supports multiple paradigms, but sometimes it's useful to 
use a language that's much more focused. Extreme examples of that are domain-
specific languages where they can only be used in one area.

I've used Haskell a fair bit, and for some types of problems, it's fantastic. 
For others, it's horrific. On the whole, I'd prefer to use D which is more 
general purpose, but that doesn't mean that I'll never use Haskell again. I 
prefer D to Java and C++, but odds are that I'll still end up using them if
they 
fit the problem better for whatever reason.

The reality of the matter is that it's unreasonable to expect one language to
be 
the best language to solve every problem, no matter how good it is. Every 
language has its strengths and weaknesses. D is more general purpose than 
Haskell and therefore will be the best language for far more problems than 
Haskell, but doesn't mean that Haskell will never be a better choice than D for 
a particular problem.

And of course, there's always preference. Plenty of stuff can be done just as 
well in multiple languages, at which point, there is no best language - it's 
whatever the programmer prefers to use.

Ultimately, I don't see the fact that a language isn't particularly multi-
paradigm to be a problem. It just means that it's not the language to use when 
you're not doing something where that paradigm is the best to use. And 
naturally, using more general purpose languages is generally a better idea, 
since they're more flexible. But there's plent of room for a variety of 
programming languages in this world, including ones which are pretty much
single 
paradigm languages.

- Jonathan M Davis
Sep 18 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:

 Yes, Pascal WAS a teaching language. However, probably there are no 
 colleges using it these days. Teachers have adopted more recent languages 
 during the last 20 years and it makes no sense to compare anything to 
 Pascal anymore.


I meant it as an example of a language that was designed for a purpose other 
than what D was designed for. Sheesh!



 TP and Delphi both brought Pascal back to mainstream.


Delphi came along long after TP, and while it is a derivative of Pascal, it is 
not Pascal.



 I guess it's terribly hard to get rid of the 'ivory tower' stigma.


I didn't give it a stigma. I said it was designed as a research language - and 
it was. Their own designers said it was.



 What do you think is missing?


I did not say anything was missing, nor did I criticize Haskell. I made a 
statement of fact.



 Netscape Navigator is dead. Vbscript is dead. Nowadays the Web 2.0 world 
 is using IE 8, Firefox 3.6, Chrome 6, and many other standard compliant 
 browsers. The platforms of choice today are Flash 10, Silverlight, Java 
 6, and Javascript. Everything else is obsolete.


True, but irrelevant. I mentioned these as examples whose goal was to push a 
related product. Want some more? PALASM, given away for free in order to get 
people to use Programmable Logic Arrays, and it was highly successful at doing
that.



 Basic is famous in that its charter specifically was for
 non-programmers. Cobol was designed for managers to be able to
 understand the code, not to write it (a slightly different aim).


 
 Both Basic and Cobol are dead outside some legacy projects.


True, but irrelevant to my point. I see that nobody understood my point at all.



 The inventors of C just didn't realize it's a single paradigm language.


Meaning it was not deliberately designed as a single paradigm language. The 
topic I'm addressing is design goals for a language - not what the language 
became, evolved into, or whether it is in wide use or dead.
Sep 18 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 18 September 2010 11:43:36 Walter Bright wrote:

 Basic is famous in that its charter specifically was for
 non-programmers. Cobol was designed for managers to be able to
 understand the code, not to write it (a slightly different aim).


 
 Both Basic and Cobol are dead outside some legacy projects.


 
 True, but irrelevant to my point. I see that nobody understood my point at
 all.


I do! You're talking about the purposes behind the design of a language, and 
what it was designed for. What that language has later been used for is an 
entirely separate issue.

- Jonathan M Davis
Sep 18 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:

 On Saturday 18 September 2010 11:43:36 Walter Bright wrote:

 Basic is famous in that its charter specifically was for
 non-programmers. Cobol was designed for managers to be able to
 understand the code, not to write it (a slightly different aim).


 Both Basic and Cobol are dead outside some legacy projects.


 True, but irrelevant to my point. I see that nobody understood my point at
 all.


 
 I do! You're talking about the purposes behind the design of a language, and 
 what it was designed for. What that language has later been used for is an 
 entirely separate issue.


Thanks, I'm glad I wasn't being totally incomprehensible!
Sep 18 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Walter Bright <newshound2 digitalmars.com> wrote:


 True, but irrelevant to my point. I see that nobody understood my point  
 at all.


I'm sure I'm not the only with my palm glued to my face from the replies
you got.

-- 
Simen
Sep 18 2010
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
 True, but irrelevant to my point. I see that nobody understood my point=


 at all.

	I am appalled at the way some people here seem unable to understand
basic sentences both in this thread and others (and it's not just a
question of not being native English speakers, I'm not either). I'm
starting to wonder if they are not deliberately misunderstanding you
to generate noise...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Sep 20 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Sat, 18 Sep 2010 03:44:30 -0700, Walter Bright wrote:


 I know nothing about Alice.


You SHOULD probably study the ML family of languages a bit more closely. 
It feels like we're having a conversation with a dinosaur.

After all, in the functional programming world, ML languages are the 
closest competitor of D. Why? Both try to be safe, modular, strict (= not 
lazy by default), functional, garbage collected, often compile to native 
code, and have an expressive static type system with inference.

Alice is the Alice ML dialect, http://www.ps.uni-saarland.de/alice/
Sep 18 2010
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
retard wrote:


 Sat, 18 Sep 2010 03:44:30 -0700, Walter Bright wrote:
 

 I know nothing about Alice.


 
 You SHOULD probably study the ML family of languages a bit more closely.
 It feels like we're having a conversation with a dinosaur.
 
 After all, in the functional programming world, ML languages are the
 closest competitor of D. Why? Both try to be safe, modular, strict (= not
 lazy by default), functional, garbage collected, often compile to native
 code, and have an expressive static type system with inference.
 
 Alice is the Alice ML dialect, http://www.ps.uni-saarland.de/alice/


Do you know if Alice is suited for practical programming, any experience? I
know 
only that it is somewhat related to Oz which had a reasonably extensive 
ecosystem, but it doesn't seem to be developed anymore.
Sep 18 2010
parent reply retard <re tard.com.invalid> writes:
Sat, 18 Sep 2010 18:43:45 +0200, Lutger wrote:


 retard wrote:
 

 Sat, 18 Sep 2010 03:44:30 -0700, Walter Bright wrote:
 

 I know nothing about Alice.


 
 You SHOULD probably study the ML family of languages a bit more
 closely. It feels like we're having a conversation with a dinosaur.
 
 After all, in the functional programming world, ML languages are the
 closest competitor of D. Why? Both try to be safe, modular, strict (=
 not lazy by default), functional, garbage collected, often compile to
 native code, and have an expressive static type system with inference.
 
 Alice is the Alice ML dialect, http://www.ps.uni-saarland.de/alice/


 
 Do you know if Alice is suited for practical programming, any
 experience? I know only that it is somewhat related to Oz which had a
 reasonably extensive ecosystem, but it doesn't seem to be developed
 anymore.


Unfortunately no, but the web site gives an impression that the 
development has stalled few years ago. I think Alice used the Oz's 
runtime, but is now a separate project with a new backend. If I'd write 
something significant commercial code in any functional language, I might
Sep 18 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/18/2010 12:31 PM, retard wrote:

 Sat, 18 Sep 2010 18:43:45 +0200, Lutger wrote:


 retard wrote:


 Sat, 18 Sep 2010 03:44:30 -0700, Walter Bright wrote:


 I know nothing about Alice.


 You SHOULD probably study the ML family of languages a bit more
 closely. It feels like we're having a conversation with a dinosaur.

 After all, in the functional programming world, ML languages are the
 closest competitor of D. Why? Both try to be safe, modular, strict (=
 not lazy by default), functional, garbage collected, often compile to
 native code, and have an expressive static type system with inference.

 Alice is the Alice ML dialect, http://www.ps.uni-saarland.de/alice/


 Do you know if Alice is suited for practical programming, any
 experience? I know only that it is somewhat related to Oz which had a
 reasonably extensive ecosystem, but it doesn't seem to be developed
 anymore.


 Unfortunately no, but the web site gives an impression that the
 development has stalled few years ago. I think Alice used the Oz's
 runtime, but is now a separate project with a new backend. If I'd write
 something significant commercial code in any functional language, I might



Then probably it's fair to not chastise Walter for not having heard of 
it. (FWIW I'm familiar with ML and somewhat so with OCaml, but I only 
vaguely knew of a language called Alice and didn't know it was related 
to ML.)

Andrei
Sep 18 2010
prev sibling parent reply retard++ <more retarded.invalid.com> writes:
 If I'd write 
 something significant commercial code in any functional language, I might 



Have you ever written something significant ?
Sep 18 2010
next sibling parent reply retarded.clear() <int main.void> writes:
retard++ Wrote:


 If I'd write 
 something significant commercial code in any functional language, I might 



 
 Have you ever written something significant ?
 


The douchebag has never done anything. Trolling here day and night. Doesn't
know anything about functional programming, but reads those reddit posts and
comes here to boost his ego with the news about new technologies. Has no
practical experience with any language. I know these kinds of losers. If he had
real talent, he would write code and shut up.
Sep 18 2010
parent Justin Johansson <no spam.com> writes:
On 19/09/2010 7:41 AM, retarded.clear() wrote:

 retard++ Wrote:


 If I'd write
 something significant commercial code in any functional language, I might



 Have you ever written something significant ?


 The douchebag has never done anything. Trolling here day and night. Doesn't
know anything about functional programming, but reads those reddit posts and
comes here to boost his ego with the news about new technologies. Has no
practical experience with any language. I know these kinds of losers. If he had
real talent, he would write code and shut up.


"If he had real talent, he would write code and shut up"

What language do you propose the alleged "douchebag" *should* write
code in?  Possibly the person referred to does have real talent,
he/she does actually write good code, and further he/she is
an asset to this community as a devil's advocate to question where
D is going or purports to go?

Cheers
Justin Johansson
Sep 19 2010
prev sibling parent Justin Johansson <no spam.com> writes:
On 19/09/2010 7:20 AM, retard++ wrote:

 If I'd write
 something significant commercial code in any functional language, I might



 Have you ever written something significant ?


Here's a significant challenge.

Try implementing the XPath 2.0 XDM data model in D and see where
you come unstuck.  I have tried very hard to do this (in C++
and Java also) and time and time again the classical OO paradigm
proves that it is incapable of solving problems relating to the
modeling of complex type systems without an inordinate amount of
code.

In this respect D is not multi-paradigm by any means (no more than
C++ or Java).  D is just another way of doing the more of the same
old classical OO crap as does C++ and Java and its better meta-
-programming capabilities, whilst a credit to itself, don't actually
help to solve these kinds of complex type systems problems either.

To solve the kinds of type system modelings that I am interested
in, I feel that a higher level of approach is needed beyond what
languages like C++, Java and D can deliver with their incestuous
view of the OO world.

Cheers
Justin Johansson
Sep 19 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:

 It feels like we're having a conversation with a dinosaur.


I apologize for all my numerous shortcomings!
Sep 18 2010
parent reply retard <re tard.com.invalid> writes:
Sat, 18 Sep 2010 11:45:51 -0700, Walter Bright wrote:


 retard wrote:

 It feels like we're having a conversation with a dinosaur.


 
 I apologize for all my numerous shortcomings!


I'm sorry :-) But I still recommend writing couple of hundreds of lines 
of code in some ML. It's a great experience.
Sep 18 2010
next sibling parent "JimBob" <jim bob.com> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i73350$2m08$3 digitalmars.com...

 Sat, 18 Sep 2010 11:45:51 -0700, Walter Bright wrote:


 retard wrote:

 It feels like we're having a conversation with a dinosaur.


 I apologize for all my numerous shortcomings!


 I'm sorry :-) But I still recommend writing couple of hundreds of lines
 of code in some ML. It's a great experience.


If you wont go out of the house at least open the curtains for a bit.
Sep 18 2010
prev sibling parent reply Jay Byrd <JayByrd rebels.com> writes:
On Sat, 18 Sep 2010 19:15:44 +0000, retard wrote:


 Sat, 18 Sep 2010 11:45:51 -0700, Walter Bright wrote:
 

 retard wrote:

 It feels like we're having a conversation with a dinosaur.


 
 I apologize for all my numerous shortcomings!


 
 I'm sorry :-) But I still recommend writing couple of hundreds of lines
 of code in some ML. It's a great experience.


Still? Your previous comment criticized Walter for not knowing what Alice 
is -- a totally different matter. You sure do live up to your user name.
Sep 20 2010
parent reply hismastersvoice <word of.god> writes:
Jay Byrd Wrote:


 On Sat, 18 Sep 2010 19:15:44 +0000, retard wrote:
 

 Sat, 18 Sep 2010 11:45:51 -0700, Walter Bright wrote:
 

 retard wrote:

 It feels like we're having a conversation with a dinosaur.


 
 I apologize for all my numerous shortcomings!


 
 I'm sorry :-) But I still recommend writing couple of hundreds of lines
 of code in some ML. It's a great experience.


 
 Still? Your previous comment criticized Walter for not knowing what Alice 
 is -- a totally different matter. You sure do live up to your user name.


Why don't you both cut that shit out and go play to the kindergarten? No one
has to study any stupid functional language, especially toys like that Alice.
How stupid is the name anyway? Oz? Alice? WTF

And stop posting one liners. Like we now latin? Not every one is university
educated.
Sep 20 2010
next sibling parent Russel Winder <russel russel.org.uk> writes:
On Mon, 2010-09-20 at 17:29 -0400, hismastersvoice wrote:
[ . . . ]

 Why don't you both cut that shit out and go play to the kindergarten? No =


one has to study any stupid functional language, especially toys like that =
Alice. How stupid is the name anyway? Oz? Alice? WTF

I certainly agree with your first sentence:  the standard of posting on
this list by some people is getting worse than appalling.  Dreadful
language, nigh on offensive comments made in an off-hand and disparaging
manner.  Whatever happened to respect and courtesy?

Sadly you then ruin it in your second sentence.  Whichever language you
use to program in in a day-to-day sense, learning how to program in all
of Lisp, Haskell, C, Java, Python, Alice, Ruby, D, Scala, C++, OCaml,
Fortran, Groovy, Prolog, etc. makes you a better programmer in the
language you are using.  This is not wishful thinking or a condescending
"hand down" statement, there is repeatable, evidential data -- the
psychology of programming folk have been doing experiments on these
issues for 25 years and more, and consistently finding that knowing how
to program well in multiple computational models makes you a better
programmer in your language of choice.

So do study functional languages even if you are programming using D, it
will help your D usage.  If not Alice, then Clojure, Haskell, OCaml,
Scheme -- pick one, or more.  Write some code in those languages, and
see that it helps you think different about how to write D code.  Your D
programming will get better.


 And stop posting one liners. Like we now latin? Not every one is universi=


ty educated.

What I find irritating is people who do not edit the quoted reply when
making their one-line response.  To have pages and pages of quote to
trawl through to get to the one-liner is what should not happen.

Oh and being university educated doesn't mean you know (note spelling)
Latin (note capitalization, the name of the language is a proper noun
and hence capitalized).

Yours, looking forward to a higher standard of posting by everyone,

--=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
Sep 20 2010
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
hismastersvoice wrote:

 And stop posting one liners. Like we now latin? Not every one is univer=


sity educated.

	"non sequitur" is in the English dictionary (Collins Cobuild 1992)
so you shouldn't need to know Latin to understand the expression...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Sep 21 2010
parent BCS <none anon.com> writes:
Hello Jérôme,


 hismastersvoice wrote:
 

 And stop posting one liners. Like we now latin? Not every one is
 university educated.
 


 "non sequitur" is in the English dictionary (Collins Cobuild 1992) so
 you shouldn't need to know Latin to understand the expression...


Heck, A spell check could do a decent translation.

-- 
... <IXOYE><
Sep 21 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Walter Bright wrote:

 C wasn't designed around a single paradigm, either, it 
 was intended as a general purpose language, and was specifically not 
 designed for any particular area of application (so says K&R).


One example of C not being a particular paradigm is that it included modern
(for 
the time) structured programming constructs, but still supported goto.
Sep 18 2010
prev sibling parent reply Juanjo Alvarez <fake fakeemail.com> writes:
On Fri, 17 Sep 2010 14:33:30 -0700, Walter Bright 
<newshound2 digitalmars.com> wrote:

 Exactly. Much of that can be summed up as D being intended for 


professional 

 production use, rather than:


Anyway you can't ignore D's productivity. As a newcomer after one 
week learning and toying with D my productivity is about 70% of the 
one I have with Python after 8 years doing Python, and higher than 
the one I've with Java or C++. 

I've found that the compiler error messages are usually very 
informative,  which helps, but being able to link with C libs is a 
boost too, compared to Python or Java where you need to write lot 
more than declarations. 

Yesterday I translated some Python code (Quixote's scgi.py) to D in a 
couple hours and now it runs like five times faster (before any 
optimization or D-ization) using 10% of the.memory.  The translation 
was almost direct, line by line which speaks a lot about D's 
expresivity (I only missed something like list.remove(item)).
Sep 26 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Juanjo Alvarez wrote:

 Anyway you can't ignore D's productivity. As a newcomer after one week 
 learning and toying with D my productivity is about 70% of the one I 
 have with Python after 8 years doing Python, and higher than the one 
 I've with Java or C++.
 I've found that the compiler error messages are usually very 
 informative,  which helps, but being able to link with C libs is a boost 
 too, compared to Python or Java where you need to write lot more than 
 declarations.
 Yesterday I translated some Python code (Quixote's scgi.py) to D in a 
 couple hours and now it runs like five times faster (before any 
 optimization or D-ization) using 10% of the.memory.  The translation was 
 almost direct, line by line which speaks a lot about D's expresivity (I 
 only missed something like list.remove(item)).


It's a great case history, thanks for posting this.

The problem with touting D's productivity, though, is that unless a new way can 
be found to tout it, it will be ineffective. This is because everyone touts 
their language as "more productive". People just see "more productive" and
their 
brain just skips over it without it even entering their conscious thought.
Sep 27 2010
parent reply Juanjo Alvarez <fake fakeemail.com> writes:
On Mon, 27 Sep 2010 21:28:16 -0700, Walter Bright 
<newshound2 digitalmars.com> wrote:

 be found to tout it, it will be ineffective. This is because 


everyone touts 

 their language as "more productive". People just see "more 


productive" and their 

 brain just skips over it without it even entering their conscious 


thought.

Well, in this case I don't believe that D is more productive than 
Python in the short term (it could be in the long term for big 
codebases involving several developers). But it is almost as 
productive while smoking it in performance and resource usage. So it 
is more like you have the advantages of a natively compiled language 
without many of the drawbacks.
Sep 28 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Juanjo Alvarez Wrote:


 On Mon, 27 Sep 2010 21:28:16 -0700, Walter Bright 
 <newshound2 digitalmars.com> wrote:

 be found to tout it, it will be ineffective. This is because 


 everyone touts 

 their language as "more productive". People just see "more 


 productive" and their 

 brain just skips over it without it even entering their conscious 


 thought.
 
 Well, in this case I don't believe that D is more productive than 
 Python in the short term (it could be in the long term for big 
 codebases involving several developers). But it is almost as 
 productive while smoking it in performance and resource usage. So it 
 is more like you have the advantages of a natively compiled language 
 without many of the drawbacks.


This is exactly how it should be marketed. It has the productivity of Python,
other dynamic languages, with the performance and power of a natively compiled
language.
Sep 28 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jesse Phillips:


 This is exactly how it should be marketed. It has the productivity
 of Python, other dynamic languages, with the performance and power
 of a natively compiled language.


Most programmers are able to see that's very false, today.


today the Web is very important, and D can't be used in browers.

I think that if D wants a chance to not die as many other C-inspired languages
have done in past, Walter needs lot of perseverance and to keep slowly
improving D for 8-10 more years. When D will be "good enough" maybe some people
will start to use it. But the implementation of D2 is currently far from that
point.

Bye,
bearophile
Sep 28 2010
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
bearophile Wrote:


 Jesse Phillips:
 

 This is exactly how it should be marketed. It has the productivity
 of Python, other dynamic languages, with the performance and power
 of a natively compiled language.


 
 Most programmers are able to see that's very false, today.
 

But today the Web is very important, and D can't be used in browers.
 
 I think that if D wants a chance to not die as many other C-inspired languages
have done in past, Walter needs lot of perseverance and to keep slowly
improving D for 8-10 more years. When D will be "good enough" maybe some people
will start to use it. But the implementation of D2 is currently far from that
point.
 
 Bye,
 bearophile


I agree that much more time and work must go into it, especially a good working
selection of libraries. But for the most part it does deliver what I described
but not in all areas, e.g. web.



D offers. Oh, and I need to figure out how to effectively use a GUI designer so
that production is actually increased when making GUIs.
Sep 28 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, September 28, 2010 10:22:09 bearophile wrote:

 Jesse Phillips:

 This is exactly how it should be marketed. It has the productivity
 of Python, other dynamic languages, with the performance and power
 of a natively compiled language.


 
 Most programmers are able to see that's very false, today.
 

 But today the Web is very important, and D can't be used in browers.
 
 I think that if D wants a chance to not die as many other C-inspired
 languages have done in past, Walter needs lot of perseverance and to keep
 slowly improving D for 8-10 more years. When D will be "good enough" maybe
 some people will start to use it. But the implementation of D2 is
 currently far from that point.
 
 Bye,
 bearophile


Well, there's certainly plenty of more work to be done on dmd, but it won't
take 
8 - 10 more years for it reach the point where it's fully stable and feature-
complete and completely reasonable for using in production code. What it really 

libraries and tool support. The number of libraries out there for most popular 
languages is enormous. D just doesn't have that (though the fact that it can 
call C, and to some extent C++, definitely helps). Phobos is continuing to move 
forward, and work on tools for D is being done, and at some point we may be 
closer to more established languages, but that will definitely take time, and
it 
could very well be 8 - 10 more years before the D ecosystem is really on par 
with that of many popular, more established languages. But it could get there. 
For instance, it's taken years for python to get where it is today. But steady 
growth in usage has gotten it to the point where it's a major and popular 
language.

As it stands, I think that the statements of about D's productivity are true
for 
many tasks, but compiler bugs and the lack of libraries (much as both are 
improving) can really take a toll on productivity in comparison to languages 
which are completely stable and have lots of existing library code available.
If 
we stick with it, though, we should get there eventually.

- Jonathan M Davis
Sep 28 2010
prev sibling next sibling parent reply Juanjo Alvarez <fake fakeemail.com> writes:
On Tue, 28 Sep 2010 13:22:09 -0400, bearophile 
<bearophileHUGS lycos.com> wrote:




multi-platform. But today the Web is very important, and D can't be 
used in browers.

And performance, (most of the time) . And memory usage.
Sep 28 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Juanjo Alvarez (fake fakeemail.com)'s article

 On Tue, 28 Sep 2010 13:22:09 -0400, bearophile
 <bearophileHUGS lycos.com> wrote:




 multi-platform. But today the Web is very important, and D can't be
 used in browers.
 And performance, (most of the time) . And memory usage.


And metaprogramming.
Sep 28 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
dsimcha:

 And metaprogramming.



And if you take a look at the Google C++ style guide you see that for a
representative group of programmers the metaprogramming capabilities are a
negative thing :-)

Bye,
bearophile
Sep 28 2010
next sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
bearophile Wrote:


 dsimcha:

 And metaprogramming.


 

 And if you take a look at the Google C++ style guide you see that for a
representative group of programmers the metaprogramming capabilities are a
negative thing :-)
 
 Bye,
 bearophile


And D can do that at compile time.

C++ meta programming is ugly.
Sep 28 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:




Any language can do that.


 And if you take
 a look at the Google C++ style guide you see that for a representative group
 of programmers the metaprogramming capabilities are a negative thing :-)


I'd be careful not to conflate C++ template metaprogramming with
metaprogramming 
in general.
Sep 28 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:





 
 Any language can do that.



have a human API to build an AST and then you are able to compile and run it.
The 'compiler as library' is something I have suggested for D too, and you said
no. Anyway, I am not asking for this feature now.

Bye,
bearophile
Sep 28 2010
prev sibling parent BCS <none anon.com> writes:
Hello Walter,


 bearophile wrote:
 


 


 Any language can do that.
 

 And if you take
 a look at the Google C++ style guide you see that for a
 representative group
 of programmers the metaprogramming capabilities are a negative thing
 :-)


 I'd be careful not to conflate C++ template metaprogramming with
 metaprogramming in general.
 


I think it is safe to say that the ghastly hackery needed to do MP in C++ 
is a *major* part of the reason it is banned. OTOH the other reasons might 
be enough to keep it out even still.

-- 
... <IXOYE><
Sep 28 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Tue, 28 Sep 2010 13:22:09 -0400, bearophile wrote:

 Jesse Phillips:
 

 This is exactly how it should be marketed. It has the productivity of
 Python, other dynamic languages, with the performance and power of a
 natively compiled language.


 
 Most programmers are able to see that's very false, today.
 

 multi-platform. But today the Web is very important, and D can't be used
 in browers.


I don't find it surprising that people here agree, when one is bashing 

language than D and that means it by definition has better portability to 




 I think that if D wants a chance to not die as many other C-inspired
 languages have done in past, Walter needs lot of perseverance and to
 keep slowly improving D for 8-10 more years. When D will be "good
 enough" maybe some people will start to use it. But the implementation
 of D2 is currently far from that point.


D2 basically brought the number of supported libraries back to zero. It's 
almost like starting from scratch.

Jesse Phillips wrote:

 This is exactly how it should be marketed. It has the productivity of
 Python, other dynamic languages, with the performance and power of a
 natively compiled language.


I keep wondering, what language has the best productivity? How is it 
possible that people here STILL think that a single language could solve 
all problems. Is Python the right choice when creating interactive 
browser games? Is it the right choice for iPhone? Is it good for writing 
filesystem drivers? Is it good for high performance computing (vs FORTRAN 
et al).

Juanjo Alvarez wrote:

 As a newcomer after one week learning and toying with D my productivity
 is about 70% of the one I have with Python after 8 years doing Python,
 and higher than the one I've with Java or C++.


That's pretty awesome. You have maybe 0.001% of the libraries directly 
available, a buggy compiler, no 64-bit support, no formal spec etc. etc. 
And still you get about 70% of the productivity. And people say Python is 
maybe the most productive general purpose language out there. That's just 
incredible. My guess is, when D 2.0 is finally production ready, you're 
at least 100 times more productive than with Python. You can write 100000 
lines of code per day.
Sep 28 2010
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 28 September 2010 12:36:32 retard wrote:

 Tue, 28 Sep 2010 13:22:09 -0400, bearophile wrote:

 Jesse Phillips:

 This is exactly how it should be marketed. It has the productivity of
 Python, other dynamic languages, with the performance and power of a
 natively compiled language.


 
 Most programmers are able to see that's very false, today.
 

 multi-platform. But today the Web is very important, and D can't be used
 in browers.


 
 I don't find it surprising that people here agree, when one is bashing

 language than D and that means it by definition has better portability to






intended for Windows. Microsoft only likes to claim that it's cross platform.
In 
principle, given its VM and whatnot, it really should be cross platform similar 
to how Java is cross platform, but it really isn't. Sure, having Mono is way 
better than nothing, but it's always light years behind the Windows 
implementation, and if you want programs to run both on Windows and on other 
OSes with Mono, you're going to have to use a subset of the language and give
up 
a lot of nice stuff.

D is cross platform in the same way that C++ is, the same way that _most_ 

you're targetting. Really, I don't see much point in touting a language as
cross 
platform unless you're talking about Java's compile once run anywhere kind of 

one platform). So, it really doesn't make much sense to me to make a big deal 
about D being cross platform unless you're talking about how some of its 
constructs (like version) make it easier to deal with code for different 

that touting D as cross platform.

- Jonathan M Davis
Sep 28 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 28 Sep 2010 15:36:32 -0400, retard <re tard.com.invalid> wrote:


 Tue, 28 Sep 2010 13:22:09 -0400, bearophile wrote:

 Jesse Phillips:


 This is exactly how it should be marketed. It has the productivity of
 Python, other dynamic languages, with the performance and power of a
 natively compiled language.


 Most programmers are able to see that's very false, today.


 multi-platform. But today the Web is very important, and D can't be used
 in browers.


 I don't find it surprising that people here agree, when one is bashing

 language than D and that means it by definition has better portability to





language, and a good language.  But I consider them on the same level.   

has runtime reflection, D has compile-time reflection.  There's nothing I  

language's fault.


 I think that if D wants a chance to not die as many other C-inspired
 languages have done in past, Walter needs lot of perseverance and to
 keep slowly improving D for 8-10 more years. When D will be "good
 enough" maybe some people will start to use it. But the implementation
 of D2 is currently far from that point.


 D2 basically brought the number of supported libraries back to zero. It's
 almost like starting from scratch.


+1 dcollections :)

But on that note, most libraries in dsource are defunct anyways, and  
wouldn't compile on the latest D1.  Someone needs to clean that attic  
someday.

Also, D is able to use any C library with minimal effort.


 Jesse Phillips wrote:

 This is exactly how it should be marketed. It has the productivity of
 Python, other dynamic languages, with the performance and power of a
 natively compiled language.


 I keep wondering, what language has the best productivity? How is it
 possible that people here STILL think that a single language could solve
 all problems. Is Python the right choice when creating interactive
 browser games? Is it the right choice for iPhone? Is it good for writing
 filesystem drivers? Is it good for high performance computing (vs FORTRAN
 et al).


Bleh, this is really a personal choice I think.  D is my preference when  
given a choice.  But most of the time, I'm not given a choice...


 Juanjo Alvarez wrote:

 As a newcomer after one week learning and toying with D my productivity
 is about 70% of the one I have with Python after 8 years doing Python,
 and higher than the one I've with Java or C++.


 That's pretty awesome. You have maybe 0.001% of the libraries directly
 available, a buggy compiler, no 64-bit support, no formal spec etc. etc.
 And still you get about 70% of the productivity. And people say Python is
 maybe the most productive general purpose language out there. That's just
 incredible. My guess is, when D 2.0 is finally production ready, you're
 at least 100 times more productive than with Python. You can write 100000
 lines of code per day.


And you are still posting on this NG because...?

-Steve
Sep 28 2010
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
Steven Schveighoffer Wrote:


 On Tue, 28 Sep 2010 15:36:32 -0400, retard <re tard.com.invalid> wrote:


 That's pretty awesome. You have maybe 0.001% of the libraries directly
 available, a buggy compiler, no 64-bit support, no formal spec etc. etc.
 And still you get about 70% of the productivity. And people say Python is
 maybe the most productive general purpose language out there. That's just
 incredible. My guess is, when D 2.0 is finally production ready, you're
 at least 100 times more productive than with Python. You can write 100000
 lines of code per day.


 
 And you are still posting on this NG because...?
 
 -Steve


Obviously he is following D2 for when it becomes production ready and he can be
100 times more productive then he would be in Python. Maybe he was trying to be
sarcastic, but I've seen retard as one very critical of D with the desire for
it to realize its goals.

D has had many set backs. And has made great strides. I think the criticisms
brought to the NG are usually valid, though may not may not help to resolve
them. But when we start praising D it can be good to keep in mind the issues
that do exist; even if only a perception by those not using the language.
Sep 28 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Tue, 28 Sep 2010 16:20:27 -0400, Steven Schveighoffer wrote:


 And you are still posting on this NG because...?


The amount of religious stupidity never fails to impress me. I've never 
seen a community with this badly brainwashed zealots.
Sep 28 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/28/10 14:32 PDT, retard wrote:

 Tue, 28 Sep 2010 16:20:27 -0400, Steven Schveighoffer wrote:


 And you are still posting on this NG because...?


 The amount of religious stupidity never fails to impress me. I've never
 seen a community with this badly brainwashed zealots.


That only begs the question :o).

Andrei
Sep 28 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 28 Sep 2010 17:32:38 -0400, retard <re tard.com.invalid> wrote:


 Tue, 28 Sep 2010 16:20:27 -0400, Steven Schveighoffer wrote:


 And you are still posting on this NG because...?


 The amount of religious stupidity never fails to impress me. I've never
 seen a community with this badly brainwashed zealots.


You know, people who like D come to this newsgroup for suggestions,  
answers, and discussion... about D!

So you are surprised when people here post positive things about D?  You  
know, you are right.  We're all brainwashed, and I think you just saved us.

I heard there are some other newsgroups in the alt area that have been  
brainwashed into thinking sex is good.  I think you have the perfect  
skills to go set them straight.  Good luck!

-Steve
Sep 29 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
Tue, 28 Sep 2010 16:20:27 -0400, Steven Schveighoffer wrote:


 On Tue, 28 Sep 2010 15:36:32 -0400, retard <re tard.com.invalid> wrote:
 

 Tue, 28 Sep 2010 13:22:09 -0400, bearophile wrote:

 Jesse Phillips:


 This is exactly how it should be marketed. It has the productivity of
 Python, other dynamic languages, with the performance and power of a
 natively compiled language.


 Most programmers are able to see that's very false, today.


 multi-platform. But today the Web is very important, and D can't be
 used in browers.


 I don't find it surprising that people here agree, when one is bashing

 language than D and that means it by definition has better portability


 (silverlight/moonlight).


 




have access to inline assembler? Agreed, it doesn't provide many new high 
level features compared to D, but it doesn't have all the interfaces with 
raw metal. That makes it higher level language in my book. It's less 
dependent on the hardware platform.
Sep 28 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 28 Sep 2010 17:38:43 -0400, retard <re tard.com.invalid> wrote:


 Tue, 28 Sep 2010 16:20:27 -0400, Steven Schveighoffer wrote:


 On Tue, 28 Sep 2010 15:36:32 -0400, retard <re tard.com.invalid> wrote:


 Tue, 28 Sep 2010 13:22:09 -0400, bearophile wrote:

 Jesse Phillips:


 This is exactly how it should be marketed. It has the productivity of
 Python, other dynamic languages, with the performance and power of a
 natively compiled language.


 Most programmers are able to see that's very false, today.


 multi-platform. But today the Web is very important, and D can't be
 used in browers.


 I don't find it surprising that people here agree, when one is bashing

 language than D and that means it by definition has better portability


 (silverlight/moonlight).





 FWIW, I was talking about the language, not its implementation.


So was I.  Hence my dismissing the library argument because it's not the  
language's fault.



 have access to inline assembler? Agreed, it doesn't provide many new high
 level features compared to D, but it doesn't have all the interfaces with
 raw metal. That makes it higher level language in my book. It's less
 dependent on the hardware platform.



is at the same level even if it does provide inline assembler.  The simple  
fact is, you don't *have* to use low level features of D, you can stick to  

D without ever touching a pointer or inline assembler.

-Steve
Sep 29 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Wed, 29 Sep 2010 07:00:33 -0400, Steven Schveighoffer wrote:


 On Tue, 28 Sep 2010 17:38:43 -0400, retard <re tard.com.invalid> wrote:
 

 Tue, 28 Sep 2010 16:20:27 -0400, Steven Schveighoffer wrote:

 have access to inline assembler? Agreed, it doesn't provide many new
 high level features compared to D, but it doesn't have all the
 interfaces with raw metal. That makes it higher level language in my
 book. It's less dependent on the hardware platform.


 

 D is at the same level even if it does provide inline assembler.  The
 simple fact is, you don't *have* to use low level features of D, you can

 programs in D without ever touching a pointer or inline assembler.


Being a higher level language isn't some positive optimum. I guess part 
of the reason you disagree is that you take everything personally if 
someone is critical towards D. My personal opinion is that D is in many 

lower level language. You can find one definition here:

http://en.wikipedia.org/wiki/High-level_programming_language


 You know, people who like D come to this newsgroup for suggestions,
 answers, and discussion... about D!
 
 So you are surprised when people here post positive things about D?  You
 know, you are right.  We're all brainwashed, and I think you just saved
 us.


The logic often goes:

if (post.sender == "retard" && post.criticizes("D")) poster.sender.isWrong 
= true;

No matter what I say, I'm always wrong. Even quotes from encyclopedias or 
research papers are more wrong when I share them.
Sep 29 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 29 Sep 2010 07:22:08 -0400, retard <re tard.com.invalid> wrote:


 Wed, 29 Sep 2010 07:00:33 -0400, Steven Schveighoffer wrote:


 On Tue, 28 Sep 2010 17:38:43 -0400, retard <re tard.com.invalid> wrote:


 Tue, 28 Sep 2010 16:20:27 -0400, Steven Schveighoffer wrote:

 have access to inline assembler? Agreed, it doesn't provide many new
 high level features compared to D, but it doesn't have all the
 interfaces with raw metal. That makes it higher level language in my
 book. It's less dependent on the hardware platform.



 D is at the same level even if it does provide inline assembler.  The
 simple fact is, you don't *have* to use low level features of D, you can

 programs in D without ever touching a pointer or inline assembler.


 Being a higher level language isn't some positive optimum. I guess part
 of the reason you disagree is that you take everything personally if
 someone is critical towards D.



both, I feel both are at the same level -- I can accomplish (with proper  
library support) the same things in both with about the same amount of  
effort (probably less effort with D, but this statement is probably the  

which managed the initialization and testing of about 400 concurrent PCs  
for production, and it worked pretty darn well.  So I'm not talking out of  
my ass here.

I'm also not asserting that high-level is better than low-level.  People  
can do ridiculous things with assembly that can beat the pants off of a  

the same in terms of level.


 My personal opinion is that D is in many

 lower level language. You can find one definition here:

 http://en.wikipedia.org/wiki/High-level_programming_language


 From that article:

"The terms high-level and low-level are inherently relative. Some decades  
ago, the C language, and similar languages, were most often considered  
"high-level", as it supported concepts such as expression evaluation,  
parameterised recursive functions, and data types and structures, while  
assembly language was considered "low-level". Many programmers today might  
refer to C as low-level, as it lacks a large runtime-system (no garbage  
collection etc.), basically supports only scalar operations, and provides  
direct memory addressing. It therefore readily blends with assembly  
language and the machine level of CPUs and microcontrollers."

D does not lack a large runtime system and garbage collection.  It has  
pretty good high-level constructs, and pretty low level constructs as well.

One thing not really discussed in that wikipedia article is what if a  
language has *both* the lowest level constructs and the highest level  
constructs, how is it defined?

I guess you have to define the highs or lows as overriding the other, and  
I feel the high-level constructs are more what define the language than  
the low level, since the high level constructs are what the average  
developer uses.  You may interpret it differently, so I can respect that.

If SafeD is ever properly implemented, I'm guessing it would be considered  
a high-level language, even by you.


 You know, people who like D come to this newsgroup for suggestions,
 answers, and discussion... about D!

 So you are surprised when people here post positive things about D?  You
 know, you are right.  We're all brainwashed, and I think you just saved
 us.


 The logic often goes:

 if (post.sender == "retard" && post.criticizes("D"))  
 poster.sender.isWrong
 = true;


You missed some booleans there: post.contains("rant about brainwashing")  
&& post.contains("comments about how the OP is an idiot")

Those fields are naturally not going to elicit a positive response.  Look  
at bearophile, every other word out of his keyboard is about Python, yet  
nobody gets pissed off and defensive when he compares D unfavorably to  
Python.


 No matter what I say, I'm always wrong. Even quotes from encyclopedias or
 research papers are more wrong when I share them.


I don't think it's your knowledge or lack thereof, it's your delivery.   
Your verbiage tends to put people on the defensive.

-Steve
Sep 29 2010
parent reply Sclytrack <sclytrack fake.com> writes:
 nobody gets pissed off and defensive when he compares D unfavorably to
 Python.

 No matter what I say, I'm always wrong. Even quotes from encyclopedias or
 research papers are more wrong when I share them.





Compile-time custom annotation might be hard to implement. Do we really need it?
Going from compile-time to runtime might not be obvious too.


class MarkThis : CustomAnnotation
{

}

class A
{
    MarkThis("test",10)
   void test()
   {
          //MarkThis obj = (MarkThis) getCustomAnnotation( ... ); //at runtime
          //even invoke methods of the annotation.
   }
}

Method test <--linked to-->  annotation MarkThis and parameters ("test", 10)
Sep 29 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, September 29, 2010 05:39:25 Sclytrack wrote:

 nobody gets pissed off and defensive when he compares D unfavorably to
 Python.
 

 No matter what I say, I'm always wrong. Even quotes from encyclopedias
 or research papers are more wrong when I share them.




 
 Compile-time custom annotation might be hard to implement. Do we really
 need it? Going from compile-time to runtime might not be obvious too.
 
 
 class MarkThis : CustomAnnotation
 {
 
 }
 
 class A
 {
     MarkThis("test",10)
    void test()
    {
           //MarkThis obj = (MarkThis) getCustomAnnotation( ... ); //at
 runtime //even invoke methods of the annotation.
    }
 }
 
 Method test <--linked to-->  annotation MarkThis and parameters ("test",
 10)


Custom annotations can be very powerful and highly useful. Now, lacking runtime 
reflection, exactly how useful they'd be would differ from languages such as
Java 

which 
would be in D at some point - and since adding them would likely be purely 
additive rather than having to make breaking changes, they could be added at 
pretty much any point in D's development. However, I do think that D would do a 
lot better to have dmd and Phobos progress quite a bit more before even 
considering adding such a feature.

- Jonathan M Davis
Sep 29 2010
prev sibling parent reply Pelle <pelle.mansson gmail.com> writes:
On 09/29/2010 01:22 PM, retard wrote:

 Wed, 29 Sep 2010 07:00:33 -0400, Steven Schveighoffer wrote:


 On Tue, 28 Sep 2010 17:38:43 -0400, retard<re tard.com.invalid>  wrote:


 Tue, 28 Sep 2010 16:20:27 -0400, Steven Schveighoffer wrote:

 have access to inline assembler? Agreed, it doesn't provide many new
 high level features compared to D, but it doesn't have all the
 interfaces with raw metal. That makes it higher level language in my
 book. It's less dependent on the hardware platform.



 D is at the same level even if it does provide inline assembler.  The
 simple fact is, you don't *have* to use low level features of D, you can

 programs in D without ever touching a pointer or inline assembler.


 Being a higher level language isn't some positive optimum. I guess part
 of the reason you disagree is that you take everything personally if
 someone is critical towards D. My personal opinion is that D is in many

 lower level language. You can find one definition here:

 http://en.wikipedia.org/wiki/High-level_programming_language


Let me provide silly pictures. Ascii, of course.


--- ---  <-- high level
  |   |
  |   |
  |   |
  |  ---
  |
---      <-- low level

D providing lower level features may make it a lower level language, but 
it also might not. :-)

DISCLAIMER: I am wrong.


 You know, people who like D come to this newsgroup for suggestions,
 answers, and discussion... about D!

 So you are surprised when people here post positive things about D?  You
 know, you are right.  We're all brainwashed, and I think you just saved
 us.


 The logic often goes:

 if (post.sender == "retard"&&  post.criticizes("D")) poster.sender.isWrong
 = true;

 No matter what I say, I'm always wrong. Even quotes from encyclopedias or
 research papers are more wrong when I share them.


I, for one, think that treating you offensively is silly and wrong. 
Critizising D is a good thing to do.
Sep 29 2010
parent reply retard <re tard.com.invalid> writes:
Wed, 29 Sep 2010 15:17:17 +0200, Pelle wrote:


 On 09/29/2010 01:22 PM, retard wrote:

 Wed, 29 Sep 2010 07:00:33 -0400, Steven Schveighoffer wrote:


 On Tue, 28 Sep 2010 17:38:43 -0400, retard<re tard.com.invalid> 
 wrote:



 have access to inline assembler? Agreed, it doesn't provide many new
 high level features compared to D, but it doesn't have all the
 interfaces with raw metal. That makes it higher level language in my
 book. It's less dependent on the hardware platform.



 IMO D is at the same level even if it does provide inline assembler. 
 The simple fact is, you don't *have* to use low level features of D,

 full useful programs in D without ever touching a pointer or inline
 assembler.


 Being a higher level language isn't some positive optimum. I guess part
 of the reason you disagree is that you take everything personally if
 someone is critical towards D. My personal opinion is that D is in many

 lower level language. You can find one definition here:

 http://en.wikipedia.org/wiki/High-level_programming_language


 Let me provide silly pictures. Ascii, of course.
 

 --- ---  <-- high level
   |   |
   |   |
   |   |
   |  ---
   |
 ---      <-- low level
 
 D providing lower level features may make it a lower level language, but
 it also might not. :-)
 
 DISCLAIMER: I am wrong.


You're not wrong. I saw your point and liked the fact that you didn't 
start arguing pointlessly. The picture also illustrates what I originally 
had in mind. These terms aren't well defined which makes this kind of 
discussion rather unfruitful in the first place.
Sep 29 2010
parent reply Sclytrack <sclytrack sleepy.com> writes:

 --- ---  <-- high level
   |   |
   |   |
   |   |
   |  ---
   |
 ---      <-- low level







            ---
             |  <---------gc
       Delphi|
        ---  |
         |   |  <---------custom attributes, reflection, generic collections
     D   |   |
    ---  |   |
     |<--|---|------------gc, better templates, experimental purity
C++  |   |   |
---  |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |   |
 |   |   |  ---
 |   |   |   <-------------Assembler
--- --- ---

Delphi might make an excellent RAD
and system programming language.
Sep 29 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, September 29, 2010 07:59:25 Sclytrack wrote:


 
 --- ---  <-- high level
 
   |  ---
 
 ---      <-- low level




 

             ---
 
              |  <---------gc
 
        Delphi|
         ---  |
 
          |   |  <---------custom attributes, reflection, generic
          |   |  collections
 
      D   |   |
     ---  |   |
 
      |<--|---|------------gc, better templates, experimental purity
 
 C++  |   |   |
 ---  |   |   |
 
  |   |   |  ---
  |   |   |  
  |   |   |   <-------------Assembler
 
 --- --- ---
 
 Delphi might make an excellent RAD
 and system programming language.



doesn't 

Delphi. Take reflection, for instance. D has compile-time reflection, which 
combined with templates, can be extremely powerful, but it lacks runtime 

the 
other hand, has runtime reflection, but it lacks both templates and
compile-time 
reflection (though lacking templates, I'm not sure that compile-time reflection 
would do it much good). It's not an obvious case of one being higher level or 
superior to the other. It's simply a different set of abilities, and each of
them 
is better in a particular area but worse in another.

Personally, I tend to think about a language being high level if it is capable 
of high-level abstractions and doesn't force you to use the low level stuff
like 
pointers. So, whether a language _has_ the low level stuff is irrelevant to my 
way of thinking. It's whether it has the high level stuff and doesn't force you 
to use low level stuff. D has the high level stuff (though obviously there are 
some types of high level features that it lacks that other languages lack, just 
like many of those languages lack some of the high level features that D has) 
and doesn't force you to use its low level stuff, so it's a high level
language. 
That's pretty much how I look at it. The fact that it has high level 
capabalities makes it high level even if it has low level capabilities. But 
since even the terms high and low level are pretty subjective, it's not like 
you're ever going to get a definitive scale or definition on the matter.

- Jonathan M Davis
Sep 29 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:


 D is at the same level even if it does provide inline assembler.  The 
 simple fact is, you don't *have* to use low level features of D, you can 

 programs in D without ever touching a pointer or inline assembler.




1. direct C interface
2. inline assembler
3. pointers

Higher level:

1. metaprogramming
2. support for purity, const, immutable, shared
3. CTFE
Sep 29 2010
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:

 Steven Schveighoffer wrote:


 IMO D is at the same level even if it does provide inline assembler.  
 The simple fact is, you don't *have* to use low level features of D, 

 full useful programs in D without ever touching a pointer or inline 
 assembler.


 

 
 1. direct C interface
 2. inline assembler
 3. pointers
 
 Higher level:
 
 1. metaprogramming
 2. support for purity, const, immutable, shared
 3. CTFE


It's worth noting that the lowest level language is a list of hex bytes.
Asm only gets to that level by the 'db' pseudo-instruction; there are 
several constructs which it doesn't support natively.
Interestingly, one of those constructs is float.infinity, which D _does_ 
support natively.
Oct 01 2010
parent Justin Johansson <no spam.com> writes:
On 1/10/2010 9:19 PM, Don wrote:

 It's worth noting that the lowest level language is a list of hex bytes.


Ur no (pun intended).  CGAT is the basic alphabet, implemented on
top of RNA .

Some interesting links:
http://en.wikipedia.org/wiki/Proto-Human_language
http://www.impredicative.com/ur/
http://www.ncbi.nlm.nih.gov/pubmed/14631359

Cheers
Justin Johansson
Oct 01 2010
prev sibling next sibling parent Juanjo Alvarez <fake fakeemail.com> writes:
On Tue, 28 Sep 2010 19:36:32 +0000 (UTC), retard 
<re tard.com.invalid> wrote:

 That's pretty awesome. You have maybe 0.001% of the libraries 


directly 

I have a lot more libraries in D than in Python. In C. 


 [bla bla bla, bad sarcasms, bla bla bla]
 at least 100 times more productive than with Python. You can write 


100000 

 lines of code per day.


Productivity is not measured by lines of code written. Sometimes a 
better measure is lines of code removed.
Sep 28 2010
prev sibling parent Juanjo Alvarez <fake fakeemail.com> writes:
On Tue, 28 Sep 2010 19:36:32 +0000 (UTC), retard 
<re tard.com.invalid> wrote:


 language than D and that means it by definition has better 


portability to 




major

LOL.  I've never been able to run any mildly complex application in 
Mono. And I've tried.
Sep 28 2010
prev sibling parent piotrek <starpit tlen.pl> writes:
On Tue, 28 Sep 2010 13:22:09 -0400, bearophile wrote:


 Jesse Phillips:
 

 This is exactly how it should be marketed. It has the productivity of
 Python, other dynamic languages, with the performance and power of a
 natively compiled language.


 
 Most programmers are able to see that's very false, today.
 

 multi-platform. But today the Web is very important, and D can't be used
 in browers.
 
 I think that if D wants a chance to not die as many other C-inspired
 languages have done in past, Walter needs lot of perseverance and to
 keep slowly improving D for 8-10 more years. When D will be "good
 enough" maybe some people will start to use it. But the implementation
 of D2 is currently far from that point.
 
 Bye,
 bearophile


Hi,

The majority of software developers do what they are told to do. They 
can't make any independent decision regarding technology and methodology 
they use.


anything around. But unfortunately there's no commercial support behind 
it. 




To me, D solves almost every software development problem. How?
D makes almost all other programming languages not needed. I mean I DON'T 
what to learn another language to query database or write a simple script 
or transform xml to html. 

The problem with C++ (and C) which blocks it from achieve this goal is 
that it's ugly and not convenient in so many places. That's why people 
tried to do it easier and started to produce auxiliary technologies. With 
D they aren't necessary. But of course we need good library and IDE. If 
it was me I would fork Qt Creator and make it work with D. Unfortunately 
plenty of platforms slows down D development. The work is divided into 
too many targets. D deserves a dedicated modern processor architecture 
and a well designed OS ;)

Cheers
Piotrek
Sep 28 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-09-17 03:38, sybrandy wrote:

 On 09/16/2010 07:04 AM, Simen Kjaeraas wrote:

 Here's a draft of something I'd like to see. I like having the ten


 == The D Manifesto ==

 0. Pragmatism is king.

 1. Safe before all, fast before the rest.

 2. High level where possible, low level where necessary.

 3. If it looks like C, it works like C or never compiles.

 4. Easy things easy, difficult things possible.

 5. Thou shalt not need to write boilerplate code.

 6. Sugar is good for you, as is salt. In moderation.

 7. Too much power is almost enough.

 8. User-defined types should not be treated differently.

 9. What the compiler knows, the programmer can query.

 10. What works at run-time, should work at compile-time.




 These are runner-ups that I like, but don't feel are as important as
 those above, says things that are already said, or just don't 'feel'
 right.

 11. Avoid magic.

 12. The tool does not pick you - you pick the tool.

 13. The straight path is safe and correct.

 14. The crooked path is passable.

 15. We're consenting adults, not suicidal maniacs.

 --
 Simen


 To go along with this, perhaps "Concurrency should be easy and safe"?

 Casey


Concurrency is currently far from easy.

-- 
/Jacob Carlborg
Sep 17 2010
next sibling parent sybrandy <sybrandy gmail.com> writes:
 Concurrency is currently far from easy.


Perhaps, but with D providing a message-passing API, we're certainly on 
our way to making it much easier.  I tried Perl threading a few years 
ago and settled on using fork for what I needed as it was much easier. 
I later learned Erlang and went "Wow, this is really easy!"*  Did some 
threading in D with some success, but seeing I can now do things almost 
as easy as Erlang, that just makes me happy.

Granted, this doesn't solve things like being able to perform an 
operation on all 2048 elements in an array at the same time, but it's a 
step in the right direction for a lot of applications, like server 
development.

Casey

* Before you go too far, yes, I do realize that there are still ways to 
shoot yourself in the foot with message passing.  Erlang is grant in 
keeping you from doing so, but in either the documentation or in a 
tutorial elsewhere, the Erlang sages have warned us that the path may be 
treacherous.  I can only hope that Gandalf is with me when the balrog 
appears...
Sep 17 2010
prev sibling parent Jay Byrd <JayByrd rebels.com> writes:
On Fri, 17 Sep 2010 15:08:07 +0200, Jacob Carlborg wrote:


 On 2010-09-17 03:38, sybrandy wrote:

 On 09/16/2010 07:04 AM, Simen Kjaeraas wrote:

 Here's a draft of something I'd like to see. I like having the ten


 == The D Manifesto ==

 0. Pragmatism is king.

 1. Safe before all, fast before the rest.

 2. High level where possible, low level where necessary.

 3. If it looks like C, it works like C or never compiles.

 4. Easy things easy, difficult things possible.

 5. Thou shalt not need to write boilerplate code.

 6. Sugar is good for you, as is salt. In moderation.

 7. Too much power is almost enough.

 8. User-defined types should not be treated differently.

 9. What the compiler knows, the programmer can query.

 10. What works at run-time, should work at compile-time.




 These are runner-ups that I like, but don't feel are as important as
 those above, says things that are already said, or just don't 'feel'
 right.

 11. Avoid magic.

 12. The tool does not pick you - you pick the tool.

 13. The straight path is safe and correct.

 14. The crooked path is passable.

 15. We're consenting adults, not suicidal maniacs.

 --
 Simen


 To go along with this, perhaps "Concurrency should be easy and safe"?

 Casey


 
 Concurrency is currently far from easy.


Non sequitur.
Sep 20 2010
prev sibling parent reply JMRyan <nospam nospam.com> writes:
Simen Kjaeraas <simen.kjaras gmail.com> wrote in news:i6stke$o0v$1
 digitalmars.com:


 Here's a draft of something I'd like to see. I like having the ten

 
                           == The D Manifesto ==
 


Please don't call it a manifesto.  A statement of design goals or design 
principles says, "This is what we want to do."  A manifesto says, "This is 
what everybody should want to do.  This is exactly why the Date/Darwen 
manifesto choose that word.  D is a good language.  (I am forced to use 
Visual dBase in my day job, so I find D to be a really, Really, REALLY good 
language).  There are other good languages out there. There is no reason 
that all systems/general purpose languages should have the same design 
goals or priorities.  The word "manifesto" suggests we think otherwise. C++ 
programmers already have an "if it is not The Next Big Thing in Programming 
Languages, then why bother" attitude toward D.  We don't want them to think 
of us as kooky zealots was well.
Sep 18 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
JMRyan <nospam nospam.com> wrote:


 Simen Kjaeraas <simen.kjaras gmail.com> wrote in news:i6stke$o0v$1
  digitalmars.com:


 Here's a draft of something I'd like to see. I like having the ten


                           =3D=3D The D Manifesto =3D=3D


 Please don't call it a manifesto.  A statement of design goals or desi=


gn

 principles says, "This is what we want to do."  A manifesto says, "Thi=


s  =


 is
 what everybody should want to do.


We'll interpret it as 'what everyone who wants to make D should want to
do', then. :p

Now, checking my dictionaries, I have found no support for your
definition of manifesto:

man=C2=B7i=C2=B7fes=C2=B7to (man-uh-fes-toh)
=E2=80=93noun, plural -toes.
a public declaration of intentions, opinions, objectives, or motives,
as one issued by a government, sovereign, or organization.

1644, from Italian 'manifesto', Latin 'manifestum' - clear, evident.
"Public declaration explaining past actions and announcing the motive
for forthcoming ones,"


This does not seem too far off the mark for what the above guidelines
are, and all other definitions I could find agreed with the above.



-- =

Simen
Sep 18 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 18 September 2010 23:47:09 Simen kjaeraas wrote:

 JMRyan <nospam nospam.com> wrote:

 Simen Kjaeraas <simen.kjaras gmail.com> wrote in news:i6stke$o0v$1
=20
  digitalmars.com:

 Here's a draft of something I'd like to see. I like having the ten

=20
                           =3D=3D The D Manifesto =3D=3D


=20
 Please don't call it a manifesto.  A statement of design goals or design
 principles says, "This is what we want to do."  A manifesto says, "This
 is
 what everybody should want to do.


=20
 We'll interpret it as 'what everyone who wants to make D should want to
 do', then. :p
=20
 Now, checking my dictionaries, I have found no support for your
 definition of manifesto:
=20
 man=C2=B7i=C2=B7fes=C2=B7to (man-uh-fes-toh)
 =E2=80=93noun, plural -toes.
 a public declaration of intentions, opinions, objectives, or motives,
 as one issued by a government, sovereign, or organization.
=20
 1644, from Italian 'manifesto', Latin 'manifestum' - clear, evident.
 "Public declaration explaining past actions and announcing the motive
 for forthcoming ones,"
=20
=20
 This does not seem too far off the mark for what the above guidelines
 are, and all other definitions I could find agreed with the above.


While manifesto may be technically correct, I tend to concur with JMRyan. I=
t=20
seems to me to be far to ideological/political a term and potentially impli=
es=20
that we're trying to impose it on others. All we're looking to do is to do =
what=20
the subject says: give a summary of what the principles are behind D's desi=
gn.=20
We're looking to make clear what D is aiming to do, not push anything on an=
yone.=20
So, while manifesto make be technically correct, common usage tends to make=
 it=20
more forceful, so I concur that it would be a poor term  to use.

=2D Jonathan M Davis
Sep 19 2010
prev sibling parent reply Jay Byrd <JayByrd rebels.com> writes:
On Sun, 19 Sep 2010 06:33:28 +0000, JMRyan wrote:


 Simen Kjaeraas <simen.kjaras gmail.com> wrote in news:i6stke$o0v$1
  digitalmars.com:
 

 Here's a draft of something I'd like to see. I like having the ten

 
                           == The D Manifesto ==
 
 


 Please don't call it a manifesto.  A statement of design goals or design
 principles says, "This is what we want to do."  A manifesto says, "This
 is what everybody should want to do.


You're simply wrong. (Not just "technically", Jonathan.)

-- JB


 This is exactly why the
 Date/Darwen manifesto choose that word.  D is a good language.  (I am
 forced to use Visual dBase in my day job, so I find D to be a really,
 Really, REALLY good language).  There are other good languages out
 there. There is no reason that all systems/general purpose languages
 should have the same design goals or priorities.  The word "manifesto"
 suggests we think otherwise. C++ programmers already have an "if it is
 not The Next Big Thing in Programming Languages, then why bother"
 attitude toward D.  We don't want them to think of us as kooky zealots
 was well.
Sep 20 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, September 20, 2010 14:22:17 Jay Byrd wrote:

 On Sun, 19 Sep 2010 06:33:28 +0000, JMRyan wrote:

 Simen Kjaeraas <simen.kjaras gmail.com> wrote in news:i6stke$o0v$1
 
  digitalmars.com:

 Here's a draft of something I'd like to see. I like having the ten

 
                           == The D Manifesto ==


 
 Please don't call it a manifesto.  A statement of design goals or design
 principles says, "This is what we want to do."  A manifesto says, "This
 is what everybody should want to do.


 
 You're simply wrong. (Not just "technically", Jonathan.)
 
 -- JB


The dictionary definition and the common usage of a word are not necessarily
the 
same. It's not uncommon that a particular word is seen to have certain 
implications to it that are not part of the dictionary definition simply
because 
of when and where people choose to use the word. So, people take the word to 
have extra meaning beyond what it has per its dictionary definiton. Manifesto
is 
such a word.

- Jonathan M Davis
Sep 20 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design 
 principles. This was after I'd mentioned the "no function hijacking" 
 stance.
 
 I think it would be a great idea if the up-and-coming 
 www.d-programming-language.org contained such a document.


I agree, but let's be careful not to drift into trite platitudes. For example, 
Ted Neward pointed out to me that *every* programming language bills itself as 
productivity enhancing. A manifesto should list things that set D apart from
the 
goals of other languages, and shouldn't just repeat things that every language 
claims to do.
Sep 17 2010
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 17 September 2010 00:02:36 Walter Bright wrote:

 Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.
 
 I think it would be a great idea if the up-and-coming
 www.d-programming-language.org contained such a document.


 
 I agree, but let's be careful not to drift into trite platitudes. For
 example, Ted Neward pointed out to me that *every* programming language
 bills itself as productivity enhancing. A manifesto should list things
 that set D apart from the goals of other languages, and shouldn't just
 repeat things that every language claims to do.


And I was _so_ thinking of suggesting "write programs." ;)

Excellent point.

- Jonathan M Davis
Sep 17 2010
parent reply F. Almeida <francisco.m.almeida gmail.com> writes:
I would like such a manifesto to emphasize the following aspects that
together, make D unique IMO:

* Programs may be as high or as low level as the programmer chooses.
* No single style is imposed on the programmer.
* The memory can be managed automatically or manually.
Sep 17 2010
parent #ponce <contact gamCOOKIESesfrommars.fr> writes:
 I would like such a manifesto to emphasize the following aspects that
 together, make D unique IMO:
 
 * Programs may be as high or as low level as the programmer chooses.
 * No single style is imposed on the programmer.
 * The memory can be managed automatically or manually.


Pragmatism not religion.
Empower not mutilate.
Safety not patronising.
Sep 17 2010
prev sibling next sibling parent reply Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
On 16/09/2010 5:58 a.m., Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.


there is no one, true, only to be used, library. D supports diversity.
Sep 17 2010
next sibling parent reply Justin Johansson <no spam.com> writes:
On 17/09/2010 6:48 PM, Nick B wrote:

 On 16/09/2010 5:58 a.m., Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.


 there is no one, true, only to be used, library. D supports diversity.


Using Walter's words this is a "trite platitude".

Comments such as these are akin to saying "D is carbon neutral"
without a supporting argument.

Can you please support your argument with more substance, i.e.
more sausage and less sizzle. :-)
Sep 17 2010
parent reply Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
On 18/09/2010 12:28 a.m., Justin Johansson wrote:

 On 17/09/2010 6:48 PM, Nick B wrote:

 On 16/09/2010 5:58 a.m., Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.


 there is no one, true, only to be used, library. D supports diversity.


 Using Walter's words this is a "trite platitude".

 Comments such as these are akin to saying "D is carbon neutral"
 without a supporting argument.

 Can you please support your argument with more substance, i.e.
 more sausage and less sizzle. :-)


Is the fact there are two libraries, and not one, or twenty, a strength, 
and not a weakness, of the language and the D community.

For example, see this list of (approx 100) C++ libraries: 


I think that this large number of libraries, just leads to fragmentation 
of effort by the C++ community.

Nick B
Sep 17 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 17 September 2010 19:20:20 Nick B wrote:

 On 18/09/2010 12:28 a.m., Justin Johansson wrote:

 On 17/09/2010 6:48 PM, Nick B wrote:

 On 16/09/2010 5:58 a.m., Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.


 
 there is no one, true, only to be used, library. D supports diversity.


 
 Using Walter's words this is a "trite platitude".
 
 Comments such as these are akin to saying "D is carbon neutral"
 without a supporting argument.
 
 Can you please support your argument with more substance, i.e.
 more sausage and less sizzle. :-)


 
 Is the fact there are two libraries, and not one, or twenty, a strength,
 and not a weakness, of the language and the D community.
 
 For example, see this list of (approx 100) C++ libraries:

 
 I think that this large number of libraries, just leads to fragmentation
 of effort by the C++ community.
 
 Nick B


The fact that D has so few libraries is almost certainly temporary (not to 
mention, if you look at dsource, there are quite a few, though most of them are 
essentially dead). Even Java, which has an extensive standard library, has all 
kinds of 3rd party libraries floating around. Certainly, C++ suffers in part 
because its standard library is so lacking in functionality, but even if it
were 
fantastic, there would still be plenty of C++ libraries floating around. Any 
language which is used by a lot of people will eventually have a lot of 
libraries unless the language itself somehow restricts it (which none do to my 
knowledge).

There's nothing inherent in the D language which would restrict the number of 
libraries. Whether there is one library or 5 million has nothing to do with the 
language itself, so I really don't think that it makes sense to talk about the 
number of libraries that D has being part of the philosophy behind it. And 
honestly, while there aren't 100+ D libraries floating around, the division in 
the community over Phobos vs Tango gives the impression that one of the 
philosophies of D is to have one library.

- Jonathan M Davis
Sep 17 2010
parent retard <re tard.com.invalid> writes:
Fri, 17 Sep 2010 19:31:35 -0700, Jonathan M Davis wrote:


 On Friday 17 September 2010 19:20:20 Nick B wrote:

 On 18/09/2010 12:28 a.m., Justin Johansson wrote:

 On 17/09/2010 6:48 PM, Nick B wrote:

 On 16/09/2010 5:58 a.m., Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's
 design principles. This was after I'd mentioned the "no function
 hijacking" stance.


 
 there is no one, true, only to be used, library. D supports
 diversity.


 
 Using Walter's words this is a "trite platitude".
 
 Comments such as these are akin to saying "D is carbon neutral"
 without a supporting argument.
 
 Can you please support your argument with more substance, i.e. more
 sausage and less sizzle. :-)


 
 Is the fact there are two libraries, and not one, or twenty, a
 strength, and not a weakness, of the language and the D community.
 
 For example, see this list of (approx 100) C++ libraries:

 
 I think that this large number of libraries, just leads to
 fragmentation of effort by the C++ community.
 
 Nick B


 
 The fact that D has so few libraries is almost certainly temporary (not
 to mention, if you look at dsource, there are quite a few, though most
 of them are essentially dead). Even Java, which has an extensive
 standard library, has all kinds of 3rd party libraries floating around.
 Certainly, C++ suffers in part because its standard library is so
 lacking in functionality, but even if it were fantastic, there would
 still be plenty of C++ libraries floating around. Any language which is
 used by a lot of people will eventually have a lot of libraries unless
 the language itself somehow restricts it (which none do to my
 knowledge).


Some people value the lack of libraries quite high. In fact, if you take 
a brief look at fresh new languages like Rust, there are lots of 
motivated individuals working on the same problems that have already been 
solved in many existing language communities.

Then, take another look at this newsgroup, 10 years ago. Not many of 
those who used to use D back then are here now. Even the Tango developers 
have disappeared. We soon hear about the TDPL statistics. I'm sure a 
manifesto would make the general goals clearer, but the sad fact is that 
D has already lost some previously important key persons because the 
competition is quite intense.
Sep 17 2010
prev sibling parent Jay Byrd <JayByrd rebels.com> writes:
On Sat, 18 Sep 2010 14:20:20 +1200, Nick B wrote:


 On 18/09/2010 12:28 a.m., Justin Johansson wrote:

 On 17/09/2010 6:48 PM, Nick B wrote:

 On 16/09/2010 5:58 a.m., Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's
 design principles. This was after I'd mentioned the "no function
 hijacking" stance.


 there is no one, true, only to be used, library. D supports diversity.


 Using Walter's words this is a "trite platitude".

 Comments such as these are akin to saying "D is carbon neutral" without
 a supporting argument.

 Can you please support your argument with more substance, i.e. more
 sausage and less sizzle. :-)


 Is the fact there are two libraries, and not one, or twenty, a strength,
 and not a weakness, of the language and the D community.
 
 For example, see this list of (approx 100) C++ libraries:

 
 I think that this large number of libraries, just leads to fragmentation
 of effort by the C++ community.
 
 Nick B


I gather that you are quite new to programming. Check /usr/lib on any 
linux system -- or check CPAN. Libraries are rife, and for good reason. 
And this has nothing whatsoever to do with Phobos vs. Tango, which are 
far from the only libraries for D -- their significance is that they are 
*core* libraries, akin to libc in C.
Sep 20 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
Fri, 17 Sep 2010 21:18:04 +1200, Nick B wrote:


 On 16/09/2010 5:58 a.m., Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.


 there is no one, true, only to be used, library. D supports diversity.


Did I sense a bit of irony there?
Sep 17 2010
parent Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
On 18/09/2010 12:46 a.m., retard wrote:

 Fri, 17 Sep 2010 21:18:04 +1200, Nick B wrote:


 On 16/09/2010 5:58 a.m., Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.


 there is no one, true, only to be used, library. D supports diversity.


 Did I sense a bit of irony there?


No.
Sep 17 2010
prev sibling next sibling parent BLS <windevguy hotmail.de> writes:
On 15/09/2010 19:58, Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles.


to reduce it to the max.
The AnDrei design principles ;]   no, just kidding.

Seriously
I wish we could use D2 for our dot net development tasks. Guess we could 
save easily 30-40 percent of time just by using DBC, class invariants 
and /especially/ scope(exit).

Despite that, D keeps the spirit of ALGOL alive, which is nice 
especially for programming enthusiasts coming from the Wirth side of life.
my 2 euro cents.
Bjoern
Sep 17 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:


 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking" stance.
 
 I think it would be a great idea if the up-and-coming
 www.d-programming-language.org contained such a document.
 
 Ideas for what it could contain? I know we discussed this once in the
 past, but couldn't find the discussion.
 
 
 Andrei


To me some of the most distinguishing aspects of D are:


like python

- focus on early binding: this quote from David Griers is fitting: "Never put 
off until run time what you can do at compile time." But also related is the 
tendency to choose for a rich set of features, binding at 'language design time'

- support a diversity of programming styles (like C++, python) and attempt to 
integrate them

- support for features that help, and avoid designs that complicate maintenance 
of large programs

- take advantage of existing C knowledge and codebase

- enable the programmer to make his own tradeoff between performance and other 
quality criteria: this is true of many languages, but in D there is a much
wider 
space to choose from.
Sep 18 2010
parent reply Justin Johansson <no spam.com> writes:
On 19/09/2010 2:59 AM, Lutger wrote:

 To me some of the most distinguishing aspects of D are:


 like python

 - focus on early binding: this quote from David Griers is fitting: "Never put
 off until run time what you can do at compile time." But also related is the
 tendency to choose for a rich set of features, binding at 'language design
time'

 - support a diversity of programming styles (like C++, python) and attempt to
 integrate them

 - support for features that help, and avoid designs that complicate maintenance
 of large programs

 - take advantage of existing C knowledge and codebase

 - enable the programmer to make his own tradeoff between performance and other
 quality criteria: this is true of many languages, but in D there is a much
wider
 space to choose from.


I think the salient point that all miss is that D does not
expand beyond the classical OO paradigm in any meaningful way.

When all you have is a hammer, everything looks like a nail.

When all you have is classical OO, everything looks like it
can be modeled with inheritance by addition (rather than
inheritance by restriction for example) or an interface
(rather than a trait for example also).

There is no need, or significant consumer demand, to reinvent
another classical OO language in 2010.  To make any inroad,
a new language in these times needs to leverage upon some of
the lesser well known yet powerful idioms of PLs that allow
for extensible type systems.

Cheers
Justin Johansson
Sep 19 2010
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Justin Johansson wrote:


 On 19/09/2010 2:59 AM, Lutger wrote:

 To me some of the most distinguishing aspects of D are:


 like python

 - focus on early binding: this quote from David Griers is fitting: "Never put
 off until run time what you can do at compile time." But also related is the
 tendency to choose for a rich set of features, binding at 'language design
 time'

 - support a diversity of programming styles (like C++, python) and attempt to
 integrate them

 - support for features that help, and avoid designs that complicate
 maintenance of large programs

 - take advantage of existing C knowledge and codebase

 - enable the programmer to make his own tradeoff between performance and
 other quality criteria: this is true of many languages, but in D there is a
 much wider space to choose from.


 
 I think the salient point that all miss is that D does not
 expand beyond the classical OO paradigm in any meaningful way.


I don't understand this statement, there are quite a few things in D that 
support a different style of programming than OOP, such as: 
- closures for higher-order programming
- pointers, systems programming features
- templates
- pure, transitive const and immutable

Do you think this is not meaningful? Or do you mean that what is actually
needed 
is a better OOP system than what D offers? What do you have in mind?
Sep 19 2010
parent reply Justin Johansson <no spam.com> writes:
On 19/09/2010 11:49 PM, Lutger wrote:

 Justin Johansson wrote:


 On 19/09/2010 2:59 AM, Lutger wrote:

 To me some of the most distinguishing aspects of D are:


 like python

 - focus on early binding: this quote from David Griers is fitting: "Never put
 off until run time what you can do at compile time." But also related is the
 tendency to choose for a rich set of features, binding at 'language design
 time'

 - support a diversity of programming styles (like C++, python) and attempt to
 integrate them

 - support for features that help, and avoid designs that complicate
 maintenance of large programs

 - take advantage of existing C knowledge and codebase

 - enable the programmer to make his own tradeoff between performance and
 other quality criteria: this is true of many languages, but in D there is a
 much wider space to choose from.


 I think the salient point that all miss is that D does not
 expand beyond the classical OO paradigm in any meaningful way.


 I don't understand this statement, there are quite a few things in D that
 support a different style of programming than OOP, such as:
 - closures for higher-order programming
 - pointers, systems programming features
 - templates
 - pure, transitive const and immutable

 Do you think this is not meaningful? Or do you mean that what is actually
needed
 is a better OOP system than what D offers? What do you have in mind?


Some of these features you mention are very worthwhile but I mean that
that D does not offer any better OOP system amongst its contemporary
rivals.

To be well read on the subject of OOP models I can recommend this link
to a well-articulated paper by Bertrand Meyer:

http://se.ethz.ch/~meyer/publications/computer/taxonomy.pdf

Cheers
Justin Johansson
Sep 19 2010
next sibling parent lurker <lurk lurking.net> writes:
Justin Johansson Wrote:


 On 19/09/2010 11:49 PM, Lutger wrote:

 Justin Johansson wrote:


 On 19/09/2010 2:59 AM, Lutger wrote:

 To me some of the most distinguishing aspects of D are:


 like python

 - focus on early binding: this quote from David Griers is fitting: "Never put
 off until run time what you can do at compile time." But also related is the
 tendency to choose for a rich set of features, binding at 'language design
 time'

 - support a diversity of programming styles (like C++, python) and attempt to
 integrate them

 - support for features that help, and avoid designs that complicate
 maintenance of large programs

 - take advantage of existing C knowledge and codebase

 - enable the programmer to make his own tradeoff between performance and
 other quality criteria: this is true of many languages, but in D there is a
 much wider space to choose from.


 I think the salient point that all miss is that D does not
 expand beyond the classical OO paradigm in any meaningful way.


 I don't understand this statement, there are quite a few things in D that
 support a different style of programming than OOP, such as:
 - closures for higher-order programming
 - pointers, systems programming features
 - templates
 - pure, transitive const and immutable

 Do you think this is not meaningful? Or do you mean that what is actually
needed
 is a better OOP system than what D offers? What do you have in mind?


 
 Some of these features you mention are very worthwhile but I mean that
 that D does not offer any better OOP system amongst its contemporary
 rivals.
 
 To be well read on the subject of OOP models I can recommend this link
 to a well-articulated paper by Bertrand Meyer:
 
 http://se.ethz.ch/~meyer/publications/computer/taxonomy.pdf


tl;dr

Anyway, D supports many paradigms, read the slides written by Walter in some
conference. They are the truth. D supports imperative, procedural, functinal,
metal, meta, constrain, dsl programming, among others. That should be enough.
Sep 19 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/19/10 9:04 CDT, Justin Johansson wrote:

 To be well read on the subject of OOP models I can recommend this link
 to a well-articulated paper by Bertrand Meyer:

 http://se.ethz.ch/~meyer/publications/computer/taxonomy.pdf


I don't consider that piece a recommendable read for contemporary OOP 
developments.

Andrei
Sep 19 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Justin Johansson wrote:

 Some of these features you mention are very worthwhile but I mean that
 that D does not offer any better OOP system amongst its contemporary
 rivals.
 
 To be well read on the subject of OOP models I can recommend this link
 to a well-articulated paper by Bertrand Meyer:
 
 http://se.ethz.ch/~meyer/publications/computer/taxonomy.pdf


The article was written in 1996.

It's just a taxonomy. Describing various inheritance schemes is not enough to 
argue for their adoption. One must show that it neatly solves significant 
problems that other schemes do not or can not.

Meyer's ideas have consistently failed to gain any traction. I don't know why.
Sep 19 2010
prev sibling parent Jay Byrd <JayByrd rebels.com> writes:
On Sun, 19 Sep 2010 23:07:13 +1000, Justin Johansson wrote:


 On 19/09/2010 2:59 AM, Lutger wrote:

 To me some of the most distinguishing aspects of D are:


 perhaps like python

 - focus on early binding: this quote from David Griers is fitting:
 "Never put off until run time what you can do at compile time." But
 also related is the tendency to choose for a rich set of features,
 binding at 'language design time'

 - support a diversity of programming styles (like C++, python) and
 attempt to integrate them

 - support for features that help, and avoid designs that complicate
 maintenance of large programs

 - take advantage of existing C knowledge and codebase

 - enable the programmer to make his own tradeoff between performance
 and other quality criteria: this is true of many languages, but in D
 there is a much wider space to choose from.


 
 I think the salient point that all miss is that D does not expand beyond
 the classical OO paradigm in any meaningful way.


Sorry, but "salient" is not a synonym for "false". Later you clarify by 
saying "D does not offer any better OOP system amongst its contemporary
rivals" but that simply is not relevant to what you responded to.


 When all you have is a hammer, everything looks like a nail.


But D provides more than one tool, so this is silly and misdirected.
 

 When all you have is classical OO, everything looks like it can be
 modeled with inheritance by addition (rather than inheritance by
 restriction for example) or an interface (rather than a trait for
 example also).


Well, D has multiple subtyping, which is akin to traits.
 

 There is no need, or significant consumer demand, to reinvent another
 classical OO language in 2010.


Sez you. What language currently meets D's goals?


 To make any inroad, a new language in
 these times needs to leverage upon some of the lesser well known yet
 powerful idioms of PLs that allow for extensible type systems.


Sez you, but without supporting logic or evidence. Other languages have 
made inroads for quite different reasons.



 
 Cheers
 Justin Johansson
Sep 20 2010
prev sibling next sibling parent reply JMRyan <nospam nospam.com> writes:
One thing that seems to have been missed in this discussion:  minimize (or 
at least reduce from C++ levels) undefined behavior.  That's the reason for 
auto-initialized variables.  It's not to provide aconvenience for those 
times when the default values are what you want.  It's so that failure to 
initialize will cause your program to fail in consistent and predictable 
ways.  It is also the reason for providng clear() as an alternative to 
delete().  Dereferencing dangling pointers results in undefined behavior.  
Accessing a cleared object results in admittedly bad but at least defined 
behavior.
Sep 19 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
JMRyan wrote:

 One thing that seems to have been missed in this discussion:  minimize (or 
 at least reduce from C++ levels) undefined behavior.  That's the reason for 
 auto-initialized variables.  It's not to provide aconvenience for those 
 times when the default values are what you want.  It's so that failure to 
 initialize will cause your program to fail in consistent and predictable 
 ways.  It is also the reason for providng clear() as an alternative to 
 delete().  Dereferencing dangling pointers results in undefined behavior.  
 Accessing a cleared object results in admittedly bad but at least defined 
 behavior.


Good points.
Sep 19 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 15/09/2010 18:58, Andrei Alexandrescu wrote:

 A coworker asked me where he could find a brief document of D's design
 principles. This was after I'd mentioned the "no function hijacking"
 stance.

 I think it would be a great idea if the up-and-coming
 www.d-programming-language.org contained such a document.

 Ideas for what it could contain? I know we discussed this once in the
 past, but couldn't find the discussion.


 Andrei


(recapitulating something that popped in the middle of a discussion a 
while back) :

* D aims to be suitable for medium and large sized software projects. In 
other words, it aims to scale well with increases of: developers, source 
code, software components, project duration, teams, third party 
components, etc..

I don't think this goal would actually influence D's design that much, 
because if language changes and features are carefully designed, they 
would rarely be detrimental to small scale projects in favor of medium 
or large ones.
Rather, the big benefit of the statement above would be to reduce 
certain wasteful discussions or comments that pop-up occasionally in 
which someone proposes some "Pythonesque" change that might benefit 
small programs but would be crap for medium/large ones.


-- 
Bruno Medeiros - Software Engineer
Oct 21 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bruno Medeiros:


 Rather, the big benefit of the statement above would be to reduce 
 certain wasteful discussions or comments that pop-up occasionally in 
 which someone proposes some "Pythonesque" change that might benefit 
 small programs but would be crap for medium/large ones.


I suggest to judge each proposed feature on its own, instead of refusing all
the "Pythonesque" changes together.

A well designed tuple unpacking syntax will shorten D code and make it more
readable and more handy to write, so I think it's a positive change, both for
little and large D programs.

As every language feature tuples too may be abused: in large programs if many
of your functions/methods return tuples with five or six different anonymous
fields, your program will not be much readable.

Another "Pythonesque" example of change that I regard as positive for D
programs of all sizes are lazy/eager array/range comprehensions. If you don't
abuse them, they shorten code, make it more readable, and avoid the cluttering
of brackets and parentheses typical of lambdas with map+array/filter+array
functions.

Bye,
bearophile
Oct 21 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 21/10/2010 18:07, bearophile wrote:

 Bruno Medeiros:


 Rather, the big benefit of the statement above would be to reduce
 certain wasteful discussions or comments that pop-up occasionally in
 which someone proposes some "Pythonesque" change that might benefit
 small programs but would be crap for medium/large ones.


 I suggest to judge each proposed feature on its own, instead of refusing all
the "Pythonesque" changes together.


I agree, and never suggested or implied otherwise!

My reference to Python was a lighthearted one, I did not want to make a 
generic statement about all Python features (that's why I put quotes 
around "Pythonesque"). I am not even familiar with Python, other than 
it's syntax, and in fact, the indentation-as-blocks was the example I 
has in mind when I mentioned "Pythonesque".



 A well designed tuple unpacking syntax will shorten D code and make it more
readable and more handy to write, so I think it's a positive change, both for
little and large D programs.

 As every language feature tuples too may be abused: in large programs if many
of your functions/methods return tuples with five or six different anonymous
fields, your program will not be much readable.

 Another "Pythonesque" example of change that I regard as positive for D
programs of all sizes are lazy/eager array/range comprehensions. If you don't
abuse them, they shorten code, make it more readable, and avoid the cluttering
of brackets and parentheses typical of lambdas with map+array/filter+array
functions.

 Bye,
 bearophile


I've just recalled another "corollary" design goal, a strictening of the 
previous one, that I would also like to see adopted:

  * If changes are of limited use to medium/large scale projects, they 
should also not be considered, even if they are not detrimental to 
projects of such scale.

The reason for this is to save work in implementing languages tools 
(compilers, IDEs, any kind of code analysis tools, etc.). It should be 
obvious to everyone that the time of the programmers working such tools, 
especially the compiler, is a very precious resource.
Indeed, Walter has already expressed his intention to not adopt features 
that are of limited use, however, how useful a feature is is very 
debatable and often not agreed upon. So what I am arguing for, in the 
point above, is that usefulness should only be evaluated in the context 
of medium/large projects.


I am not implying that the tuple features you mentioned above have 
limited use like I described. I am not familiar with those changes at 
the moment and won't comment on them now.


-- 
Bruno Medeiros - Software Engineer
Oct 22 2010