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