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