www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - If you have to learn just one programming language

reply retard <re tard.com.invalid> writes:
I'm not sure if bearophile or some other language advocate posted this 
already, but:

http://www.reddit.com/r/programming/comments/c3p8e/
if_you_have_to_learn_just_one_programming_language/

"Here are my criteria for selecting (a non domain specific) language to 
learn."

"It should provide high level of abstraction so that programmer 
productivity is high. A fast running application written in C that takes 
6 months is — in most cases — not as useful as one that can be completed 
in 1 month: programmer cost as well as time-to-market considerations."

D is very close to C. The productivity is much lower than with other 
modern scripting or hybrid-functional languages.

"Speed: It should be fast (should approach C in speed)."

DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.

"Succinct: The language should not be verbose. This is very important. 
Brevity is one reason why Python and Ruby are popular."

For example the lambda syntax is terribly verbose in D compared to Scala 
or Haskell.

"It should be a mature and time-tested language with active development, 
user base and lots of applications."

D & DMD are unstable, badly specified, buggy and most dsource projects 
are deprecated (D1) or dead.

"Platform agnostic: It should not favor or give advantage to one 
platform."

DMD only works on 32-bit x86.

"Code readability and maintainability: It should be relatively easy for 
authors and others to maintain existing code."

Java 2-7 is very backwards compatible compared to D2.

"Opensource is a fine model, but if the author doesn’t want to release 
his/her creation under open-source he/she should be able to do so."

The official backend is non-free.

"Has a test framework that can generate and run tests."

The integrated unittest construct is a joke compared to JUnit et al.
May 31 2010
next sibling parent reply Alessandro Ogheri <ogheri alessandroogheri.com> writes:
I suppose you are simply trolling...

anyway, I think that D is an absolutely amazing language,

but please, if you are able to write a language that is faster than
D , more elegant, ALONE!! and you are willing to donate it to us
like Mr. Bright has done... please show us why you think to be so
much better!!
May 31 2010
parent reply retard <re tard.com.invalid> writes:
Mon, 31 May 2010 16:14:31 +0000, Alessandro Ogheri wrote:

 I suppose you are simply trolling...
 
 anyway, I think that D is an absolutely amazing language,
I was simply comparing the current status of D with the other languages mentioned in the original blog post and also propagated the link, since someone might find it funny / amusing / interesting. I appreciate your uneducated subjective opinion, but it has as little value as mine. Learn to tolerate other opinions. I know the social pressure here forces you to post only positive reviews & opinions about D, but in reality those only exist inside your funny little dream world.
 
 but please, if you are able to write a language that is faster than D ,
 more elegant, ALONE!! and you are willing to donate it to us like Mr.
 Bright has done... please show us why you think to be so much better!!
I don't understand this mentality. Do I owe you something?
May 31 2010
parent BCS <none anon.com> writes:
Hello retard,

 Mon, 31 May 2010 16:14:31 +0000, Alessandro Ogheri wrote:
 
 I suppose you are simply trolling...
 
 anyway, I think that D is an absolutely amazing language,
 
I was simply comparing the current status of D with the other languages mentioned in the original blog post and also propagated the link, since someone might find it funny / amusing / interesting. I appreciate your uneducated subjective opinion, but it has as little value as mine. Learn to tolerate other opinions. I know the social pressure here forces you to post only positive reviews & opinions about D, but in reality those only exist inside your funny little dream world.
 but please, if you are able to write a language that is faster than D
 , more elegant, ALONE!! and you are willing to donate it to us like
 Mr. Bright has done... please show us why you think to be so much
 better!!
 
I don't understand this mentality. Do I owe you something?
That link is rather interesting but unless you're suggesting improvements or that we all abandon D, your opinion/commentary has very little value. -- ... <IXOYE><
May 31 2010
prev sibling next sibling parent reply Pelle <pelle.mansson gmail.com> writes:
On 05/31/2010 05:43 PM, retard wrote:
 D is very close to C. The productivity is much lower than with other
 modern scripting or hybrid-functional languages.
I disagree, unless you need a specific library which D does not yet have.
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
 For example the lambda syntax is terribly verbose in D compared to Scala
 or Haskell.
But way better than in java, C, C++ or almost any other language.
 D&  DMD are unstable, badly specified, buggy and most dsource projects
 are deprecated (D1) or dead.
True, but it's not like D isn't moving anywhere in that aspect.
 DMD only works on 32-bit x86.
It only compiles 32 bit code, but it works on x86_64 as well, I think. Is there a point in here somewhere? :)
May 31 2010
parent reply retard <re tard.com.invalid> writes:
Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:

 On 05/31/2010 05:43 PM, retard wrote:
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
Polymorphic method calls, auto-vectorization, link-time optimization, floating point performance, etc.
 
 For example the lambda syntax is terribly verbose in D compared to
 Scala or Haskell.
But way better than in java, C, C++ or almost any other language.
So basically if I'm offering you $100000 and $10, you're taking $10 because it's more than $1 or $2 or any value between $3 and $4. Great logic.
 
 D&  DMD are unstable, badly specified, buggy and most dsource projects
 are deprecated (D1) or dead.
True, but it's not like D isn't moving anywhere in that aspect.
Not sure about that. I'm still waiting for proper .stringof documentation and a formal spec for SafeD (I really want to know what it is exactly and what it is not)..
 Is there a point in here somewhere? :)
I suppose not..
May 31 2010
next sibling parent Pelle <pelle.mansson gmail.com> writes:
On 05/31/2010 08:17 PM, retard wrote:
 But way better than in java, C, C++ or almost any other language.
So basically if I'm offering you $100000 and $10, you're taking $10 because it's more than $1 or $2 or any value between $3 and $4. Great logic.
D has a delegate syntax which fits with the rest of D. If you don't like the overall design of the D syntax, well, that's another complaint entirely. It's more like offering $100 and €80.
May 31 2010
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello retard,

 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
 
 On 05/31/2010 05:43 PM, retard wrote:
 
 For example the lambda syntax is terribly verbose in D compared to
 Scala or Haskell.
 
But way better than in java, C, C++ or almost any other language.
So basically if I'm offering you $100000 and $10, you're taking $10 because it's more than $1 or $2 or any value between $3 and $4. Great logic.
I'd say it's more like me taking $10 over $10.14 because I don't have to deal with the coins.
 D&  DMD are unstable, badly specified, buggy and most dsource
 projects are deprecated (D1) or dead.
 
True, but it's not like D isn't moving anywhere in that aspect.
Not sure about that. I'm still waiting for proper .stringof documentation
I see a lot of fruit that's a lot lower and juicer than that. For that matter, you can read the source, figure it out your self and write the docs for it. Heck, even if you just slapped together some notes and posted them in an bugzilla ticket it would be something.
 and a formal spec for SafeD (I really want to know what
 it is exactly and what it is not)..
 
Um, it's easy to figure out of something is or isn't allowed in safeD; write a program and try it. -- ... <IXOYE><
May 31 2010
parent reply Don <nospam nospam.com> writes:
BCS wrote:
 Hello retard,
 
 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:

 On 05/31/2010 05:43 PM, retard wrote:

 For example the lambda syntax is terribly verbose in D compared to
 Scala or Haskell.
But way better than in java, C, C++ or almost any other language.
So basically if I'm offering you $100000 and $10, you're taking $10 because it's more than $1 or $2 or any value between $3 and $4. Great logic.
I'd say it's more like me taking $10 over $10.14 because I don't have to deal with the coins.
 D&  DMD are unstable, badly specified, buggy and most dsource
 projects are deprecated (D1) or dead.
True, but it's not like D isn't moving anywhere in that aspect.
Not sure about that. I'm still waiting for proper .stringof documentation
I see a lot of fruit that's a lot lower and juicer than that. For that matter, you can read the source, figure it out your self and write the docs for it. Heck, even if you just slapped together some notes and posted them in an bugzilla ticket it would be something.
 and a formal spec for SafeD (I really want to know what
 it is exactly and what it is not)..
Um, it's easy to figure out of something is or isn't allowed in safeD; write a program and try it.
That doesn't work. Pointer arithmetic is forbidden in safeD, but currently accepted by the compiler. But don't worry about this stuff, it should be fixed fairly soon.
May 31 2010
parent reply BCS <none anon.com> writes:
Hello Don,

 BCS wrote:
 
 Hello retard,
 
 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
 
 On 05/31/2010 05:43 PM, retard wrote:
 
 For example the lambda syntax is terribly verbose in D compared to
 Scala or Haskell.
 
But way better than in java, C, C++ or almost any other language.
So basically if I'm offering you $100000 and $10, you're taking $10 because it's more than $1 or $2 or any value between $3 and $4. Great logic.
I'd say it's more like me taking $10 over $10.14 because I don't have to deal with the coins.
 D&  DMD are unstable, badly specified, buggy and most dsource
 projects are deprecated (D1) or dead.
 
True, but it's not like D isn't moving anywhere in that aspect.
Not sure about that. I'm still waiting for proper .stringof documentation
I see a lot of fruit that's a lot lower and juicer than that. For that matter, you can read the source, figure it out your self and write the docs for it. Heck, even if you just slapped together some notes and posted them in an bugzilla ticket it would be something.
 and a formal spec for SafeD (I really want to know what it is
 exactly and what it is not)..
 
Um, it's easy to figure out of something is or isn't allowed in safeD; write a program and try it.
That doesn't work. Pointer arithmetic is forbidden in safeD, but currently accepted by the compiler. But don't worry about this stuff, it should be fixed fairly soon.
In that case, I'd say that the reason there is no formal spec for SafeD is that there is no spec at all. Formal spec or no, a SafeD that's not enforced by the compiler is of little or no usable value, and I'm leaning towards the latter. -- ... <IXOYE><
May 31 2010
parent reply retard <re tard.com.invalid> writes:
Tue, 01 Jun 2010 05:02:45 +0000, BCS wrote:

 Hello Don,
 
 BCS wrote:
 
 Hello retard,
 
 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
 
 On 05/31/2010 05:43 PM, retard wrote:
 
 For example the lambda syntax is terribly verbose in D compared to
 Scala or Haskell.
 
But way better than in java, C, C++ or almost any other language.
So basically if I'm offering you $100000 and $10, you're taking $10 because it's more than $1 or $2 or any value between $3 and $4. Great logic.
I'd say it's more like me taking $10 over $10.14 because I don't have to deal with the coins.
 D&  DMD are unstable, badly specified, buggy and most dsource
 projects are deprecated (D1) or dead.
 
True, but it's not like D isn't moving anywhere in that aspect.
Not sure about that. I'm still waiting for proper .stringof documentation
I see a lot of fruit that's a lot lower and juicer than that. For that matter, you can read the source, figure it out your self and write the docs for it. Heck, even if you just slapped together some notes and posted them in an bugzilla ticket it would be something.
 and a formal spec for SafeD (I really want to know what it is exactly
 and what it is not)..
 
Um, it's easy to figure out of something is or isn't allowed in safeD; write a program and try it.
That doesn't work. Pointer arithmetic is forbidden in safeD, but currently accepted by the compiler. But don't worry about this stuff, it should be fixed fairly soon.
In that case, I'd say that the reason there is no formal spec for SafeD is that there is no spec at all. Formal spec or no, a SafeD that's not enforced by the compiler is of little or no usable value, and I'm leaning towards the latter.
When a Haskell developer invents something like SafeD, he/she immediately opens safed-spec.tex in vim or emacs. The paper is precise and published on the standard web site. It might even get a presentation in some FPL conference. When D gets a new feature, there might be 0-2 short examples showing some more or less unimportant aspect of the feature among 50000 daily bikeshedding NNTP articles. Basically, if you want to know what SafeD is, you seriously need to browse all the messages written here lately.
Jun 01 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/01/2010 05:34 PM, retard wrote:
 When a Haskell developer invents something like SafeD, he/she immediately
 opens safed-spec.tex in vim or emacs. The paper is precise and published
 on the standard web site. It might even get a presentation in some FPL
 conference. When D gets a new feature, there might be 0-2 short examples
 showing some more or less unimportant aspect of the feature among 50000
 daily bikeshedding NNTP articles. Basically, if you want to know what
 SafeD is, you seriously need to browse all the messages written here
 lately.
I agree that we should better ground theoretically some important aspects of D semantics. Andrei
Jun 01 2010
parent retard <re tard.com.invalid> writes:
Tue, 01 Jun 2010 17:44:57 -0500, Andrei Alexandrescu wrote:

 On 06/01/2010 05:34 PM, retard wrote:
 When a Haskell developer invents something like SafeD, he/she
 immediately opens safed-spec.tex in vim or emacs. The paper is precise
 and published on the standard web site. It might even get a
 presentation in some FPL conference. When D gets a new feature, there
 might be 0-2 short examples showing some more or less unimportant
 aspect of the feature among 50000 daily bikeshedding NNTP articles.
 Basically, if you want to know what SafeD is, you seriously need to
 browse all the messages written here lately.
I agree that we should better ground theoretically some important aspects of D semantics. Andrei
Thank you.
Jun 01 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
 
 On 05/31/2010 05:43 PM, retard wrote:
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
Polymorphic method calls, auto-vectorization, link-time optimization, floating point performance, etc.
Link time optimization? Let's examine it: https://lwn.net/Articles/387122/ "When source files are compiled and linked using -flto, GCC applies optimizations as if all the source code were in a single file. This allows GCC to perform more aggressive optimizations across files, such as inlining the body of a function from one file that is called from a different file, and propagating constants across files. In general, the LTO framework enables all the usual optimizations that work at a higher level than a single function to also work across files that are independently compiled." D has had that for 8 years now, it's just done in the compiler instead of the linker. You can specify as many D source modules as you want on the command line to the compiler, and it will compile & optimizer & inline them all together and generate one object file. Essentially, link time optimization is a hack to get around the language problem C/C++ have with their separate compilation model. To say D code is slower because it lacks link-time optimization is a false supposition.
May 31 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 retard wrote:
 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:

 On 05/31/2010 05:43 PM, retard wrote:
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
Polymorphic method calls, auto-vectorization, link-time optimization, floating point performance, etc.
Link time optimization? Let's examine it: https://lwn.net/Articles/387122/ "When source files are compiled and linked using -flto, GCC applies optimizations as if all the source code were in a single file. This allows GCC to perform more aggressive optimizations across files, such as inlining the body of a function from one file that is called from a different file, and propagating constants across files. In general, the LTO framework enables all the usual optimizations that work at a higher level than a single function to also work across files that are independently compiled." D has had that for 8 years now, it's just done in the compiler instead of the linker. You can specify as many D source modules as you want on the command line to the compiler, and it will compile & optimizer & inline them all together and generate one object file. Essentially, link time optimization is a hack to get around the language problem C/C++ have with their separate compilation model. To say D code is slower because it lacks link-time optimization is a false supposition.
I was not aware that specifying multiple files at the same time affects optimization. This feature needs to be better integrated into IDEs. For small but computationally intensive scientific computing programs, I would rather ditch separate compilation entirely and just compile the entire program in one go. Nonetheless, CodeBlocks compiles each file separately by default, and if this is customizable I don't how how.
May 31 2010
parent "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 31 May 2010 19:09:06 -0400, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 retard wrote:
 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:

 On 05/31/2010 05:43 PM, retard wrote:
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
Polymorphic method calls, auto-vectorization, link-time optimization, floating point performance, etc.
Link time optimization? Let's examine it: https://lwn.net/Articles/387122/ "When source files are compiled and linked using -flto, GCC applies optimizations as if all the source code were in a single file. This allows GCC to perform more aggressive optimizations across files, such as inlining the body of a function from one file that is called from a different file, and propagating constants across files. In general, the LTO framework enables all the usual optimizations that work at a higher level than a single function to also work across files that are independently compiled." D has had that for 8 years now, it's just done in the compiler instead of the linker. You can specify as many D source modules as you want on the command line to the compiler, and it will compile & optimizer & inline them all together and generate one object file. Essentially, link time optimization is a hack to get around the language problem C/C++ have with their separate compilation model. To say D code is slower because it lacks link-time optimization is a false supposition.
I was not aware that specifying multiple files at the same time affects optimization. This feature needs to be better integrated into IDEs. For small but computationally intensive scientific computing programs, I would rather ditch separate compilation entirely and just compile the entire program in one go. Nonetheless, CodeBlocks compiles each file separately by default, and if this is customizable I don't how how.
Includes count for the purposes of this feature, so you shouldn't be losing any optimization opportunities with separate compilation.
Jun 04 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Mon, 31 May 2010 15:41:00 -0700, Walter Bright wrote:

 retard wrote:
 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
 
 On 05/31/2010 05:43 PM, retard wrote:
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
Polymorphic method calls, auto-vectorization, link-time optimization, floating point performance, etc.
Link time optimization? Let's examine it: https://lwn.net/Articles/387122/ "When source files are compiled and linked using -flto, GCC applies optimizations as if all the source code were in a single file. This allows GCC to perform more aggressive optimizations across files, such as inlining the body of a function from one file that is called from a different file, and propagating constants across files. In general, the LTO framework enables all the usual optimizations that work at a higher level than a single function to also work across files that are independently compiled." D has had that for 8 years now, it's just done in the compiler instead of the linker. You can specify as many D source modules as you want on the command line to the compiler, and it will compile & optimizer & inline them all together and generate one object file. Essentially, link time optimization is a hack to get around the language problem C/C++ have with their separate compilation model. To say D code is slower because it lacks link-time optimization is a false supposition.
I thought the DMD's approach required sources for each module and GCC supported LTO even when only object / library files were provided.
May 31 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 I thought the DMD's approach required sources for each module and GCC 
 supported LTO even when only object / library files were provided.
DMD does require the sources, or at least the sources you'd like to have inlined. GCC requires all the sources used to be compiled with a special switch: "When using multiple steps, it is strongly recommended to use exactly the same optimization and machine-dependent options in all commands, because conflicting options during compilation and link-time may lead to strange errors." https://lwn.net/Articles/387122/
May 31 2010
parent reply Alex Makhotin <alex bitprox.com> writes:
Walter Bright wrote:
 retard wrote:
 I thought the DMD's approach required sources for each module and GCC 
 supported LTO even when only object / library files were provided.
DMD does require the sources, or at least the sources you'd like to have inlined. GCC requires all the sources used to be compiled with a special switch: "When using multiple steps, it is strongly recommended to use exactly the same optimization and machine-dependent options in all commands, because conflicting options during compilation and link-time may lead to strange errors." https://lwn.net/Articles/387122/
So the best way to build release version(assuming two-phase build) should be: 1. Synchronize DMD compilation switches with DMD link switches(-release -O -inline). 2. Pass all the project sources in one DMD cmd line, compile. 3. Link produced object file with other libs. Am I correct? Does single-phase(compile-link in one command line) give optimization gain with the DMD? -- Alex Makhotin, the founder of BITPROX, http://bitprox.com
Jun 01 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Alex Makhotin wrote:
 So the best way to build release version(assuming two-phase build) 
 should be:
 
 1. Synchronize DMD compilation switches with DMD link switches(-release 
 -O -inline).
 2. Pass all the project sources in one DMD cmd line, compile.
 3. Link produced object file with other libs.
 
 Am I correct?
You don't need to "synchronize" switches. Just pass all the source files that you can that make up your project on one command line.
 Does single-phase(compile-link in one command line) give optimization 
 gain with the DMD?
Yes.
Jun 01 2010
next sibling parent Alex Makhotin <alex bitprox.com> writes:
Walter Bright wrote:
 
 Does single-phase(compile-link in one command line) give optimization 
 gain with the DMD?
Yes.
OK, currently I use two step build system, it looks reasonable to implement this scheme for release build. -- Alex Makhotin, the founder of BITPROX, http://bitprox.com
Jun 01 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/01/2010 04:57 AM, Walter Bright wrote:
 Alex Makhotin wrote:
 So the best way to build release version(assuming two-phase build)
 should be:

 1. Synchronize DMD compilation switches with DMD link
 switches(-release -O -inline).
 2. Pass all the project sources in one DMD cmd line, compile.
 3. Link produced object file with other libs.

 Am I correct?
You don't need to "synchronize" switches. Just pass all the source files that you can that make up your project on one command line.
I now realize that for large projects a future need would be for dmd to read files off the standard input. The length of the command line is limited. Andrei
Jun 01 2010
next sibling parent Max Samukha <spambox d-coding.com> writes:
On 01.06.2010 16:23, Andrei Alexandrescu wrote:

 I now realize that for large projects a future need would be for dmd to
 read files off the standard input. The length of the command line is
 limited.

 Andrei
"dmd cmdfile" is often used for that purpose.
Jun 01 2010
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  1 de junio a las 08:23 me escribiste:
 On 06/01/2010 04:57 AM, Walter Bright wrote:
Alex Makhotin wrote:
So the best way to build release version(assuming two-phase build)
should be:

1. Synchronize DMD compilation switches with DMD link
switches(-release -O -inline).
2. Pass all the project sources in one DMD cmd line, compile.
3. Link produced object file with other libs.

Am I correct?
You don't need to "synchronize" switches. Just pass all the source files that you can that make up your project on one command line.
I now realize that for large projects a future need would be for dmd to read files off the standard input. The length of the command line is limited.
Or maybe from a file. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- DESCARTAN BIDET VIRTUAL PORQUE NO LAVA -- Cronista TV
Jun 01 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 I now realize that for large projects a future need would be for dmd to 
 read files off the standard input. The length of the command line is 
 limited.
dmd can read command lines from a file with the: dmd command.txt syntax. There is no limit to the command line length this way. Also, dmd can read command lines from an environment variable using: dmd COMMAND These can be arbitrarily combined with other switches: dmd -inline command.txt -release COMMAND
Jun 01 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/01/2010 01:42 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 I now realize that for large projects a future need would be for dmd
 to read files off the standard input. The length of the command line
 is limited.
dmd can read command lines from a file with the: dmd command.txt syntax. There is no limit to the command line length this way. Also, dmd can read command lines from an environment variable using: dmd COMMAND These can be arbitrarily combined with other switches: dmd -inline command.txt -release COMMAND
Windows syntax, bleh. :o| Andrei
Jun 01 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 06/01/2010 01:42 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 I now realize that for large projects a future need would be for dmd
 to read files off the standard input. The length of the command line
 is limited.
dmd can read command lines from a file with the: dmd command.txt syntax. There is no limit to the command line length this way. Also, dmd can read command lines from an environment variable using: dmd COMMAND These can be arbitrarily combined with other switches: dmd -inline command.txt -release COMMAND
Windows syntax, bleh. :o|
Actually, this goes back to DOS in 1983 or so, because DOS had a 128 byte command line length limit.
Jun 01 2010
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 01 Jun 2010 10:56:47 +0300, Alex Makhotin <alex bitprox.com> wrote:

 So the best way to build release version(assuming two-phase build)  
 should be:

 1. Synchronize DMD compilation switches with DMD link switches(-release  
 -O -inline).
 2. Pass all the project sources in one DMD cmd line, compile.
 3. Link produced object file with other libs.

 Am I correct?
"-release -O -inline" are all compiler switches, and do not apply to the linker. Speaking of link-time optimization: I assume that the standard library is not subjected to link-time optimization, because all code is used from the .lib. Doesn't this mean that standard library functions will never be inlined? Even very short functions, that merely return a value? (e.g. range.length) I suppose that the same applies to the runtime, but if the runtime functions were short enough to be inlined, the compiler could just generate the appropriate machine code instead. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Jun 01 2010
next sibling parent Alex Makhotin <alex bitprox.com> writes:
Vladimir Panteleev wrote:
 
 I assume that the standard library is not subjected to link-time 
 optimization, because all code is used from the .lib.
 
What I think is that the libphobos2.a and libdruntime.a should be available with and without debug information so that the user may choose which to link with. And I guess, what kind of issues may arise from mixing such static libs, and what effects this may take on, e.g. memory allocation/deallocation. -- Alex Makhotin, the founder of BITPROX, http://bitprox.com
Jun 01 2010
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-06-01 12:01, Vladimir Panteleev wrote:
 On Tue, 01 Jun 2010 10:56:47 +0300, Alex Makhotin <alex bitprox.com> wrote:

 So the best way to build release version(assuming two-phase build)
 should be:

 1. Synchronize DMD compilation switches with DMD link
 switches(-release -O -inline).
 2. Pass all the project sources in one DMD cmd line, compile.
 3. Link produced object file with other libs.

 Am I correct?
"-release -O -inline" are all compiler switches, and do not apply to the linker. Speaking of link-time optimization: I assume that the standard library is not subjected to link-time optimization, because all code is used from the .lib. Doesn't this mean that standard library functions will never be inlined? Even very short functions, that merely return a value? (e.g. range.length)
The sources are available. Compared to C/C++, D doesn't use header files (at least not Phobos).
 I suppose that the same applies to the runtime, but if the runtime
 functions were short enough to be inlined, the compiler could just
 generate the appropriate machine code instead.
-- /Jacob Carlborg
Jun 01 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Vladimir Panteleev wrote:
 Doesn't this mean that standard library functions will never be inlined? 
The standard library functions can be inlined despite them being in phobos.lib because the compiler still has access to the source code for them.
Jun 01 2010
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 31 de mayo a las 15:41 me escribiste:
 retard wrote:
Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:

On 05/31/2010 05:43 PM, retard wrote:
DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
Polymorphic method calls, auto-vectorization, link-time optimization, floating point performance, etc.
Link time optimization? Let's examine it: https://lwn.net/Articles/387122/ "When source files are compiled and linked using -flto, GCC applies optimizations as if all the source code were in a single file. This allows GCC to perform more aggressive optimizations across files, such as inlining the body of a function from one file that is called from a different file, and propagating constants across files. In general, the LTO framework enables all the usual optimizations that work at a higher level than a single function to also work across files that are independently compiled." D has had that for 8 years now, it's just done in the compiler instead of the linker. You can specify as many D source modules as you want on the command line to the compiler, and it will compile & optimizer & inline them all together and generate one object file. Essentially, link time optimization is a hack to get around the language problem C/C++ have with their separate compilation model. To say D code is slower because it lacks link-time optimization is a false supposition.
Yeah, but you can't get link-time optimization if you compile each file separately (to enable partial compilation when you change just one file). Yes I know that D compiles really fast, but you can never compile fast enough :) With really huge projects, compiling the whole project can take, let's say 10 seconds, while compiling *just* one file takes a fraction of a seconds (is instantaneous from a human point of view). The difference is waiting a little time vs not waiting at all. That said, doing link-time optimization is probably useful only for builds that you will test a lot or production code, so maybe for that builds one can afford the extra waiting time, it's just a little annoying to have to use a different build method for those builds, though :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- El techo de mi cuarto lleno de galaxias
May 31 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 31 de mayo a las 15:41 me escribiste:
 To say D code is slower because it lacks link-time optimization is a
 false supposition.
Yeah, but you can't get link-time optimization if you compile each file separately (to enable partial compilation when you change just one file). Yes I know that D compiles really fast, but you can never compile fast enough :)
The link-time optimization is essentially compiling the whole project anyway, so I don't see how you're saving any time with it over D's approach.
May 31 2010
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Walter Bright wrote:

 The link-time optimization is essentially compiling the whole project
 anyway,
That makes no sense.
 so I don't see how you're saving any time with it over D's approach.
You save time by recompiling only files that have changes. More importantly, what if you only have access to the object files? -- Michiel Helvensteijn
Jun 01 2010
parent reply Adam Ruppe <destructionator gmail.com> writes:
On 6/1/10, Michiel Helvensteijn <m.helvensteijn.remove gmail.com> wrote:
 Walter Bright wrote:

 The link-time optimization is essentially compiling the whole project
 anyway,
That makes no sense.
In simple terms, that is what it is though! http://gcc.gnu.org/wiki/LinkTimeOptimization "Link Time Optimization (LTO) gives GCC the capability of dumping its internal representation (GIMPLE) to disk, so that all the different compilation units that make up a single executable can be optimized as a single module." The -lto option dumps gcc's internal data into the object file, so when it is called again, it can reload it, as if it had just created it from the source.
 You save time by recompiling only files that have changes.
But, then the whole program goes through the process again anyway to perform the optimization. You save a little time in skipping parts of the front end for unchanged file, but the whole backend process has to happen anyway.
 More importantly, what if you only have access to the object files?
Unless you make those object files with the special -lto switch, you still don't get the benefit.
Jun 01 2010
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Adam Ruppe wrote:

 You save time by recompiling only files that have changes.
But, then the whole program goes through the process again anyway to perform the optimization. You save a little time in skipping parts of the front end for unchanged file, but the whole backend process has to happen anyway.
That `backend' process is not the compilation process all over again. It's not even the optimizer phase all over again. It's just the extra optimizations that could not be performed on a file-by-file basis. Or at least it should be. -- Michiel Helvensteijn
Jun 01 2010
parent reply Don <nospam nospam.com> writes:
Michiel Helvensteijn wrote:
 Adam Ruppe wrote:
 
 You save time by recompiling only files that have changes.
But, then the whole program goes through the process again anyway to perform the optimization. You save a little time in skipping parts of the front end for unchanged file, but the whole backend process has to happen anyway.
That `backend' process is not the compilation process all over again. It's not even the optimizer phase all over again. It's just the extra optimizations that could not be performed on a file-by-file basis. Or at least it should be.
It really needs to be able to perform inlining, and that means it's still a fair chunk of the optimiser. It's true that link-time optimisation means that much of the front-end compilation can be skipped, which is a huge fraction of the total time in C++. (Certainly you can skip the parsing step completely). But it's a much smaller fraction of the total time in D. So it isn't the big win for D that it is for C++.
Jun 01 2010
parent reply Leandro Lucarella <llucax gmail.com> writes:
Don, el  1 de junio a las 20:15 me escribiste:
 Michiel Helvensteijn wrote:
Adam Ruppe wrote:

You save time by recompiling only files that have changes.
But, then the whole program goes through the process again anyway to perform the optimization. You save a little time in skipping parts of the front end for unchanged file, but the whole backend process has to happen anyway.
That `backend' process is not the compilation process all over again. It's not even the optimizer phase all over again. It's just the extra optimizations that could not be performed on a file-by-file basis. Or at least it should be.
It really needs to be able to perform inlining, and that means it's still a fair chunk of the optimiser. It's true that link-time optimisation means that much of the front-end compilation can be skipped, which is a huge fraction of the total time in C++. (Certainly you can skip the parsing step completely). But it's a much smaller fraction of the total time in D. So it isn't the big win for D that it is for C++.
LTO is not only targeted at C++. I don't have numbers to talk seriously about how a big gain is for C though, which might be closer to D in terms of parse time compared with the whole compilation process. Even more, you can do LTO for object files generated from different languages. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- En la calle me crucé con un señor muy correcto, que habitualmente anda en Falcon; iba corriendo con dos valijas en la mano y dijo: "Voy para Miami, tiene algún mensaje o ..." y le dije: "No, no, no..." -- Extra Tato (1983, Triunfo de Alfonsín)
Jun 01 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 LTO is not only targeted at C++. I don't have numbers to talk seriously
 about how a big gain is for C though, which might be closer to D in
 terms of parse time compared with the whole compilation process. Even
 more, you can do LTO for object files generated from different
 languages.
I gotta believe that if you're writing Fortran functions and expecting them to be inlined into C code, or other such function-by-function language mixing, things are getting desperate. It's also true that too much inlining will make your code slower: https://lwn.net/Articles/255364/
Jun 01 2010
next sibling parent Alex Makhotin <alex bitprox.com> writes:
Walter Bright wrote:
  
 I gotta believe that if you're writing Fortran functions and expecting 
 them to be inlined into C code, or other such function-by-function 
 language mixing, things are getting desperate.
 
I have experienced a runtime disaster after executing exe which successfully linked with C++ library, probably produced with MS toolchain, with another one, produced with mingw32 GCC on Windows. Same language, incompatible compilers, incompatible code... Fixed it by rebuild all required libraries with Microsoft tools. Another issue came - runtime crash when MS DLL called routine inside the EXE produced with the DMD. Currently I don't know how to fix it, I disabled callbacks as a temporary measure. For this reason the GC managed code doesn't free resources, because even if the wxWidgets releases it's allocated object, the reference of the managed wrapper persists, which is stored in the hash table, so the hash table becomes bigger and bigger... -- Alex Makhotin, the founder of BITPROX, http://bitprox.com
Jun 01 2010
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  1 de junio a las 17:18 me escribiste:
 Leandro Lucarella wrote:
LTO is not only targeted at C++. I don't have numbers to talk seriously
about how a big gain is for C though, which might be closer to D in
terms of parse time compared with the whole compilation process. Even
more, you can do LTO for object files generated from different
languages.
I gotta believe that if you're writing Fortran functions and expecting them to be inlined into C code, or other such function-by-function language mixing, things are getting desperate. It's also true that too much inlining will make your code slower: https://lwn.net/Articles/255364/
It looks like you are reading LWN a lot lately. That's good! =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- FALTAN 325 DIAS PARA LA PRIMAVERA -- Crónica TV
Jun 01 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Adam Ruppe wrote:
 You save time by recompiling only files that have changes.
But, then the whole program goes through the process again anyway to perform the optimization. You save a little time in skipping parts of the front end for unchanged file, but the whole backend process has to happen anyway.
 More importantly, what if you only have access to the object files?
Unless you make those object files with the special -lto switch, you still don't get the benefit.
Right. I wish to add that when compiling with full optimization on, the optimization time dominates the compile time. You'd only do LTO when doing a release build with full optimization, so it essentially is compiling the full program even when doing an incremental build.
Jun 01 2010
prev sibling parent reply Lurker <nospam spamfree.net> writes:
Walter Bright wrote:

"Essentially, link time optimization is a hack to get around the language
problem C/C++ have with their separate compilation model."

I know what you meant, but to be correct: C/C++ have INDEPENDENT
compilation, not SEPARATE compilation; Ada has SEPARATE compilation, for
example.
Jun 01 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Lurker wrote:
 Walter Bright wrote:
 
 "Essentially, link time optimization is a hack to get around the language
 problem C/C++ have with their separate compilation model."
 
 I know what you meant, but to be correct: C/C++ have INDEPENDENT
 compilation, not SEPARATE compilation; Ada has SEPARATE compilation, for
 example.
Right.
Jun 01 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 Mon, 31 May 2010 18:23:18 +0200, Pelle wrote:
 
 On 05/31/2010 05:43 PM, retard wrote:
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
For very special values of much, I suppose.
Polymorphic method calls,
What do you mean by that as an optimization?
May 31 2010
prev sibling next sibling parent "Yao G." <nospamyao gmail.com> writes:
Thanks for another trolling post of yours. :rolleyes: Weren't you suppos=
ed  =

to stop posting?

On Mon, 31 May 2010 10:43:36 -0500, retard <re tard.com.invalid> wrote:

 I'm not sure if bearophile or some other language advocate posted this=
 already, but:

 http://www.reddit.com/r/programming/comments/c3p8e/
 if_you_have_to_learn_just_one_programming_language/

 "Here are my criteria for selecting (a non domain specific) language t=
o
 learn."

 "It should provide high level of abstraction so that programmer
 productivity is high. A fast running application written in C that tak=
es
 6 months is =E2=80=94 in most cases =E2=80=94 not as useful as one tha=
t can be completed
 in 1 month: programmer cost as well as time-to-market considerations."=
 D is very close to C. The productivity is much lower than with other
 modern scripting or hybrid-functional languages.

 "Speed: It should be fast (should approach C in speed)."

 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.

 "Succinct: The language should not be verbose. This is very important.=
 Brevity is one reason why Python and Ruby are popular."

 For example the lambda syntax is terribly verbose in D compared to Sca=
la
 or Haskell.

 "It should be a mature and time-tested language with active developmen=
t,
 user base and lots of applications."

 D & DMD are unstable, badly specified, buggy and most dsource projects=
 are deprecated (D1) or dead.

 "Platform agnostic: It should not favor or give advantage to one
 platform."

 DMD only works on 32-bit x86.

 "Code readability and maintainability: It should be relatively easy fo=
r
 authors and others to maintain existing code."

 Java 2-7 is very backwards compatible compared to D2.

 "Opensource is a fine model, but if the author doesn=E2=80=99t want to=
release
 his/her creation under open-source he/she should be able to do so."

 The official backend is non-free.

 "Has a test framework that can generate and run tests."

 The integrated unittest construct is a joke compared to JUnit et al.
-- = Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
May 31 2010
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 31 May 2010 15:43:36 +0000, retard wrote:
 I'm not sure if bearophile or some other language advocate posted this
 already, but:
 
 http://www.reddit.com/r/programming/comments/c3p8e/
 if_you_have_to_learn_just_one_programming_language/
 
 "Here are my criteria for selecting (a non domain specific) language to
 learn."
It seems to me that most of your statements are completely subjective, since you haven't backed any of them by actual evidence. Nor do you suggest ways to improve on the situation. As far as helping D goes, you might as well have said "I don't like cheese".
 most dsource projects
 are deprecated (D1) or dead.
I suspect the same is true for SourceForge or any other similar site. The problem is that dead projects are listed together with the few active ones, but that's a problem with dsource, not with D. Also, I believe there are plenty of people who will disagree with you that D1 is "deprecated".
 DMD only works on 32-bit x86.
It works on x86 and x86-64, for Windows, Linux, OSX and FreeBSD. This covers the vast majority of desktops and servers in existence. (Embedded systems are a different story, though.)
 "Opensource is a fine model, but if the author doesn’t want to release
 his/her creation under open-source he/she should be able to do so."
 
 The official backend is non-free.
What does "official backend" mean? I guess you mean DMD's backend, which is both "free as in beer" and open source, only not "free as in speech" or Open Source (TM). But I don't see what this has to do with D users' choice of open or closed source. -Lars
May 31 2010
parent BCS <none anon.com> writes:
Hello Lars,

 As far as helping D goes,
 you might as well have said "I don't like cheese".
And that phrase has even less content than most people first think because it fails to distinguish between disliking cheese and just not caring. I apologize for dragging out my soapbox but you just used the exact phrase I love using as an example. :) -- ... <IXOYE><
May 31 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello retard,

 I'm not sure if bearophile or some other language advocate posted this
 already, but:
 
 http://www.reddit.com/r/programming/comments/c3p8e/
 if_you_have_to_learn_just_one_programming_language/
 
 "Here are my criteria for selecting (a non domain specific) language
 to learn."
 
 "It should provide high level of abstraction so that programmer
 productivity is high. A fast running application written in C that
 takes 6 months is — in most cases — not as useful as one that can be
 completed in 1 month: programmer cost as well as time-to-market
 considerations."
 
 D is very close to C. The productivity is much lower than with other
 modern scripting or hybrid-functional languages.
D is better than C++ (by a lot) and C++ is better than C. This is my opinion, I will not debate it.
 
 "Speed: It should be fast (should approach C in speed)."
 
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
That's an implementation issue, the result of some degree of immaturity and is being addressed.
 
 "Succinct: The language should not be verbose. This is very important.
 Brevity is one reason why Python and Ruby are popular."
 
 For example the lambda syntax is terribly verbose in D compared to
 Scala or Haskell.
 
It's succinct enought for me. Being more succinct would add no value IMO.
 "It should be a mature and time-tested language with active
 development, user base and lots of applications."
 
 D & DMD are unstable, badly specified, buggy and most dsource projects
 are deprecated (D1) or dead.
D is immature and not time-tested, but than so is every language at some point. D1 is stable, D2 is being stabilized, DMD is buggy but improving. I'll grant that the library situation isn't good but, again, time can change that.
 
 "Platform agnostic: It should not favor or give advantage to one
 platform."
 
 DMD only works on 32-bit x86.
 
Yes, DMD only works on 32bit x86. D can be implemented on most any modern processor as shown (or so I recall) by LDC and GDC.
 "Code readability and maintainability: It should be relatively easy
 for authors and others to maintain existing code."
 
 Java 2-7 is very backwards compatible compared to D2.
I don't see that as a problem. If every major version is full of breaking changes that could be a problems.
 
 "Opensource is a fine model, but if the author doesn’t want to release
 his/her creation under open-source he/she should be able to do so."
 
 The official backend is non-free.
Irrelevant.
 
 "Has a test framework that can generate and run tests."
 
 The integrated unittest construct is a joke compared to JUnit et al.
 
IIRC JUnit is a library that is integrated into IDEs as well as the language culture but not Java its self. Unless you want to show that the same CAN'T be done for D, your point devolves to "D is immature". All the points that have any value IMO devolve to "D is immature" (and that's the only thing the OP said about it) so for the question of " If you have to learn just one programming language today", yes D likely isn't it, but nothing rules it out for a ways (maybe only a little ways) down the line. -- ... <IXOYE><
May 31 2010
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
retard Wrote:

 snip
Even though he said all of that, he wouldn't be here and post so often if he didn't think D was a good language.
May 31 2010
parent reply retard <re tard.com.invalid> writes:
Mon, 31 May 2010 13:57:34 -0400, Andrej Mitrovic wrote:

 retard Wrote:
 
 snip
Even though he said all of that, he wouldn't be here and post so often if he didn't think D was a good language.
There's no such thing as bad publicity. And my "opinions" weren't completely wrong. You can easily see this by writing a 5 LOC backend plugin for the 64-bit ARM backend of DMD. This plugin should send you email every time the compilations succeeds. When you compile this plugin, DMD should generate better whole program optimizations than GCC 4.5. The plugin should also use lambdas with a terser syntax than Haskell and its whole program type inference. The same heap allocating closure should also work with both D1 and D2. Did I forget to say that the plugin should also display the contents of some internal compiler struct with .stringof - luckily the construct is fully documented in the spec.
May 31 2010
parent BCS <none anon.com> writes:
Hello retard,

 Mon, 31 May 2010 13:57:34 -0400, Andrej Mitrovic wrote:
 
 retard Wrote:
 
 snip
 
Even though he said all of that, he wouldn't be here and post so often if he didn't think D was a good language.
There's no such thing as bad publicity. And my "opinions" weren't completely wrong. You can easily see this by writing a 5 LOC backend plugin for the 64-bit ARM backend of DMD. This plugin should send you email every time the compilations succeeds. When you compile this plugin, DMD should generate better whole program optimizations than GCC 4.5. The plugin should also use lambdas with a terser syntax than Haskell and its whole program type inference. The same heap allocating closure should also work with both D1 and D2. Did I forget to say that the plugin should also display the contents of some internal compiler struct with .stringof - luckily the construct is fully documented in the spec.
Would you like a kitchen sink with that? -- ... <IXOYE><
May 31 2010
prev sibling next sibling parent reply Bane <branimir.milosavljevic gmail.com> writes:
This reminds me of elementary school and those discussions "which
car/plane/tank is best". Pretty futile subject to begin with, as you cant
compare fruits and vegetables. And no matter what somebody say there will
always be some kid claiming opposite just for the sake of disagreeing. 

I guess troll got hungry.
May 31 2010
parent reply retard <re tard.com.invalid> writes:
Mon, 31 May 2010 14:19:22 -0400, Bane wrote:

 This reminds me of elementary school and those discussions "which
 car/plane/tank is best". Pretty futile subject to begin with, as you
 cant compare fruits and vegetables. And no matter what somebody say
 there will always be some kid claiming opposite just for the sake of
 disagreeing.
 
 I guess troll got hungry.
http://tinyurl.com/37lqc65 IMHO the original blog post was more trolling than my false opinions. I liked your critical way of thinking so much that I publicly admit that my post was a bit provocative. When you see this kind of articles, you should really ponder whether it makes sense for anyone to prove that a new favorite language beats everything ever built. Seriously, the argumentation was really sloppy. Languages should not be like religions. I find it so funny when people are desperately "protecting" their precious poor little D from the faceless evil trolls.
May 31 2010
parent Bane <branimir.milosavljevic gmail.com> writes:
 IMHO the original blog post was more trolling than my false opinions. I 
 liked your critical way of thinking so much that I publicly admit that my 
 post was a bit provocative.
Thank you for a compliment.
 When you see this kind of articles, you should really ponder whether it 
 makes sense for anyone to prove that a new favorite language beats 
 everything ever built. Seriously, the argumentation was really sloppy. 
 Languages should not be like religions. I find it so funny when people 
 are desperately "protecting" their precious poor little D from the 
 faceless evil trolls. 
I think that is consumer society problem. They (evil marketing dudes) brainwash people that new products are better than old, so they would buy new stuff. Its influence is in lot of areas of life, why not programming to. Or just Darwinist evolution approach believing that new things are better and smarter than old. Yea, right. As for trolls, they have their role in questioning things and annoying people that take things too seriously. Keep up the good work!
May 31 2010
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
On 5/31/10, retard <re tard.com.invalid> wrote:
 For example the lambda syntax is terribly verbose in D compared to Scala
 or Haskell.
Eh, one man's "terse" is another man's "unreadable".
May 31 2010
parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Adam Ruppe wrote:

 On 5/31/10, retard <re tard.com.invalid> wrote:
 For example the lambda syntax is terribly verbose in D compared to Scala
 or Haskell.
Eh, one man's "terse" is another man's "unreadable".
True, though I think that Haskell's lambda syntax is quite nice (I haven't used Scala, so I can't comment there). However, I don't think that it would really fit in D. Haskell uses type-inference for everything, so lambdas don't include types. And since D is statically typed and only uses type- inference with templates, it wouldn't work very well to use the same sort of syntax in D. What D has is still rather good though, just not as terse. I don't see you getting much terser in D without making it problematic. So, the level of terseness which is appropriate is also very context- dependent, not just programmer-dependent. - Jonathan M Davis
May 31 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:
 "Succinct: The language should not be verbose. This is very important. 
 Brevity is one reason why Python and Ruby are popular."
 
 For example the lambda syntax is terribly verbose in D compared to Scala 
 or Haskell.
Have you checked out APL? Here's the game of life in APL: http://upload.wikimedia.org/wikipedia/en/f/ff/LifeInApl.gif
May 31 2010
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
retard wrote:

<snip>

When you have to cherry-pick from 5 very different battle-tested languages and
a handful of the top compilers/vm's to bash a language that is barely finished,
then I'd say that language shows some promise.
Jun 01 2010
prev sibling next sibling parent Kagamin <spam here.lot> writes:
retard Wrote:

 D is very close to C. The productivity is much lower than with other 
 modern scripting or hybrid-functional languages.
 DMD is much slower than Sun Javac/Jvm 7, GNU GCC 4.5, and LLVM.
 "Succinct: The language should not be verbose. This is very important. 
 Brevity is one reason why Python and Ruby are popular."
 For example the lambda syntax is terribly verbose in D compared to Scala 
 or Haskell.
 Java 2-7 is very backwards compatible compared to D2.
 
Just one language :3
Jun 01 2010
prev sibling parent reply #ponce <nospam nospam.nospam> writes:
 For example the lambda syntax is terribly verbose in D compared to Scala 
 or Haskell.
 
It may seem surprising to you, but there is a lot of project who can't afford using Scala or Haskell. If you're constrained to use D at your dayjob, imagine what could be to be forced to use C++. Wonderful hours spent finding that your destructor failed because it called virtual functions, while your stack trace magically disappear and you have to wait recompilation for 10 min.
Jun 01 2010
parent retard <re tard.com.invalid> writes:
Tue, 01 Jun 2010 05:19:55 -0400, #ponce wrote:

 For example the lambda syntax is terribly verbose in D compared to
 Scala or Haskell.
 
 
It may seem surprising to you, but there is a lot of project who can't afford using Scala or Haskell. If you're constrained to use D at your dayjob, imagine what could be to be forced to use C++. Wonderful hours spent finding that your destructor failed because it called virtual functions, while your stack trace magically disappear and you have to wait recompilation for 10 min.
The world would be a better place if instead of shooting in your leg you shot your client's head off.
Jun 01 2010