www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Next Big Language

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/dsdd6/the_next_big_language_2010_edition/
Oct 17 2010
next sibling parent Peter Alexander <peter.alexander.au gmail.com> writes:
On 17/10/10 9:14 PM, Walter Bright wrote:

 http://www.reddit.com/r/programming/comments/dsdd6/the_next_big_language_2010_edition/


Andrei beat you to it about 5 hours ago :-)
Oct 17 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 Discusses a few languages including D: 
 http://www.reddit.com/r/programming/comments/dsdd6/the_next_big_language_2010_edition/


The "Next Big Language" will probably be JavaScript.

Bye,
bearophile
Oct 18 2010
next sibling parent Justin Johansson <no spam.com> writes:
On 18/10/2010 10:11 PM, bearophile wrote:

 Andrei:


 Discusses a few languages including D:
 http://www.reddit.com/r/programming/comments/dsdd6/the_next_big_language_2010_edition/


 The "Next Big Language" will probably be JavaScript.

 Bye,
 bearophile


What encourages you to say so.  JavaScript is already pretty
much ubiquitous so perhaps one might say that it is the
"Contemporary Big Language" but do you think it will become
even bigger (perhaps in its next version?) to take on the
title of the "Next Big Language" posthumously?

Regards, Justin
Oct 18 2010
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 10/18/2010 07:11 AM, bearophile wrote:

 The "Next Big Language" will probably be JavaScript.


I see JavaScript as being stuck in the browser for the foreseeable 
future. It does have some usage outside the browser, but not much.
Oct 18 2010
next sibling parent Emil Madsen <sovende gmail.com> writes:
I see a lot of applications going into the browser, in the future, but thats
maybe just me :)

On 18 October 2010 16:10, Jeff Nowakowski <jeff dilacero.org> wrote:


 On 10/18/2010 07:11 AM, bearophile wrote:


 The "Next Big Language" will probably be JavaScript.


 I see JavaScript as being stuck in the browser for the foreseeable future.
 It does have some usage outside the browser, but not much.




-- 
// Yours sincerely
// Emil 'Skeen' Madsen
Oct 18 2010
prev sibling next sibling parent reply Gianluigi <gianluigi grsoft.org> writes:
  Il 18/10/10 16.10, Jeff Nowakowski ha scritto:

 I see JavaScript as being stuck in the browser for the foreseeable 
 future. It does have some usage outside the browser, but not much.


Take a look at http://nodejs.org/, there's someone willing to use JS to 
build server side software ...

GR
Oct 18 2010
parent Jeff Nowakowski <jeff dilacero.org> writes:
On 10/18/2010 11:14 AM, Gianluigi wrote:

 Take a look at http://nodejs.org/, there's someone willing to use JS to
 build server side software ...


Yeah, I saw the Google Tech-talk for that. As I said, usage outside the 
browser exists, but not much. The talk had some interesting ideas, but I 
don't see why he chose JavaScript as the implementation language. He 
said C is a pain to work with, and I agree, but JavaScript seems like an 
odd fallback solution for server-side work.
Oct 18 2010
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Jeff Nowakowski (jeff dilacero.org)'s article

 On 10/18/2010 07:11 AM, bearophile wrote:

 The "Next Big Language" will probably be JavaScript.


 I see JavaScript as being stuck in the browser for the foreseeable
 future. It does have some usage outside the browser, but not much.


Gnome-Shell, a prototype Desktop Environment for Gnome3, is written in
Javascript
(and C for Clutter bindings); uses CSS for theming. Having seen some recent
demos
and screenshots of what people can do with it, the end result is quite
magnificent. At least, in my humble opinion. =)
Oct 18 2010
prev sibling parent Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 10/18/2010 7:11 AM, bearophile wrote:

 Andrei:


 Discusses a few languages including D:
 http://www.reddit.com/r/programming/comments/dsdd6/the_next_big_language_2010_edition/


 The "Next Big Language" will probably be JavaScript.

 Bye,
 bearophile


I love javascript for small-to-medium jobs (I even use it with Windows 
Scripting Host instead of batch files), but I'd hate to use something 
without static typing on a large project.

As the usual argument goes... change a function's name, arguments, or 
argument types and you don't know what else breaks until you're careful 
to run it through all of the possible scenarios.
Oct 18 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 Pascal - Provided a very good way to learn structured programming


Pascal today is a bit obsolete language to teach programming (even if
FreePascal compiles a Object Pascal updated in many useful ways). But recently
I have realized that the style of programming of Pascal is useful to
teach/train to use more often static memory. Dynamic allocation of memory (as
usually done in Python and even in D) is quite handy, but once you care a bit
for performance, you see that static/stack memory helps a lot.

And it's not just a matter of performance: my experience shows me that thinking
about some algorithms in term of static memory helps understand them better.
Understanding the bounds of memory used by an algorithm is not a secondary
thing, it's often tied to the structure of the algorithm. So often if you don't
understand clearly the invariants of how the algorithm uses the memory, you
have not fully understood the algorithm. Static memory asks to be more precise
about memory usages, and this helps you understand the algorithm better (and
will often improve the performance of your code too, even if you use Java).



 Scala - Seems to be the next big language in the JVM


It's an interesting language, but its type system is quite complex, maybe a bit
too much for the average programmer.

-----------------------

Justin Johansson:


 What encourages you to say so.  JavaScript is already pretty much ubiquitous
so perhaps one might say that it is the "Contemporary Big Language" but do you
think it will become even bigger (perhaps in its next version?) to take on the
title of the "Next Big Language" posthumously?<


JavaScript has to expland its usage still a lot in desktop and server-side
usages.

-----------------------

Fawzi Mohamed:


 I see a future for D in the HPC field,


For that few ideas from a good numerical computing languages like Chapel may
help D a lot.
http://en.wikipedia.org/wiki/Chapel_%28programming_language%29

Bye,
bearophile
Oct 18 2010
prev sibling next sibling parent reply eternium <swiftj19NOSPAM yahoo.com> writes:
Yao G. Wrote:


 On Sun, 17 Oct 2010 13:08:45 -0500, Andrej Mitrovic  
 <andrej.mitrovich gmail.com> wrote:
 

 I think it was a rather superficial review of all the languages. Did
 he even try any of them out, or did he just took a look at what
 wikipedia has to say?

 Here's my comment
 http://www.reddit.com/r/programming/comments/dsdd6/the_next_big_language_2010_edition/c12k68w

 On 10/17/10, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Discusses a few languages including D:
 http://www.reddit.com/r/programming/comments/dsdd6/the_next_big_language_2010_edition/




 
 Whenever I read a comment from that guy that post as eternium there, in  
 reddit, I have a sense of déjà vu. The same exact passive-agressive stance  
 with respect to D, the constant Walter/Andrei bashing, the ivory tower  
 snark comment, the "people posting in the newsgroup are n00bs, idiots,  
 fanboys"... Exactly the same comments as *someone* that post here, you  
 know who. It gets more sad if you look at his comments history and see  
 that like 80% of what he writes there, is just D bashing. At least he  
 should post with the same user name in both places :)


Dear Mister Conspiracy Guy,

I added more original sources to my posts as per Your request. Seemed to work
(already improved my reddit karma 3 units in short time). That particular ivory
tower quotation came from someone here.

I also do mention good things:

"Switching from C/C++ to D may improve your productivity in many cases." <-
http://www.reddit.com/r/programming/comments/dm9gh/whats_your_next_programming_language_and_why/c11czh9

"The D's type system supports immutability in a fine-grained manner. It makes
all kinds of optimizations possible. This system is impressive, and I have no
reason to believe that it wouldn't bring performance benefits in the future."
<- http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/c11d248

"Finally, I'd like to thank you very much for listening. I like D and I wish it
a bright future." <-
http://www.reddit.com/r/programming/comments/944gh/the_d_language_metaprogramming_language_is_d/c0bec00


Sometimes the rants hit the nail in the head (wasn't this fixed recently):

"You could at least set the executable flag for the Linux binaries to improve
user experience. Many would appreciate that and it's trivial to do e.g. with
the Linux version of zip." <-
http://www.reddit.com/r/programming/comments/9zqj0/the_state_of_d_programming_is_this_situation/c0f8wym

May I ask Your reddit nick? Couldn't find any Yao G. there.
Oct 18 2010
next sibling parent "Yao G." <yao.gomez spam.gmail.com> writes:
On Mon, 18 Oct 2010 12:50:43 -0500, eternium a.k.a. retard  
<swiftj19NOSPAM yahoo.com> wrote:


 I added more original sources to my posts as per Your request. Seemed to  
 work (already improved my reddit karma 3 units in short time).


Thank you!


 That particular ivory tower quotation came from someone here.


Link please?


 I also do mention good things:

 "Switching from C/C++ to D may improve your productivity in many cases."  
 <-  
 http://www.reddit.com/r/programming/comments/dm9gh/whats_your_next_programming_language_and_why/c11czh9

 "The D's type system supports immutability in a fine-grained manner. It  
 makes all kinds of optimizations possible. This system is impressive,  
 and I have no reason to believe that it wouldn't bring performance  
 benefits in the future." <-  
 http://www.reddit.com/r/programming/comments/dm8n8/the_many_faces_of_d_slides_pdf/c11d248

 "Finally, I'd like to thank you very much for listening. I like D and I  
 wish it a bright future." <-  
 http://www.reddit.com/r/programming/comments/944gh/the_d_language_metaprogramming_language_is_d/c0bec00


Yes. But it's pretty hard to look for the "good things" when you need to  
navigate in a sea of "not so good things".


 Sometimes the rants hit the nail in the head (wasn't this fixed  
 recently):

 "You could at least set the executable flag for the Linux binaries to  
 improve user experience. Many would appreciate that and it's trivial to  
 do e.g. with the Linux version of zip." <-  
 http://www.reddit.com/r/programming/comments/9zqj0/the_state_of_d_programming_is_this_situation/c0f8wym


See the post above.


 May I ask Your reddit nick? Couldn't find any Yao G. there.


I don't have one, but I'll create an account there pronto. Thanks for your  
concern retard... err... I mean, eternium.

-- 
Yao G.
Oct 18 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/18/10 12:50 CDT, eternium wrote:

 Yao G. Wrote:


[snip]

 Dear Mister Conspiracy Guy,

 I added more original sources to my posts as per Your request.


[snip]

Hey eternium -- thanks for dropping by. I see you have invested a good 
amount of time researching D, albeit in support for more negative than 
positive points.

But if anything being passionate against or in favor of something is at 
the end of the day being passionate about that something. (Think of 
relationships... :o)) I guarantee it would produce you more satisfaction 
to contribute in building something instead of painstakingly and pettily 
getting into fights on reddit, revisiting pages that nobody looks at 
anymore, counting your votes, and reveling in paltry victories in some 
meaningless argument or another. I mean look at "eternium"s posting 
history. Can you look at that and say "this makes me a happier person"?

You clearly know what you're talking about, and you have an interest in 
D. You know a good collection of arguments can be amassed against any 
language as there's no perfect one. That's easier but also less 
satisfying than taking something that you know has weaknesses and making 
it better. If you're bitter about something that can't be undone, I 
can't help but telling you that it's a place you want to move away from. 
But if you find it in yourself that you could help improve a language 
you have an interest in, bury the hatch and make yourself heard.


Andrei
Oct 18 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 18 Oct 2010 14:36:57 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 ...bury the hatch and...


Sorry, I can't let this one pass... bury the *hatchet* :)

This isn't Lost.

-Steve
Oct 18 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/18/10 13:45 CDT, Steven Schveighoffer wrote:

 On Mon, 18 Oct 2010 14:36:57 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 ...bury the hatch and...


 Sorry, I can't let this one pass... bury the *hatchet* :)

 This isn't Lost.

 -Steve


Ah, thanks. Hatchet, hatchet.

Andrei
Oct 18 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 18/10/2010 19:45, Steven Schveighoffer wrote:

 On Mon, 18 Oct 2010 14:36:57 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 ...bury the hatch and...


 Sorry, I can't let this one pass... bury the *hatchet* :)

 This isn't Lost.

 -Steve


LOOOOOOOOOOOOOOOL


Oh man, I miss that series, even though it was going downhill..

-- 
Bruno Medeiros - Software Engineer
Nov 17 2010
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Denis Koroskin Wrote:


 "After so many years being in development this is  
 still a b.s. I will never touch this language again"


Lucky is your friend, I see no feasible alternative to D.
Oct 18 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Justin Johansson


There is also a big problem with reconciling templated types with OO typed
hierarchies.  Often a dichotomy appears when templates and classes seem to
fight one another when you try to marriage the two idioms together (for better
or for worse but generally worse). :-(<


Right.

-------------

Peter Alexander:


I think it has very little to do with the syntax (although it certainly plays a
part).


The real problem with templates (in my opinion) is that they require a higher
level abstract view of programs that most programmers simply lack. I think this
is the same reason why functional programming escapes the masses, and why C is
still so popular.<

Some of the problems of C++ templates:
- The syntax is a big problem; if you want to use them to do complex things you
need to write lot of ugly code. The lack of basic constructs like static if
doesn't help at all.
- The semantics is not clean, there are several corner cases, that turn
template programming into a puzzle solving activity.
- C++ templates are a functional language, but the C++ compilers usually lacks
the normal tools a functional language needs, like a garbage collector and an
optimizer both designed for a functional language, and error messages good for
a functional language. This makes then slow for the compiler, and at
compile-time the compiler burns lot of RAM (they have improved a bit G++ 4.5,
as template instantiations are now looked up using hash tables:
http://cpptruths.blogspot.com/2010/03/faster-meta-programs-u
ing-gcc-45-and.html  but it's a long way to go).
- C++ templates are powerful, because templates templates are a peek into the
realm of higher order types (kinds), but there is not much typing on the types,
so bugs are common. The Concepts were a way to add a type system to template
arguments, but it has failed.
- C++ programmers sometimes don't know much about functional programming. But
in the end the complexity of functional programs written with C++ templates is
very limited, they are often almost trivial. What makes them hard to write is
not that, it's the way you have to write such little functional programs.

D2 improves the situation a bit (with constraints, a more consistant semantics,
a bit better syntax, static ifs, more template argument types, and some
shortcuts), but there's a long way to go still. Despite the constraints D
templates are still "dynamically kinded" (the enforcement is one way only, not
two way as in the Concepts, you may solve the problem a bit manually, as Andrei
has shown me), the compile-time GC is not good enough yet, lot of useless stuff
is left in the final binaries, etc.

D2 templates too may cause bloat, because there is no way to choose where you

templates (this may be good anyway, to keep both language and compiler simpler).

Bye,
bearophile
Oct 19 2010
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 19.10.2010 13:29, schrieb bearophile:

 Some of the problems of C++ templates:
 - The syntax is a big problem; if you want to use them to do complex things
you need to write lot of ugly code. The lack of basic constructs like static if
doesn't help at all.
 - The semantics is not clean, there are several corner cases, that turn
template programming into a puzzle solving activity.
 - C++ templates are a functional language, but the C++ compilers usually lacks
the normal tools a functional language needs, like a garbage collector and an
optimizer both designed for a functional language, and error messages good for
a functional language. This makes then slow for the compiler, and at
compile-time the compiler burns lot of RAM (they have improved a bit G++ 4.5,
as template instantiations are now looked up using hash tables:
http://cpptruths.blogspot.com/2010/03/faster-meta-programs-u
ing-gcc-45-and.html  but it's a long way to go).
 - C++ templates are powerful, because templates templates are a peek into the
realm of higher order types (kinds), but there is not much typing on the types,
so bugs are common. The Concepts were a way to add a type system to template
arguments, but it has failed.
 - C++ programmers sometimes don't know much about functional programming. But
in the end the complexity of functional programs written with C++ templates is
very limited, they are often almost trivial. What makes them hard to write is
not that, it's the way you have to write such little functional programs.


and that generates a very bad scenario for "templates"

because if you find (as an newbie)

a small and understandable template code example
-> these code normaly don't show the potential behind templates/generics...

and if you see code that realy profits from using templates/generics
you can't see the profit because its hidden under masses of C++ evil 
syntax orgies
Oct 19 2010
prev sibling parent Justin Johansson <no spam.com> writes:
On 19/10/2010 10:29 PM, bearophile wrote:

 Justin Johansson


 There is also a big problem with reconciling templated types with OO typed
hierarchies.  Often a dichotomy appears when templates and classes seem to
fight one another when you try to marriage the two idioms together (for better
or for worse but generally worse). :-(<


 Right.

 -------------

 Peter Alexander:


 I think it has very little to do with the syntax (although it certainly plays
a part).


 The real problem with templates (in my opinion) is that they require a higher
level abstract view of programs that most programmers simply lack. I think this
is the same reason why functional programming escapes the masses, and why C is
still so popular.<

 Some of the problems of C++ templates:
 - The syntax is a big problem; if you want to use them to do complex things
you need to write lot of ugly code. The lack of basic constructs like static if
doesn't help at all.
 - The semantics is not clean, there are several corner cases, that turn
template programming into a puzzle solving activity.
 - C++ templates are a functional language, but the C++ compilers usually lacks
the normal tools a functional language needs, like a garbage collector and an
optimizer both designed for a functional language, and error messages good for
a functional language. This makes then slow for the compiler, and at
compile-time the compiler burns lot of RAM (they have improved a bit G++ 4.5,
as template instantiations are now looked up using hash tables:
http://cpptruths.blogspot.com/2010/03/faster-meta-programs-u
ing-gcc-45-and.html  but it's a long way to go).
 - C++ templates are powerful, because templates templates are a peek into the
realm of higher order types (kinds), but there is not much typing on the types,
so bugs are common. The Concepts were a way to add a type system to template
arguments, but it has failed.
 - C++ programmers sometimes don't know much about functional programming. But
in the end the complexity of functional programs written with C++ templates is
very limited, they are often almost trivial. What makes them hard to write is
not that, it's the way you have to write such little functional programs.

 D2 improves the situation a bit (with constraints, a more consistant
semantics, a bit better syntax, static ifs, more template argument types, and
some shortcuts), but there's a long way to go still. Despite the constraints D
templates are still "dynamically kinded" (the enforcement is one way only, not
two way as in the Concepts, you may solve the problem a bit manually, as Andrei
has shown me), the compile-time GC is not good enough yet, lot of useless stuff
is left in the final binaries, etc.

 D2 templates too may cause bloat, because there is no way to choose where you

templates (this may be good anyway, to keep both language and compiler simpler).

 Bye,
 bearophile



You are a smart person bearophile, much smarter than me.
Cheers, Justin
Oct 19 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 Knowing the syntax and knowing how to use a language are two very
 different things. If you're a newbie you can learn the C syntax in a
 couple of weeks, but you would be very wrong to assume that you know
 e.g. "70%" of C, and that you could read any C project and understand
 it well.


To become a fluent Python programmer, that knows the Python style well and uses
well the standard library, you need quite more than one month, probably many
months (the more you exercise daily the faster you get there, but there's often
a speed limit), you may even need two years.

The point I was trying to express is that from what I have seen people are able
to learn to program Python (this means quite more than just the syntax) in
*much* less time it takes to learn C++/D. And this has precise causes.


Regarding C, it's a bit like learning Scheme, you need only few months to learn
C syntax even if you don't know a prior language. Then you may need two years
to write some bigger C programs. And then you have just started learning C.
Learning to program in C feels a bit like a ladder of Initiation Levels, even
after many years you are able to find more advanced ways to use C.

Few years ago I have found the good "C tips" (http://users.bestweb.net/~ctips/
) that I have shown in this newsgroup too. They have taught me that there are
ways to write very large C programs that work. Those tips show ways to tame C
and turn it into a more reliable language. But they require very rigorous C
programmers.

Despite the advanced contents of those tips, later I have found ways to write
good C programs less hairy too (see the C source code of the Python deque in
the collections module, written by the very good Raymond Hettinger, that avoids
many of the complexities seen in those C tips, designed for far bigger
programs: http://svn.python.org/view/*checkout*/python/trunk/Modules/_collectionsmodule.c?conte
t-type=text%2Fplain ). Along the way you probably understand why the classic C
Unix tools are so small.

Later I have found the very good "performance engineering" lectures
(http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-172-performance-engineering-of-software-systems-fall
2009/lecture-notes/ ), plus I have heavily performance-tuned some small C
programs, all this has shown me new ways to program in C. And thanks to dlibs1
(and std.algorithm of Phobos2) I've seen that while those optimizations are
sometimes useful, you usually want to use them only in a small percentage of
the code of a program, all the other parts of a C program are better written in
a higher level. And yes, you may write higher level style code even in C.
Recently I have even written C code in D-style. And I guess you may write C
code composed just of pure functions that manage immutable data (despite I've
never seen such C programs), or you may write quite pure OOP programs in C (I
have seen a bit of this kind of code), just like you may use good structured
programming in assembly.

So now I presume there is one even higher level of C programming that I'm not
seeing yet :-)

In the end C is a computationally complete language, you may use it to encode
any algorithm, so probably there's no end in the number of abstractions or ways
to write programs in C. Two hundred years from now Alien people coming from a
far away star may use a C-style language to write code in ways we can't even
think about today :-)

Bye,
bearophile
Oct 19 2010
next sibling parent reply Emil Madsen <sovende gmail.com> writes:
So... When are you writing a book?
Emil Madsen

On 19 October 2010 13:49, bearophile <bearophileHUGS lycos.com> wrote:


 Andrej Mitrovic:


 Knowing the syntax and knowing how to use a language are two very
 different things. If you're a newbie you can learn the C syntax in a
 couple of weeks, but you would be very wrong to assume that you know
 e.g. "70%" of C, and that you could read any C project and understand
 it well.


 To become a fluent Python programmer, that knows the Python style well and
 uses well the standard library, you need quite more than one month, probably
 many months (the more you exercise daily the faster you get there, but
 there's often a speed limit), you may even need two years.

 The point I was trying to express is that from what I have seen people are
 able to learn to program Python (this means quite more than just the syntax)
 in *much* less time it takes to learn C++/D. And this has precise causes.


 Regarding C, it's a bit like learning Scheme, you need only few months to
 learn C syntax even if you don't know a prior language. Then you may need
 two years to write some bigger C programs. And then you have just started
 learning C. Learning to program in C feels a bit like a ladder of Initiation
 Levels, even after many years you are able to find more advanced ways to use
 C.

 Few years ago I have found the good "C tips" (
 http://users.bestweb.net/~ctips/ ) that I have shown in this newsgroup
 too. They have taught me that there are ways to write very large C programs
 that work. Those tips show ways to tame C and turn it into a more reliable
 language. But they require very rigorous C programmers.

 Despite the advanced contents of those tips, later I have found ways to
 write good C programs less hairy too (see the C source code of the Python
 deque in the collections module, written by the very good Raymond Hettinger,
 that avoids many of the complexities seen in those C tips, designed for far
 bigger programs:
 http://svn.python.org/view/*checkout*/python/trunk/Modules/_collectionsmodule.c?content
type=text%2Fplain). Along the way you probably understand why the classic C
Unix tools are so
 small.

 Later I have found the very good "performance engineering" lectures (
 http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-172-performance-engineering-of-software-systems-fall-2
09/lecture-notes/), plus I have heavily performance-tuned some small C
programs, all this has
 shown me new ways to program in C. And thanks to dlibs1 (and std.algorithm
 of Phobos2) I've seen that while those optimizations are sometimes useful,
 you usually want to use them only in a small percentage of the code of a
 program, all the other parts of a C program are better written in a higher
 level. And yes, you may write higher level style code even in C. Recently I
 have even written C code in D-style. And I guess you may write C code
 composed just of pure functions that manage immutable data (despite I've
 never seen such C programs), or you may write quite pure OOP programs in C
 (I have seen a bit of this kind of code), just like you may use good
 structured programming in assembly.

 So now I presume there is one even higher level of C programming that I'm
 not seeing yet :-)

 In the end C is a computationally complete language, you may use it to
 encode any algorithm, so probably there's no end in the number of
 abstractions or ways to write programs in C. Two hundred years from now
 Alien people coming from a far away star may use a C-style language to write
 code in ways we can't even think about today :-)

 Bye,
 bearophile




-- 
// Yours sincerely
// Emil 'Skeen' Madsen
Oct 19 2010
parent reply Justin Johansson <no spam.com> writes:
On 19/10/2010 11:16 PM, Emil Madsen wrote:

 So... When are you writing a book?
 Emil Madsen


Hear, hear, I concert.  When is bearophile going to
write a book?  Alongside you I will be sure to
purchase a copy.

Cheers, Justin :-)
Oct 19 2010
next sibling parent retard <re tard.com.invalid> writes:
Wed, 20 Oct 2010 00:02:23 +1100, Justin Johansson wrote:


 On 19/10/2010 11:16 PM, Emil Madsen wrote:

 So... When are you writing a book?
 Emil Madsen


 
 Hear, hear, I concert.  When is bearophile going to write a book? 
 Alongside you I will be sure to purchase a copy.
 
 Cheers, Justin :-)


Wouldn't be a bad idea. He has spent enormous time studying recently 
"invented" concepts and concepts important to the younger generations and 
the early adopters. It would be a good time to summarize a bit.
Oct 19 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Justin Johansson wrote:

 On 19/10/2010 11:16 PM, Emil Madsen wrote:

 So... When are you writing a book?
 Emil Madsen


 
 Hear, hear, I concert.  When is bearophile going to
 write a book?  Alongside you I will be sure to
 purchase a copy.


I think that would be a great idea! I'd buy the book, too. Bearophile, how
about 
it? Or at a bear (!) minimum, how about writing a series of articles?
Oct 19 2010
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Walter Bright wrote:

 Bearophile,
 how about it? Or at a bear (!) minimum, how about writing a series of
 articles?


I promise to translate them to Turkish promptly. :)

Ali
Nov 02 2010
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/19/10, bearophile <bearophileHUGS lycos.com> wrote:

 Andrej Mitrovic:


 Knowing the syntax and knowing how to use a language are two very
 different things. If you're a newbie you can learn the C syntax in a
 couple of weeks, but you would be very wrong to assume that you know
 e.g. "70%" of C, and that you could read any C project and understand
 it well.


 The point I was trying to express is that from what I have seen people are
 able to learn to program Python (this means quite more than just the syntax)
 in *much* less time it takes to learn C++/D. And this has precise causes.


It took me only a few days to read the Dive Into Python tutorial + the
Python tutorial on the website, the syntax is very easy to learn.
After that, I quickly got into using Python with QT, and it was damn
simple to start making some functional GUI-enabled apps. So, I agree,
Python is *much* easier to learn than C++. Although it would probably
take a few years before I would know many of the Python idioms and
write really "Pythonic" code.

I don't know about Python vs D. Coming from C/Python and having some
basic knowledge of C++ it wasn't that hard to get adjusted to D at
all. That being said, there really aren't any beginner books/tutorials
that I know of that target D2 yet (maybe one of those published
Japanese/Turkish ones do target newbies..?). TDPL is certainly not a
book for someone completely new to programming.

I have to say though, the Python documentation is just *fantastic*
(although I've heard some people disagree). It covers just about
everything you need to know (batteries included!), and there's always
instructions on how to use the library and the interpreter itself.
You're rarely left alone with a definition of some function without an
example or two + a thorough explanation on how the example works. I
really wish we had this for D2.
Oct 19 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 the Python documentation is just *fantastic*
 (although I've heard some people disagree). It covers just about
 everything you need to know (batteries included!), and there's always
 instructions on how to use the library and the interpreter itself.
 You're rarely left alone with a definition of some function without an
 example or two + a thorough explanation on how the example works. I
 really wish we had this for D2.


Python docs are good enough, but not fantastic. There are hundreds of Python
std lib features that don't have an example or have a not good enough example.
The documentation of Delphi written by Borland was much better (generally
Borland documentation was good). But Python is free (as in beer), so I don't
complain (and people are welcome to improve Python docs).

Bye,
bearophile
Oct 19 2010
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
They are fantastic in comparison to D's documentation. :-)

On 10/19/10, bearophile <bearophileHUGS lycos.com> wrote:

 Andrej Mitrovic:


 the Python documentation is just *fantastic*
 (although I've heard some people disagree). It covers just about
 everything you need to know (batteries included!), and there's always
 instructions on how to use the library and the interpreter itself.
 You're rarely left alone with a definition of some function without an
 example or two + a thorough explanation on how the example works. I
 really wish we had this for D2.


 Python docs are good enough, but not fantastic. There are hundreds of Python
 std lib features that don't have an example or have a not good enough
 example. The documentation of Delphi written by Borland was much better
 (generally Borland documentation was good). But Python is free (as in beer),
 so I don't complain (and people are welcome to improve Python docs).

 Bye,
 bearophile
Oct 19 2010
prev sibling parent Gour <gour atmarama.net> writes:
On Tue, 19 Oct 2010 13:13:35 -0400

 "bearophile" =3D=3D bearophile <bearophileHUGS lycos.com> wrote:












bearophile> Python docs are good enough, but not fantastic. There are
bearophile> hundreds of Python std lib features that don't have an
bearophile> example or have a not good enough example.=20

You can explore Haskell's libs if you're missing some examples here
and there. :-)


Sincerely,
Gour

--=20

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------
Oct 19 2010
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Andrej Mitrovic wrote:

 there really aren't any beginner books/tutorials
 that I know of that target D2 yet (maybe one of those published
 Japanese/Turkish ones do target newbies..?).


Thanks for the recognition. :)

The Turkish tutorial targets the novice and attempts to teach 
programming with D. [1]

My biggest frustration is that std.cstream will be deprecated, and there 
will be no novice-friendly console IO functions left.

Ali

[1] http://ddili.org/ders/d/index.html
Nov 02 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 The point I was trying to express is that from what I have seen people are
 able to learn to program Python (this means quite more than just the syntax)
 in *much* less time it takes to learn C++/D. And this has precise causes.


Time will tell how long it will take people to become idiomatically proficient 
in D. But also consider that Andrei's book "Modern C++ Design" completely 
changed the idiomatic way people wrote C++ programs. A 1990's state of the art 
C++ program is very different from a 2010 one.

We've only just begun figuring out the right way to write D programs.
Oct 19 2010
next sibling parent Gour <gour atmarama.net> writes:
On Tue, 19 Oct 2010 11:06:46 -0700

 "Walter" =3D=3D Walter Bright <newshound2 digitalmars.com> wrote:












Walter> We've only just begun figuring out the right way to write D
Walter> programs.

No worries about idiomatic D here...just gives us 64bit compiler an
GUI (QtD) lib so we can write...We'll optimize later. :-)


Sincerely,
Gour

--=20

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------
Oct 19 2010
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 10/19/2010 09:06 PM, Walter Bright wrote:

 bearophile wrote:

 The point I was trying to express is that from what I have seen people
 are
 able to learn to program Python (this means quite more than just the
 syntax)
 in *much* less time it takes to learn C++/D. And this has precise causes.


 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++ programs.
 A 1990's state of the art C++ program is very different from a 2010 one.

 We've only just begun figuring out the right way to write D programs.


That is funny. Now and then you and Andrei talk so confidently about Go, 

couple of lines in those languages. At the same time, you are claiming 
that it takes years to even start to learn a programming language. Sure, 
it is not problems with D that make it difficult to use. We simply don't 
know how to program in D yet, after several years of doing just that.

With all due respect for Andrei, I doubt that it is his book that 
completely changed the way people wrote C++ programs. It was 
influential, right, but it was really not a single factor. And some of 
ideas presented in that book are avoided by reasonable programmers.

Please stop so shamelessly advertising each other. Thanks!
Oct 19 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/19/10 14:04 CDT, Max Samukha wrote:

 On 10/19/2010 09:06 PM, Walter Bright wrote:

 bearophile wrote:

 The point I was trying to express is that from what I have seen people
 are
 able to learn to program Python (this means quite more than just the
 syntax)
 in *much* less time it takes to learn C++/D. And this has precise
 causes.


 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++ programs.
 A 1990's state of the art C++ program is very different from a 2010 one.

 We've only just begun figuring out the right way to write D programs.


 That is funny. Now and then you and Andrei talk so confidently about Go,

 couple of lines in those languages. At the same time, you are claiming
 that it takes years to even start to learn a programming language. Sure,
 it is not problems with D that make it difficult to use. We simply don't
 know how to program in D yet, after several years of doing just that.


I agree this seems to be a contradiction. Haskell is a fairly mature 
language building on a staunch pure functional base so many of its 

it's not difficult to learn from the perspective of the languages that 
influence it. Go is a small language that has one defining feature (the 
implicit signature conformance) that does add a certain flavor but is 
understood and has been experimented with in other languages.

D has added a lot in the direction of generics, and by their nature 
generics interact heavily with the rest of the language. I agree it is 
taking time to get to best use of such, but it's not wasted time because 
it marks real progress. For example, code using the relatively new 
template constraints is better than code that didn't use them.


 With all due respect for Andrei, I doubt that it is his book that
 completely changed the way people wrote C++ programs. It was
 influential, right, but it was really not a single factor. And some of
 ideas presented in that book are avoided by reasonable programmers.

 Please stop so shamelessly advertising each other. Thanks!


Sorry. Do I advertise Walter that frequently?


Andrei
Oct 19 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 19 October 2010 12:53:41 Andrei Alexandrescu wrote:

 On 10/19/10 14:04 CDT, Max Samukha wrote:

 On 10/19/2010 09:06 PM, Walter Bright wrote:

 bearophile wrote:

 The point I was trying to express is that from what I have seen people
 are
 able to learn to program Python (this means quite more than just the
 syntax)
 in *much* less time it takes to learn C++/D. And this has precise
 causes.


 
 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++ programs.
 A 1990's state of the art C++ program is very different from a 2010 one.
 
 We've only just begun figuring out the right way to write D programs.


 
 That is funny. Now and then you and Andrei talk so confidently about Go,

 couple of lines in those languages. At the same time, you are claiming
 that it takes years to even start to learn a programming language. Sure,
 it is not problems with D that make it difficult to use. We simply don't
 know how to program in D yet, after several years of doing just that.


 
 I agree this seems to be a contradiction. Haskell is a fairly mature
 language building on a staunch pure functional base so many of its

 it's not difficult to learn from the perspective of the languages that
 influence it. Go is a small language that has one defining feature (the
 implicit signature conformance) that does add a certain flavor but is
 understood and has been experimented with in other languages.
 
 D has added a lot in the direction of generics, and by their nature
 generics interact heavily with the rest of the language. I agree it is
 taking time to get to best use of such, but it's not wasted time because
 it marks real progress. For example, code using the relatively new
 template constraints is better than code that didn't use them.
 

 With all due respect for Andrei, I doubt that it is his book that
 completely changed the way people wrote C++ programs. It was
 influential, right, but it was really not a single factor. And some of
 ideas presented in that book are avoided by reasonable programmers.
 
 Please stop so shamelessly advertising each other. Thanks!


 
 Sorry. Do I advertise Walter that frequently?


Both of you do periodically say something about what the other has done in the 
past, but I don't get the impression that you're ever explicitly trying to make 
the other person look good or "advertise" them. Others may see it differently 
though.

And while in many ways, Modern C++ was a game-changer, I've never worked with 
anyone who really uses the stuff it talks about. In my experience with C++ code 
in production code, templates get used when they're necessary but that they're 
generally avoided. Of course, given how bad some of the code I've seen is, I 
definitely don't _want_ a lot of the people who wrote it messing around with 
heavily-templated code, but regardless, as major as the ideas in Modern C++
are, 
I think that there are a lot of C++ programmers out who never use them. They're 
just too complicated for a lot of people. Hopefully D manages to make such 
metaprogramming sane enough that your average D programmer won't freak out
about 
template metaprogramming in the way many C++ programmers do.

- Jonathan M Davis
Oct 19 2010
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
Sorry but I have to disagree.

Actually after reading TDPL I got the impression that at the semantic level, 
D is not that
much easier than C++.

It does not make a difference for people that myself that are quite 
comfortable with C++,
and all its idioms, but I think for the average programmer they are also 
complex.

Which does not rule out people using D, after all you need to have the right 
background
for doing proper programming.

--
Paulo

"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.735.1287519617.858.digitalmars-d puremagic.com...

 On Tuesday 19 October 2010 12:53:41 Andrei Alexandrescu wrote:

 On 10/19/10 14:04 CDT, Max Samukha wrote:

 On 10/19/2010 09:06 PM, Walter Bright wrote:

 bearophile wrote:

 The point I was trying to express is that from what I have seen 
 people
 are
 able to learn to program Python (this means quite more than just the
 syntax)
 in *much* less time it takes to learn C++/D. And this has precise
 causes.


 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++ 
 programs.
 A 1990's state of the art C++ program is very different from a 2010 
 one.

 We've only just begun figuring out the right way to write D programs.


 That is funny. Now and then you and Andrei talk so confidently about 
 Go,

 couple of lines in those languages. At the same time, you are claiming
 that it takes years to even start to learn a programming language. 
 Sure,
 it is not problems with D that make it difficult to use. We simply 
 don't
 know how to program in D yet, after several years of doing just that.


 I agree this seems to be a contradiction. Haskell is a fairly mature
 language building on a staunch pure functional base so many of its

 it's not difficult to learn from the perspective of the languages that
 influence it. Go is a small language that has one defining feature (the
 implicit signature conformance) that does add a certain flavor but is
 understood and has been experimented with in other languages.

 D has added a lot in the direction of generics, and by their nature
 generics interact heavily with the rest of the language. I agree it is
 taking time to get to best use of such, but it's not wasted time because
 it marks real progress. For example, code using the relatively new
 template constraints is better than code that didn't use them.


 With all due respect for Andrei, I doubt that it is his book that
 completely changed the way people wrote C++ programs. It was
 influential, right, but it was really not a single factor. And some of
 ideas presented in that book are avoided by reasonable programmers.

 Please stop so shamelessly advertising each other. Thanks!


 Sorry. Do I advertise Walter that frequently?


 Both of you do periodically say something about what the other has done in 
 the
 past, but I don't get the impression that you're ever explicitly trying to 
 make
 the other person look good or "advertise" them. Others may see it 
 differently
 though.

 And while in many ways, Modern C++ was a game-changer, I've never worked 
 with
 anyone who really uses the stuff it talks about. In my experience with C++ 
 code
 in production code, templates get used when they're necessary but that 
 they're
 generally avoided. Of course, given how bad some of the code I've seen is, 
 I
 definitely don't _want_ a lot of the people who wrote it messing around 
 with
 heavily-templated code, but regardless, as major as the ideas in Modern 
 C++ are,
 I think that there are a lot of C++ programmers out who never use them. 
 They're
 just too complicated for a lot of people. Hopefully D manages to make such
 metaprogramming sane enough that your average D programmer won't freak out 
 about
 template metaprogramming in the way many C++ programmers do.

 - Jonathan M Davis
Oct 20 2010
next sibling parent reply so <so so.do> writes:
IMHO one should not try to find a PL that is easy, what a programmer needs  
is a language that makes things easier. If you dive into high  
performance/flexible/efficient/platform specific... coding nothing will be  
easy anyway.

What makes a language easy/hard is mostly the crucial things it can do,  
just think about C, it has a syntax not hard to learn and keywords not  
that many, but not many people i know can say C is easier than others.

D does a great job on templates and makes them so easy, wouldn't even  
compare to other languages with template support.

On Wed, 20 Oct 2010 13:57:16 +0300, Paulo Pinto <pjmlp progtools.org>  
wrote:


 Sorry but I have to disagree.

 Actually after reading TDPL I got the impression that at the semantic  
 level,
 D is not that
 much easier than C++.

 It does not make a difference for people that myself that are quite
 comfortable with C++,
 and all its idioms, but I think for the average programmer they are also
 complex.

 Which does not rule out people using D, after all you need to have the  
 right
 background
 for doing proper programming.

 --
 Paulo

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.735.1287519617.858.digitalmars-d puremagic.com...

 On Tuesday 19 October 2010 12:53:41 Andrei Alexandrescu wrote:

 On 10/19/10 14:04 CDT, Max Samukha wrote:

 On 10/19/2010 09:06 PM, Walter Bright wrote:

 bearophile wrote:

 The point I was trying to express is that from what I have seen
 people
 are
 able to learn to program Python (this means quite more than just  






 the

 syntax)
 in *much* less time it takes to learn C++/D. And this has precise
 causes.


 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++
 programs.
 A 1990's state of the art C++ program is very different from a 2010
 one.

 We've only just begun figuring out the right way to write D  




 programs.

 That is funny. Now and then you and Andrei talk so confidently about
 Go,



 than a

 couple of lines in those languages. At the same time, you are  


 claiming

 that it takes years to even start to learn a programming language.
 Sure,
 it is not problems with D that make it difficult to use. We simply
 don't
 know how to program in D yet, after several years of doing just that.


 I agree this seems to be a contradiction. Haskell is a fairly mature
 language building on a staunch pure functional base so many of its

 it's not difficult to learn from the perspective of the languages that
 influence it. Go is a small language that has one defining feature (the
 implicit signature conformance) that does add a certain flavor but is
 understood and has been experimented with in other languages.

 D has added a lot in the direction of generics, and by their nature
 generics interact heavily with the rest of the language. I agree it is
 taking time to get to best use of such, but it's not wasted time  
 because
 it marks real progress. For example, code using the relatively new
 template constraints is better than code that didn't use them.


 With all due respect for Andrei, I doubt that it is his book that
 completely changed the way people wrote C++ programs. It was
 influential, right, but it was really not a single factor. And some  


 of

 ideas presented in that book are avoided by reasonable programmers.

 Please stop so shamelessly advertising each other. Thanks!


 Sorry. Do I advertise Walter that frequently?


 Both of you do periodically say something about what the other has done  
 in
 the
 past, but I don't get the impression that you're ever explicitly trying  
 to
 make
 the other person look good or "advertise" them. Others may see it
 differently
 though.

 And while in many ways, Modern C++ was a game-changer, I've never worked
 with
 anyone who really uses the stuff it talks about. In my experience with  
 C++
 code
 in production code, templates get used when they're necessary but that
 they're
 generally avoided. Of course, given how bad some of the code I've seen  
 is,
 I
 definitely don't _want_ a lot of the people who wrote it messing around
 with
 heavily-templated code, but regardless, as major as the ideas in Modern
 C++ are,
 I think that there are a lot of C++ programmers out who never use them.
 They're
 just too complicated for a lot of people. Hopefully D manages to make  
 such
 metaprogramming sane enough that your average D programmer won't freak  
 out
 about
 template metaprogramming in the way many C++ programmers do.

 - Jonathan M Davis





-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 20 2010
parent reply retard <re tard.com.invalid> writes:
Wed, 20 Oct 2010 14:57:10 +0300, so wrote:


 IMHO one should not try to find a PL that is easy, what a programmer
 needs is a language that makes things easier. If you dive into high
 performance/flexible/efficient/platform specific... coding nothing will
 be easy anyway.
 
 What makes a language easy/hard is mostly the crucial things it can do,
 just think about C, it has a syntax not hard to learn and keywords not
 that many, but not many people i know can say C is easier than others.
 
 D does a great job on templates and makes them so easy, wouldn't even
 compare to other languages with template support.


Other languages with template support? That is C++ ? Obj-C++ ?

Wikipedia mentions:

"Template metaprogramming is a metaprogramming technique in which 
templates are used by a compiler to generate temporary source code, which 
is merged by the compiler with the rest of the source code and then 
compiled. The output of these templates include compile-time constants, 
data structures, and complete functions.

The use of templates can be thought of as compile-time execution. The 
technique is used by a number of languages, the best-known being C++, but 
also Curl, D, Eiffel, Haskell, ML and XL."

Eiffer, Haskell, and ML definitely don't have templates. Template Haskell 
supports a different kind of TMP, though.

So the templates in D are better than in C++, Curl, and XL? I have zero 
experience with those two other languages, so it's hard to say.
Oct 20 2010
next sibling parent so <so so.do> writes:
Yes i meant C++ actually, but you can include here every other language  
because the point is not having templates, having it in a powerful  
environment.

For a language it shouldn't be that hard to have a generic syntax (lets  
call it templates in here) much better than D, but if you sacrifice the  
power of C just to have it, that wouldn't be a fair deal would it? :)

On Wed, 20 Oct 2010 15:37:22 +0300, retard <re tard.com.invalid> wrote:


 Wed, 20 Oct 2010 14:57:10 +0300, so wrote:


 IMHO one should not try to find a PL that is easy, what a programmer
 needs is a language that makes things easier. If you dive into high
 performance/flexible/efficient/platform specific... coding nothing will
 be easy anyway.

 What makes a language easy/hard is mostly the crucial things it can do,
 just think about C, it has a syntax not hard to learn and keywords not
 that many, but not many people i know can say C is easier than others.

 D does a great job on templates and makes them so easy, wouldn't even
 compare to other languages with template support.


 Other languages with template support? That is C++ ? Obj-C++ ?

 Wikipedia mentions:

 "Template metaprogramming is a metaprogramming technique in which
 templates are used by a compiler to generate temporary source code, which
 is merged by the compiler with the rest of the source code and then
 compiled. The output of these templates include compile-time constants,
 data structures, and complete functions.

 The use of templates can be thought of as compile-time execution. The
 technique is used by a number of languages, the best-known being C++, but
 also Curl, D, Eiffel, Haskell, ML and XL."

 Eiffer, Haskell, and ML definitely don't have templates. Template Haskell
 supports a different kind of TMP, though.

 So the templates in D are better than in C++, Curl, and XL? I have zero
 experience with those two other languages, so it's hard to say.



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 20 2010
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
Eiffel does have templates, as in generic types.

Or do you mean the compile time trick that C++ templates allow, thus opening 
the door for
the meta programming done at compile time?


"retard" <re tard.com.invalid> wrote in message 
news:i9mnq2$2m3a$1 digitalmars.com...

 Wed, 20 Oct 2010 14:57:10 +0300, so wrote:


 IMHO one should not try to find a PL that is easy, what a programmer
 needs is a language that makes things easier. If you dive into high
 performance/flexible/efficient/platform specific... coding nothing will
 be easy anyway.

 What makes a language easy/hard is mostly the crucial things it can do,
 just think about C, it has a syntax not hard to learn and keywords not
 that many, but not many people i know can say C is easier than others.

 D does a great job on templates and makes them so easy, wouldn't even
 compare to other languages with template support.


 Other languages with template support? That is C++ ? Obj-C++ ?

 Wikipedia mentions:

 "Template metaprogramming is a metaprogramming technique in which
 templates are used by a compiler to generate temporary source code, which
 is merged by the compiler with the rest of the source code and then
 compiled. The output of these templates include compile-time constants,
 data structures, and complete functions.

 The use of templates can be thought of as compile-time execution. The
 technique is used by a number of languages, the best-known being C++, but
 also Curl, D, Eiffel, Haskell, ML and XL."

 Eiffer, Haskell, and ML definitely don't have templates. Template Haskell
 supports a different kind of TMP, though.

 So the templates in D are better than in C++, Curl, and XL? I have zero
 experience with those two other languages, so it's hard to say.
Oct 20 2010
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday 20 October 2010 22:47:15 Paulo Pinto wrote:

 Eiffel does have templates, as in generic types.
 
 Or do you mean the compile time trick that C++ templates allow, thus
 opening the door for
 the meta programming done at compile time?


Templates and generics are two separate - albeit related - things. Templates 
generate code whereas generics allow you to use multiple types with the same 
code (be it by generating code or by actually making them share code). C++ 
templates happen to allow for metaprogramming beyond that, but I don't think 
that that's necessary for a language to be considered to have templates. The
key 
thing is that templates _generate_ code whereas generics can simply make 
multiple types use the same code. C++ and D are the only languages that I'm 
aware of which have templates. Other languages with generics generally don't
use 
templates to have generics.

- Jonathan M Davis
Oct 20 2010
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
Sorry but I still don't get it.

Do you mean that the types that erased and the same code is generated?

Then let me say that .Net generics get generated on the fly and JITed for 
each
different type.

Eiffel and Modula-3 generics also have specific generated code for each 
type.

The major difference regarding C++ code is that the linkers are smarter and 
are
able to remove duplicates of the generated code for the same set of type 
arguments.

--
Paulo

"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.755.1287643587.858.digitalmars-d puremagic.com...

 On Wednesday 20 October 2010 22:47:15 Paulo Pinto wrote:

 Eiffel does have templates, as in generic types.

 Or do you mean the compile time trick that C++ templates allow, thus
 opening the door for
 the meta programming done at compile time?


 Templates and generics are two separate - albeit related - things. 
 Templates
 generate code whereas generics allow you to use multiple types with the 
 same
 code (be it by generating code or by actually making them share code). C++
 templates happen to allow for metaprogramming beyond that, but I don't 
 think
 that that's necessary for a language to be considered to have templates. 
 The key
 thing is that templates _generate_ code whereas generics can simply make
 multiple types use the same code. C++ and D are the only languages that 
 I'm
 aware of which have templates. Other languages with generics generally 
 don't use
 templates to have generics.

 - Jonathan M Davis
Oct 21 2010
next sibling parent reply Gary Whatmore <no spam.spam> writes:
What's the difference between:

type polymorphism
parametric polymorphism
ad-hoc polymorphism
generics
c++ templates
d style templates
other templates (are there?)


real name and how to compare? Is D most expressive? I bet it is.

 - G.W.

Paulo Pinto Wrote:


 Sorry but I still don't get it.
 
 Do you mean that the types that erased and the same code is generated?
 
 Then let me say that .Net generics get generated on the fly and JITed for 
 each
 different type.
 
 Eiffel and Modula-3 generics also have specific generated code for each 
 type.
 
 The major difference regarding C++ code is that the linkers are smarter and 
 are
 able to remove duplicates of the generated code for the same set of type 
 arguments.
 
 --
 Paulo
 
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
 news:mailman.755.1287643587.858.digitalmars-d puremagic.com...

 On Wednesday 20 October 2010 22:47:15 Paulo Pinto wrote:

 Eiffel does have templates, as in generic types.

 Or do you mean the compile time trick that C++ templates allow, thus
 opening the door for
 the meta programming done at compile time?


 Templates and generics are two separate - albeit related - things. 
 Templates
 generate code whereas generics allow you to use multiple types with the 
 same
 code (be it by generating code or by actually making them share code). C++
 templates happen to allow for metaprogramming beyond that, but I don't 
 think
 that that's necessary for a language to be considered to have templates. 
 The key
 thing is that templates _generate_ code whereas generics can simply make
 multiple types use the same code. C++ and D are the only languages that 
 I'm
 aware of which have templates. Other languages with generics generally 
 don't use
 templates to have generics.

 - Jonathan M Davis
Oct 21 2010
next sibling parent reply Gary Whatmore <no spam.spam> writes:
I forgot Scala. They say Scala can  specialize without type erasure and it has
variance polymorphism. What are these? Sounds as if Scala is getting closer to
C++/D (instantiation and link-time optimization) and we need to fight back to
make our language more expressive.

 - G.W.

Gary Whatmore Wrote:


 What's the difference between:
 
 type polymorphism
 parametric polymorphism
 ad-hoc polymorphism
 generics
 c++ templates
 d style templates
 other templates (are there?)
 

real name and how to compare? Is D most expressive? I bet it is.
 
  - G.W.
 
 Paulo Pinto Wrote:
 

 Sorry but I still don't get it.
 
 Do you mean that the types that erased and the same code is generated?
 
 Then let me say that .Net generics get generated on the fly and JITed for 
 each
 different type.
 
 Eiffel and Modula-3 generics also have specific generated code for each 
 type.
 
 The major difference regarding C++ code is that the linkers are smarter and 
 are
 able to remove duplicates of the generated code for the same set of type 
 arguments.
 
 --
 Paulo
 
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
 news:mailman.755.1287643587.858.digitalmars-d puremagic.com...

 On Wednesday 20 October 2010 22:47:15 Paulo Pinto wrote:

 Eiffel does have templates, as in generic types.

 Or do you mean the compile time trick that C++ templates allow, thus
 opening the door for
 the meta programming done at compile time?


 Templates and generics are two separate - albeit related - things. 
 Templates
 generate code whereas generics allow you to use multiple types with the 
 same
 code (be it by generating code or by actually making them share code). C++
 templates happen to allow for metaprogramming beyond that, but I don't 
 think
 that that's necessary for a language to be considered to have templates. 
 The key
 thing is that templates _generate_ code whereas generics can simply make
 multiple types use the same code. C++ and D are the only languages that 
 I'm
 aware of which have templates. Other languages with generics generally 
 don't use
 templates to have generics.

 - Jonathan M Davis
Oct 21 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Gary Whatmore:


 I forgot Scala. They say Scala can  specialize without type erasure and it has
variance polymorphism. What are these? Sounds as if Scala is getting closer to
C++/D (instantiation and link-time optimization) and we need to fight back to
make our language more expressive.


It's never a "fight". I think Scala type system is a bit too much complex for
the average programmer (but I may be wrong, I've seen some people use Scala in
almost normal situations), so I don't think D and Scala are true competitors. 

On the other hand there are type system features that are absent in Scala that
now I think may be more useful than the Scala ones :-)

Bye,
bearophile
Oct 21 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Thu, 21 Oct 2010 16:00:11 -0400, Gary Whatmore wrote:


 What's the difference between:
 
 type polymorphism
 parametric polymorphism
 ad-hoc polymorphism
 generics
 c++ templates
 d style templates
 other templates (are there?)
 

 the real name and how to compare? Is D most expressive? I bet it is.


If I remember correctly, there used to be a comparison chart in the 
digitalmars website that made D look better than all other languages. I 
made a new version http://pastehtml.com/view/1bkw27w.html -- feel free to 
correct any errors. The main idea was to give some idea of the features 
there could be in D.
Oct 21 2010
next sibling parent retard <re tard.com.invalid> writes:
Thu, 21 Oct 2010 22:26:20 +0000, retard wrote:


 Thu, 21 Oct 2010 16:00:11 -0400, Gary Whatmore wrote:
 

 What's the difference between:
 
 type polymorphism
 parametric polymorphism
 ad-hoc polymorphism
 generics
 c++ templates
 d style templates
 other templates (are there?)
 

 What's the real name and how to compare? Is D most expressive? I bet it
 is.


 
 If I remember correctly, there used to be a comparison chart in the
 digitalmars website that made D look better than all other languages. I
 made a new version http://pastehtml.com/view/1bkw27w.html -- feel free
 to correct any errors. The main idea was to give some idea of the
 features there could be in D.


I forgot to list a lot of useful features such as typestates (thanks 
bearophile), but will probably update the chart later.
Oct 21 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
retard:

- "Complex integer types": Just L.
- "Safety features": it misses integral overflow tests and static contract
checking (and many other things done by C lint tools, etc).
- "Evaluation strategies": "by need" was present, but I think it's now
deprecated.
- "Polymorphism": template template arguments are missing, they allow an
almost-untyped form of higher order polymorphism.

Some of those features aren't compatible with each other. In the end your list
is not so useful, there are many other unlisted things present elsewhere, it
can't be complete. Even Scala probably has some type system features unlisted
there.

Bye,
bearophile
Oct 21 2010
next sibling parent retard <re tard.com.invalid> writes:
Thu, 21 Oct 2010 19:30:50 -0400, bearophile wrote:


 retard:
 
 - "Complex integer types": Just L.
 - "Safety features": it misses integral overflow tests and static
 contract checking (and many other things done by C lint tools, etc). -
 "Evaluation strategies": "by need" was present, but I think it's now
 deprecated. - "Polymorphism": template template arguments are missing,
 they allow an almost-untyped form of higher order polymorphism.
 
 Some of those features aren't compatible with each other. In the end
 your list is not so useful, there are many other unlisted things present
 elsewhere, it can't be complete. Even Scala probably has some type
 system features unlisted there.


Yes, indeed. It was mostly intended to be a checklist of things one 
should probably be aware of when designing languages. I promised to make 
a larger one later.

The 'mutability' in the list should really be 'immutability'. The 
conversion to html also wasn't perfect. Things like 'hygienic macros' was 
supposed to be a nested subcategory of the 'by macro expansion'.. maybe 
the meaning can be inferred from the context
Oct 21 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
Thu, 21 Oct 2010 19:30:50 -0400, bearophile wrote:


 retard:
 
 - "Safety features": it misses integral overflow tests and static
 contract checking (and many other things done by C lint tools, etc).


The list was describing the type system of the language. I can't agree 
these are all part of the types or type systems.
Oct 21 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:

 Thu, 21 Oct 2010 19:30:50 -0400, bearophile wrote:
 

 retard:

 - "Safety features": it misses integral overflow tests and static
 contract checking (and many other things done by C lint tools, etc).


 
 The list was describing the type system of the language. I can't agree 
 these are all part of the types or type systems.


Your list would be better if the terms were clickable links to their 
definitions. In fact, it could actually become a nice list this way.
Oct 21 2010
parent retard <re tard.com.invalid> writes:
Thu, 21 Oct 2010 20:05:58 -0700, Walter Bright wrote:


 retard wrote:

 Thu, 21 Oct 2010 19:30:50 -0400, bearophile wrote:
 

 retard:

 - "Safety features": it misses integral overflow tests and static
 contract checking (and many other things done by C lint tools, etc).


 
 The list was describing the type system of the language. I can't agree
 these are all part of the types or type systems.


 
 Your list would be better if the terms were clickable links to their
 definitions. In fact, it could actually become a nice list this way.


That's a good idea. Doing that next.
Oct 22 2010
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
retard wrote:


 Thu, 21 Oct 2010 16:00:11 -0400, Gary Whatmore wrote:
 

 What's the difference between:
 
 type polymorphism
 parametric polymorphism
 ad-hoc polymorphism
 generics
 c++ templates
 d style templates
 other templates (are there?)
 

 the real name and how to compare? Is D most expressive? I bet it is.


 
 If I remember correctly, there used to be a comparison chart in the
 digitalmars website that made D look better than all other languages. I
 made a new version http://pastehtml.com/view/1bkw27w.html -- feel free to
 correct any errors. The main idea was to give some idea of the features
 there could be in D.


There is also a bigger one in the wiki:

http://www.wikiservice.at/d/wiki.cgi?LanguagesVersusD
Oct 22 2010
parent retard <re tard.com.invalid> writes:
Fri, 22 Oct 2010 09:22:52 +0200, Lutger wrote:


 retard wrote:
 

 Thu, 21 Oct 2010 16:00:11 -0400, Gary Whatmore wrote:
 

 What's the difference between:
 
 type polymorphism
 parametric polymorphism
 ad-hoc polymorphism
 generics
 c++ templates
 d style templates
 other templates (are there?)
 

 What's the real name and how to compare? Is D most expressive? I bet
 it is.


 
 If I remember correctly, there used to be a comparison chart in the
 digitalmars website that made D look better than all other languages. I
 made a new version http://pastehtml.com/view/1bkw27w.html -- feel free
 to correct any errors. The main idea was to give some idea of the
 features there could be in D.


 
 There is also a bigger one in the wiki:
 
 http://www.wikiservice.at/d/wiki.cgi?LanguagesVersusD


Ah, the good old comparison chart. Gotta make my version longer.
Oct 22 2010
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Gary Whatmore wrote:


 What's the difference between:
 
 type polymorphism
 parametric polymorphism
 ad-hoc polymorphism
 generics
 c++ templates
 d style templates
 other templates (are there?)
 

 the real name and how to compare? Is D most expressive? I bet it is.
 
  - G.W.
 


From what I've read, the more general term is parametric polymorphism which 
is broader than the Ada/C++ family of implementations (generics/templates). 

One big difference is that generics are explicit or nominative, whereas 

the generic parameters you explicitly constrain, while in C++ and D the 
type checking is instead done at instantiation time, not based on the name 
but on the structure of the code. This makes it more flexibele, the 
argument for explicit polymorphism is that it has better type checking. 

Other ways to compare include:

- what can be parametrized. Usually classes, interfaces and functions, D 
can also parametrize more declarations at once. 


types, D expands that range to include values, symbols and function 
literals.

- support for implicit instantiation


http://en.wikipedia.org/wiki/Type_polymorphism

and a somewhat lighter read: http://www.artima.com/intv/generics.html
Oct 22 2010
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Paulo Pinto <pjmlp progtools.org> wrote:


 Sorry but I still don't get it.

 Do you mean that the types that erased and the same code is generated?

 Then let me say that .Net generics get generated on the fly and JITed for
 each
 different type.

 Eiffel and Modula-3 generics also have specific generated code for each
 type.

 The major difference regarding C++ code is that the linkers are smarter  
 and
 are
 able to remove duplicates of the generated code for the same set of type
 arguments.


The point is, D and C++ templates can do a lot more than simple generics.
Generics is limited to simple copying and pasting of type names, whereas
templates can build a DSL parser for you, let you choose whether a
function should be parallelized, a type thread-safe, etc.


-- 
Simen
Oct 21 2010
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
I can get the same benefict from functional languages+generics, or dynamic 
languages.

"Simen kjaeraas" <simen.kjaras gmail.com> wrote in message 
news:op.vkxy6xx2vxi10f biotronic-pc.lan...

 Paulo Pinto <pjmlp progtools.org> wrote:


 Sorry but I still don't get it.

 Do you mean that the types that erased and the same code is generated?

 Then let me say that .Net generics get generated on the fly and JITed for
 each
 different type.

 Eiffel and Modula-3 generics also have specific generated code for each
 type.

 The major difference regarding C++ code is that the linkers are smarter 
 and
 are
 able to remove duplicates of the generated code for the same set of type
 arguments.


 The point is, D and C++ templates can do a lot more than simple generics.
 Generics is limited to simple copying and pasting of type names, whereas
 templates can build a DSL parser for you, let you choose whether a
 function should be parallelized, a type thread-safe, etc.


 -- 
 Simen
Oct 21 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 21 October 2010 22:42:47 Paulo Pinto wrote:

 I can get the same benefict from functional languages+generics, or dynamic
 languages.


lisp macros aside, I've never seen anything that could ever come close to D 
templates in terms of their flexiblity and power for code generation. I'm sure 
that some of their capabilities can be achieved in various ways with other 
languages, but I've never seen anything come close. Adding string and template 
mixins on top of them, and you've got some massive power and flexibility.

Now, it's quite possible that a language that I'm not particularly familiar
with 
can match that flexibility and power with features of its own, but I'm not
aware 
of any (save for lisp macros).

- Jonathan M Davis
Oct 21 2010
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, October 21, 2010 12:45:32 Paulo Pinto wrote:

 Sorry but I still don't get it.
 
 Do you mean that the types that erased and the same code is generated?
 
 Then let me say that .Net generics get generated on the fly and JITed for
 each
 different type.
 
 Eiffel and Modula-3 generics also have specific generated code for each
 type.
 
 The major difference regarding C++ code is that the linkers are smarter and
 are
 able to remove duplicates of the generated code for the same set of type
 arguments.


Whether code gets consolidated really doesn't have anything to do with
templates 
- that's purely an optimization, and where exactly you draw the line betwene 
generics and templates could be bit blurry, but they are two very different 
things.

Generics allow for generic code - primarily container types. You're able to use 
multiple types with the same code. Whether duplicate code is generated or not
is 
an implementation issue, but most languages that talk about having generics 
don't seem to create full-on new sets of code for each type that you use - or
if 
they do, it's completely hidden from the programmer. Java's generics are 
completely a compile-time artifact with the exact same code being generated -
it 
just gains you extra type-safety and saves you from explicit casts. I don't
know 

regardless of how many types you use with it but keeps the type information
with 
any variables declared of that type (it may JIT specific types on the fly as
you 
state - I have no idea). But regardless, they don't actually generate code in 
your executable.

Templates are literally templates for creating code. When you instantiate a 
template, it duplicates the entire definition for the type that it's being 
instantiated for. vector<int> and vector<float> generate two completely
separate 
sets of source code. This is not hidden from the programmer. Templates can 
generate different code depending on what they're instantiated with (typically 
template specializations in C++, though D goes beyond that with conditional 
compilation with static if and whatnot). So, even if you're limiting templates 
to container types, you can end up with very different code for instantiations
of 
that template (a classic example in C++ being vector<bool>). Template 
metaprogramming goes beyond that to do much crazier stuff with templates, but 
even with out template metaprogramming, you still end up with whole new sets of 
code for each template instantiation. The compiler may choose to optimize some 
of that code and merge definitions where types are the same size, but that's an 
optimization. Templates are literally a code-generation mechanism. They 
therefore can be used for generic code or even could be considered generics,
but 
generics do not necessarily generate code.

Now, as I said, C++ and D are the only languages I know of which use templates. 
That doesn't mean that other languages do not. Looking at the wikipedia page on 
template metaprogramming, it lists other languages such as Eiffel and ML, so 
presumably those languages have templates of some kind.

In any case, the key thing about templates is that they are a code-generation 
mechanism. Generics are not (though templates can be used as generics).

- Jonathan M Davis
Oct 21 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Thu, 21 Oct 2010 16:51:03 -0700, Jonathan M Davis wrote:


 Now, as I said, C++ and D are the only languages I know of which use
 templates. That doesn't mean that other languages do not. Looking at the
 wikipedia page on template metaprogramming, it lists other languages
 such as Eiffel and ML, so presumably those languages have templates of
 some kind.


I'm not aware of templates in Eiffel or ML, but the WP article also 
mentioned Haskell (which you nimbly left out of the list) which indeed 
has been extended to support templates in Template Haskell. There are 
several similar kind of languages, e.g. MetaOCaml. The original Template 
Haskell paper lists some of these.
Oct 21 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, October 21, 2010 17:05:45 retard wrote:

 Thu, 21 Oct 2010 16:51:03 -0700, Jonathan M Davis wrote:

 Now, as I said, C++ and D are the only languages I know of which use
 templates. That doesn't mean that other languages do not. Looking at the
 wikipedia page on template metaprogramming, it lists other languages
 such as Eiffel and ML, so presumably those languages have templates of
 some kind.


 
 I'm not aware of templates in Eiffel or ML, but the WP article also
 mentioned Haskell (which you nimbly left out of the list) which indeed
 has been extended to support templates in Template Haskell. There are
 several similar kind of languages, e.g. MetaOCaml. The original Template
 Haskell paper lists some of these.


LOL. Nimbly huh. Well, there was no need to list them all, and it felt really 
weird to list Haskell when I've used Haskell a fair bit and never heard of any 
templates of any kind in Haskell. For the purposes of the discussion though, I 
don't suppose that it matters particularly. The point is that according to 
wikipedia there are languages other than C++ and D which have template 
metaprogramming capabilities (and therefore have to have templates).

- Jonathan Mdavis
Oct 21 2010
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
Sorry but all of them are just names for the same thing.

The template metaprogramming that is possibile in C++ is actually due to 
some loopholes
in the language definition. In the old days there were some articles in the 
C++ Report
when this technique was discovered.

D does provide a better way to do template metaprogramming, at least one 
that is more
user friendly.

Java generics are not that good, true. This is mainly to the fact that Sun 
decided to keep
backwards compatibility in the generated code. So actually Java generics are 
not much
more than sintactic sugar.



Not sure if this is the same Wikipedia article that was already discussed 
before
http://en.wikipedia.org/wiki/Generic_programming

Thus the only thing I conced C++ and D templates have over the other 
languages is
the metaprogramming abilities. But there are other languages which 
compensate for
that by offering other languages features to handle similar funcionality.

An example, is what is possible to do with Lisp. And lets not forget that 
optimizing
Lisp compilers can beat Fortran code, which still has very good optimizing 
compilers.

--
Paulo

"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.763.1287705091.858.digitalmars-d puremagic.com...

 On Thursday, October 21, 2010 12:45:32 Paulo Pinto wrote:

 Sorry but I still don't get it.

 Do you mean that the types that erased and the same code is generated?

 Then let me say that .Net generics get generated on the fly and JITed for
 each
 different type.

 Eiffel and Modula-3 generics also have specific generated code for each
 type.

 The major difference regarding C++ code is that the linkers are smarter 
 and
 are
 able to remove duplicates of the generated code for the same set of type
 arguments.


 Whether code gets consolidated really doesn't have anything to do with 
 templates
 - that's purely an optimization, and where exactly you draw the line 
 betwene
 generics and templates could be bit blurry, but they are two very 
 different
 things.

 Generics allow for generic code - primarily container types. You're able 
 to use
 multiple types with the same code. Whether duplicate code is generated or 
 not is
 an implementation issue, but most languages that talk about having 
 generics
 don't seem to create full-on new sets of code for each type that you use - 
 or if
 they do, it's completely hidden from the programmer. Java's generics are
 completely a compile-time artifact with the exact same code being 
 generated - it
 just gains you extra type-safety and saves you from explicit casts. I 
 don't know

 definition
 regardless of how many types you use with it but keeps the type 
 information with
 any variables declared of that type (it may JIT specific types on the fly 
 as you
 state - I have no idea). But regardless, they don't actually generate code 
 in
 your executable.

 Templates are literally templates for creating code. When you instantiate 
 a
 template, it duplicates the entire definition for the type that it's being
 instantiated for. vector<int> and vector<float> generate two completely 
 separate
 sets of source code. This is not hidden from the programmer. Templates can
 generate different code depending on what they're instantiated with 
 (typically
 template specializations in C++, though D goes beyond that with 
 conditional
 compilation with static if and whatnot). So, even if you're limiting 
 templates
 to container types, you can end up with very different code for 
 instantiations of
 that template (a classic example in C++ being vector<bool>). Template
 metaprogramming goes beyond that to do much crazier stuff with templates, 
 but
 even with out template metaprogramming, you still end up with whole new 
 sets of
 code for each template instantiation. The compiler may choose to optimize 
 some
 of that code and merge definitions where types are the same size, but 
 that's an
 optimization. Templates are literally a code-generation mechanism. They
 therefore can be used for generic code or even could be considered 
 generics, but
 generics do not necessarily generate code.

 Now, as I said, C++ and D are the only languages I know of which use 
 templates.
 That doesn't mean that other languages do not. Looking at the wikipedia 
 page on
 template metaprogramming, it lists other languages such as Eiffel and ML, 
 so
 presumably those languages have templates of some kind.

 In any case, the key thing about templates is that they are a 
 code-generation
 mechanism. Generics are not (though templates can be used as generics).

 - Jonathan M Davis
Oct 21 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 And lets not forget that optimizing Lisp compilers can beat Fortran code,


Only if the Fortran code is very bad :-)

Bye,
bearophile
Oct 22 2010
parent "Paulo Pinto" <pjmlp progtools.org> writes:
Well at least it did back in the early 90s

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.9052&rep=rep1&type=pdf
http://www.cs.berkeley.edu/~fateman/papers/lispfloat.ps
http://openmap.bbn.com/~kanderso/performance/

--
Paulo

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:i9rp28$19kb$1 digitalmars.com...

 Paulo Pinto:


 And lets not forget that optimizing Lisp compilers can beat Fortran code,


 Only if the Fortran code is very bad :-)

 Bye,
 bearophile
Oct 22 2010
prev sibling parent reply so <so so.do> writes:
One more thing, it is hard to be comfortable with C++ if you are pushing  
the limits of templates.
There are things you can do and things you simply cant.

Andrei and Walter here you know one of those template experts, so are the  
people in Boost.
I am sure not a single one of them would say that they are comfortable  
using templates. C++ is awesome, for its time :)

*cheers

On Wed, 20 Oct 2010 13:57:16 +0300, Paulo Pinto <pjmlp progtools.org>  
wrote:


 Sorry but I have to disagree.

 Actually after reading TDPL I got the impression that at the semantic  
 level,
 D is not that
 much easier than C++.

 It does not make a difference for people that myself that are quite
 comfortable with C++,
 and all its idioms, but I think for the average programmer they are also
 complex.

 Which does not rule out people using D, after all you need to have the  
 right
 background
 for doing proper programming.

 --
 Paulo

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.735.1287519617.858.digitalmars-d puremagic.com...

 On Tuesday 19 October 2010 12:53:41 Andrei Alexandrescu wrote:

 On 10/19/10 14:04 CDT, Max Samukha wrote:

 On 10/19/2010 09:06 PM, Walter Bright wrote:

 bearophile wrote:

 The point I was trying to express is that from what I have seen
 people
 are
 able to learn to program Python (this means quite more than just  






 the

 syntax)
 in *much* less time it takes to learn C++/D. And this has precise
 causes.


 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++
 programs.
 A 1990's state of the art C++ program is very different from a 2010
 one.

 We've only just begun figuring out the right way to write D  




 programs.

 That is funny. Now and then you and Andrei talk so confidently about
 Go,



 than a

 couple of lines in those languages. At the same time, you are  


 claiming

 that it takes years to even start to learn a programming language.
 Sure,
 it is not problems with D that make it difficult to use. We simply
 don't
 know how to program in D yet, after several years of doing just that.


 I agree this seems to be a contradiction. Haskell is a fairly mature
 language building on a staunch pure functional base so many of its

 it's not difficult to learn from the perspective of the languages that
 influence it. Go is a small language that has one defining feature (the
 implicit signature conformance) that does add a certain flavor but is
 understood and has been experimented with in other languages.

 D has added a lot in the direction of generics, and by their nature
 generics interact heavily with the rest of the language. I agree it is
 taking time to get to best use of such, but it's not wasted time  
 because
 it marks real progress. For example, code using the relatively new
 template constraints is better than code that didn't use them.


 With all due respect for Andrei, I doubt that it is his book that
 completely changed the way people wrote C++ programs. It was
 influential, right, but it was really not a single factor. And some  


 of

 ideas presented in that book are avoided by reasonable programmers.

 Please stop so shamelessly advertising each other. Thanks!


 Sorry. Do I advertise Walter that frequently?


 Both of you do periodically say something about what the other has done  
 in
 the
 past, but I don't get the impression that you're ever explicitly trying  
 to
 make
 the other person look good or "advertise" them. Others may see it
 differently
 though.

 And while in many ways, Modern C++ was a game-changer, I've never worked
 with
 anyone who really uses the stuff it talks about. In my experience with  
 C++
 code
 in production code, templates get used when they're necessary but that
 they're
 generally avoided. Of course, given how bad some of the code I've seen  
 is,
 I
 definitely don't _want_ a lot of the people who wrote it messing around
 with
 heavily-templated code, but regardless, as major as the ideas in Modern
 C++ are,
 I think that there are a lot of C++ programmers out who never use them.
 They're
 just too complicated for a lot of people. Hopefully D manages to make  
 such
 metaprogramming sane enough that your average D programmer won't freak  
 out
 about
 template metaprogramming in the way many C++ programmers do.

 - Jonathan M Davis





-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 20 2010
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
Personally, my only complaint is the way error messages are handled. And I
was looking forward to have concepts in the language, which was not 
possible,
but unfortunely there were some sematic issues related with the feature.

But LLVM project is showing how it is possible to make C++ more user and
tool friendly, provided all the tools have access to the code AST.

I actually think that C and C++ really match the concept of "Worse is 
Better".

For many use cases people will just do with what they offer, while using 
other
languages for more higher level tasks.

--
Paulo

"so" <so so.do> wrote in message news:op.vkvih9t67dtt59 so-pc...

 One more thing, it is hard to be comfortable with C++ if you are pushing 
 the limits of templates.
 There are things you can do and things you simply cant.

 Andrei and Walter here you know one of those template experts, so are the 
 people in Boost.
 I am sure not a single one of them would say that they are comfortable 
 using templates. C++ is awesome, for its time :)

 *cheers

 On Wed, 20 Oct 2010 13:57:16 +0300, Paulo Pinto <pjmlp progtools.org> 
 wrote:


 Sorry but I have to disagree.

 Actually after reading TDPL I got the impression that at the semantic 
 level,
 D is not that
 much easier than C++.

 It does not make a difference for people that myself that are quite
 comfortable with C++,
 and all its idioms, but I think for the average programmer they are also
 complex.

 Which does not rule out people using D, after all you need to have the 
 right
 background
 for doing proper programming.

 --
 Paulo

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.735.1287519617.858.digitalmars-d puremagic.com...

 On Tuesday 19 October 2010 12:53:41 Andrei Alexandrescu wrote:

 On 10/19/10 14:04 CDT, Max Samukha wrote:

 On 10/19/2010 09:06 PM, Walter Bright wrote:

 bearophile wrote:

 The point I was trying to express is that from what I have seen
 people
 are
 able to learn to program Python (this means quite more than just






 the

 syntax)
 in *much* less time it takes to learn C++/D. And this has precise
 causes.


 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++
 programs.
 A 1990's state of the art C++ program is very different from a 2010
 one.

 We've only just begun figuring out the right way to write D




 programs.

 That is funny. Now and then you and Andrei talk so confidently about
 Go,



 than a

 couple of lines in those languages. At the same time, you are


 claiming

 that it takes years to even start to learn a programming language.
 Sure,
 it is not problems with D that make it difficult to use. We simply
 don't
 know how to program in D yet, after several years of doing just that.


 I agree this seems to be a contradiction. Haskell is a fairly mature
 language building on a staunch pure functional base so many of its

 it's not difficult to learn from the perspective of the languages that
 influence it. Go is a small language that has one defining feature (the
 implicit signature conformance) that does add a certain flavor but is
 understood and has been experimented with in other languages.

 D has added a lot in the direction of generics, and by their nature
 generics interact heavily with the rest of the language. I agree it is
 taking time to get to best use of such, but it's not wasted time 
 because
 it marks real progress. For example, code using the relatively new
 template constraints is better than code that didn't use them.


 With all due respect for Andrei, I doubt that it is his book that
 completely changed the way people wrote C++ programs. It was
 influential, right, but it was really not a single factor. And some


 of

 ideas presented in that book are avoided by reasonable programmers.

 Please stop so shamelessly advertising each other. Thanks!


 Sorry. Do I advertise Walter that frequently?


 Both of you do periodically say something about what the other has done 
 in
 the
 past, but I don't get the impression that you're ever explicitly trying 
 to
 make
 the other person look good or "advertise" them. Others may see it
 differently
 though.

 And while in many ways, Modern C++ was a game-changer, I've never worked
 with
 anyone who really uses the stuff it talks about. In my experience with 
 C++
 code
 in production code, templates get used when they're necessary but that
 they're
 generally avoided. Of course, given how bad some of the code I've seen 
 is,
 I
 definitely don't _want_ a lot of the people who wrote it messing around
 with
 heavily-templated code, but regardless, as major as the ideas in Modern
 C++ are,
 I think that there are a lot of C++ programmers out who never use them.
 They're
 just too complicated for a lot of people. Hopefully D manages to make 
 such
 metaprogramming sane enough that your average D programmer won't freak 
 out
 about
 template metaprogramming in the way many C++ programmers do.

 - Jonathan M Davis





 -- 
 Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 20 2010
parent reply so <so so.do> writes:
Error generation is the least of it. Think about how different would you  
code, or how broad your choices would be with just templates with string  
support, nothing more.

On Wed, 20 Oct 2010 15:34:05 +0300, Paulo Pinto <pjmlp progtools.org>  
wrote:


 Personally, my only complaint is the way error messages are handled. And  
 I
 was looking forward to have concepts in the language, which was not
 possible,
 but unfortunely there were some sematic issues related with the feature.

 --
 Using Opera's revolutionary e-mail client: http://www.opera.com/mail/





-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Oct 20 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
so wrote:

 Error generation is the least of it. Think about how different would you 
 code, or how broad your choices would be with just templates with string 
 support, nothing more.


That's right. You cannot even pass a string literal to a C++ template.
Oct 20 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
so wrote:

 One more thing, it is hard to be comfortable with C++ if you are pushing 
 the limits of templates.
 There are things you can do and things you simply cant.
 
 Andrei and Walter here you know one of those template experts, so are 
 the people in Boost.
 I am sure not a single one of them would say that they are comfortable 
 using templates. C++ is awesome, for its time :)


C++ broke new ground with its template system. A lot (most?) of what you can do 
with C++ templates was discovered rather than designed, such as the functional 
programming aspect of it.

It makes perfect sense that once you figure out what to do with templates, you 
can design a system that makes that much more straightforward.

It's like the Wright Bros figured out how to do 3 axis control, and made it 
work. But it was Curtiss who started from those insights, and figured out a
much 
simpler and more effective way to do it. (The Wright airplane company
stubbornly 
stuck with the Wright design until Orville finally ceded control of the
company, 
at which point it promptly switched to the Curtiss design.)
Oct 20 2010
prev sibling parent Emil Madsen <sovende gmail.com> writes:
Nahh, its just him, he apparently likes you the most (^ . ^)
(jk)

On 19 October 2010 21:53, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org

 wrote:



 On 10/19/10 14:04 CDT, Max Samukha wrote:


 On 10/19/2010 09:06 PM, Walter Bright wrote:


 bearophile wrote:


 The point I was trying to express is that from what I have seen people
 are
 able to learn to program Python (this means quite more than just the
 syntax)
 in *much* less time it takes to learn C++/D. And this has precise
 causes.


 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++ programs.
 A 1990's state of the art C++ program is very different from a 2010 one.

 We've only just begun figuring out the right way to write D programs.


 That is funny. Now and then you and Andrei talk so confidently about Go,

 couple of lines in those languages. At the same time, you are claiming
 that it takes years to even start to learn a programming language. Sure,
 it is not problems with D that make it difficult to use. We simply don't
 know how to program in D yet, after several years of doing just that.


 I agree this seems to be a contradiction. Haskell is a fairly mature
 language building on a staunch pure functional base so many of its idioms

 difficult to learn from the perspective of the languages that influence it.
 Go is a small language that has one defining feature (the implicit signature
 conformance) that does add a certain flavor but is understood and has been
 experimented with in other languages.

 D has added a lot in the direction of generics, and by their nature
 generics interact heavily with the rest of the language. I agree it is
 taking time to get to best use of such, but it's not wasted time because it
 marks real progress. For example, code using the relatively new template
 constraints is better than code that didn't use them.


  With all due respect for Andrei, I doubt that it is his book that

 completely changed the way people wrote C++ programs. It was
 influential, right, but it was really not a single factor. And some of
 ideas presented in that book are avoided by reasonable programmers.

 Please stop so shamelessly advertising each other. Thanks!


 Sorry. Do I advertise Walter that frequently?


 Andrei




-- 
// Yours sincerely
// Emil 'Skeen' Madsen
Oct 20 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Max Samukha wrote:

 On 10/19/2010 09:06 PM, Walter Bright wrote:

 Time will tell how long it will take people to become idiomatically
 proficient in D. But also consider that Andrei's book "Modern C++
 Design" completely changed the idiomatic way people wrote C++ programs.
 A 1990's state of the art C++ program is very different from a 2010 one.

 We've only just begun figuring out the right way to write D programs.


 
 That is funny. Now and then you and Andrei talk so confidently about Go, 

 couple of lines in those languages. At the same time, you are claiming 
 that it takes years to even start to learn a programming language.


I think I claimed that it takes years to master a language, not start to learn. 



 Sure, 
 it is not problems with D that make it difficult to use. We simply don't 
 know how to program in D yet, after several years of doing just that.


Usage of just about every language has evolved away from what the designers 
originally thought it would be.



 With all due respect for Andrei, I doubt that it is his book that 
 completely changed the way people wrote C++ programs. It was 
 influential, right, but it was really not a single factor. And some of 
 ideas presented in that book are avoided by reasonable programmers.


I'm not the only one that thinks so: 
http://www.artima.com/cppsource/top_cpp_books.html



 Please stop so shamelessly advertising each other. Thanks!


It wasn't an intent to advertise, I was trying to illustrate how the usage 
pattern of a language changes over time. Does anyone think Bjarne Stroustrup 
imagined this stuff back in 1985? or even 1995? Even how people use C has 
changed a lot, despite the language itself hardly changing.
Oct 20 2010