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 want Java or C# style generics with auto-boxing and where you want C++-style 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 want Java or C# style generics with auto-boxing and where you want C++-style 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, C#, Haskell and other D competitors, without having written more 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. 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, C#, Haskell and other D competitors, without having written more 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 idioms have been established. C# uses rather conservative features so 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, C#, Haskell and other D competitors, without having written more 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 idioms have been established. C# uses rather conservative features so 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, C#, Haskell and other D competitors, without having written more 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 idioms have been established. C# uses rather conservative features so 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,
 C#, Haskell and other D competitors, without having written more  
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 idioms have been established. C# uses rather conservative features so 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?)

Does Java and C# have type polymorphism or generics or templates? What's the
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?)
 
 Does Java and C# have type polymorphism or generics or templates? What's the
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?)
 
 Does Java and C# have type polymorphism or generics or templates? 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.
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?)
 
 Does Java and C# have type polymorphism or generics or templates?
 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?)
 
 Does Java and C# have type polymorphism or generics or templates? 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
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?)
 
 Does Java and C# have type polymorphism or generics or templates?
 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?)
 
 Does Java and C# have type polymorphism or generics or templates? What's
 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 templates are implicit. In Java, Ada and C# you can only use features of 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. - what kinds can serve as parameters. In Java and C# I think this is only 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 exactly how C# does it, but as I understand it, it uses a single 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
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.

Eiffel, Modula-3, Ada, C#, F#, Scala all allow for type specialization.

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 exactly how C# does it, but as I understand it, it uses a single 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,
 C#, Haskell and other D competitors, without having written more  
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 idioms have been established. C# uses rather conservative features so 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,
 C#, Haskell and other D competitors, without having written more
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 idioms have been established. C# uses rather conservative features so 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, C#, Haskell and other D competitors, without having written more 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 idioms have been established. C# uses rather conservative features so 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
-- // 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, C#, Haskell and other D competitors, without having written more 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.
I think I claimed that it takes years to master a language, not start to learn. I am not a master of Go, C#, or Haskell.
 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