Re: Inherent code performance advantages of D over C?

2013-12-10 Thread H. S. Teoh
On Tue, Dec 10, 2013 at 08:28:14AM +0100, Joseph Rushton Wakeling wrote: > On 09/12/13 20:45, Araq wrote: > >That language X is faster than C in "practice" because X is much more > >developer friendly and thus you can tweak your code much easier etc. > >is an argument of every language out there. >

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/9/2013 11:55 PM, H. S. Teoh wrote: Agree with your points, but just had to point out that I don't even *use* the mouse (well, barely), so your example is moot. :-P A vi user? :-)

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/10/2013 12:21 AM, H. S. Teoh wrote: Result? The D version now runs faster than the C version -- perhaps up to an order of magnitude. This case history would make a great blog post.

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Iain Buclaw
On 10 December 2013 08:29, Walter Bright wrote: > On 12/9/2013 11:55 PM, H. S. Teoh wrote: >> >> Agree with your points, but just had to point out that I don't even >> *use* the mouse (well, barely), so your example is moot. :-P > > > A vi user? :-) > Worse, he's from the emacs crowd. :o)

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Joseph Rushton Wakeling
On 10/12/13 09:21, H. S. Teoh wrote: It turned out that I had overlooked a simple but very significant optimization present in the C version that hadn't been implemented in the D version yet. [...] In the original C code, it took quite a while to implement this optimization because ... well, in

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Timon Gehr
On 12/09/2013 11:00 PM, Walter Bright wrote: On 12/9/2013 1:28 PM, Timon Gehr wrote: Sorry, I'm lost. What point are you arguing? None of this disputes in any way anything I wrote. I thought you were arguing that whole program analysis was as good as using immutable and const qualifiers. Ind

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Atila Neves
On Tuesday, 10 December 2013 at 08:28:12 UTC, Walter Bright wrote: On 12/10/2013 12:21 AM, H. S. Teoh wrote: Result? The D version now runs faster than the C version -- perhaps up to an order of magnitude. This case history would make a great blog post. +1. My opinion _might_ be just a tad

Re: No household is perfect

2013-12-10 Thread Russel Winder
On Tue, 2013-12-03 at 12:06 -0800, Walter Bright wrote: […] I have been waiting to answer this as I wanted to do some experiment first. However circumstances mean that this playing will have to wait till the Christmas break. I thought I should put a place holder message in though to mark that a re

Re: D-Link with R/MATLAB/Julia/SQL

2013-12-10 Thread Siavash Babaei
Since it is not your (no-one specifically) job to do so and you are probably not as `expert', it is likely that you will mess things up. It is also time consuming ... The concept of "division of labour" has been around for several thousand years, after all. C++, R, MATLAB, and the like have real

Re: D-Link with R/MATLAB/Julia/SQL

2013-12-10 Thread Siavash Babaei
Thank you ... load of my mind

enum pre-conditions

2013-12-10 Thread bearophile
(This post is a second try of the ideas I discussed in this ER: http://d.puremagic.com/issues/show_bug.cgi?id=5906 ) It is sometimes handy and useful to be able to give structs some of the capabilities and qualities of some build-in values, this makes structs more powerful, handy and allow to b

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread H. S. Teoh
On Tue, Dec 10, 2013 at 08:59:26AM +, Iain Buclaw wrote: > On 10 December 2013 08:29, Walter Bright wrote: > > On 12/9/2013 11:55 PM, H. S. Teoh wrote: > >> > >> Agree with your points, but just had to point out that I don't even > >> *use* the mouse (well, barely), so your example is moot. :-

Re: No household is perfect

2013-12-10 Thread Luís.Marques
On Thursday, 5 December 2013 at 08:06:35 UTC, monarch_dodra wrote: Having read all that though, one could argue that having "uni" is *even worst* than "unicode", as it violates both: a) Use the ® symbol to indicate that the Unicode Mark b) Do not alter its spelling I don't care much about uni v

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Paulo Pinto
On Tuesday, 10 December 2013 at 15:09:37 UTC, H. S. Teoh wrote: On Tue, Dec 10, 2013 at 08:59:26AM +, Iain Buclaw wrote: On 10 December 2013 08:29, Walter Bright wrote: > On 12/9/2013 11:55 PM, H. S. Teoh wrote: >> >> Agree with your points, but just had to point out that I >> don't even

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread H. S. Teoh
On Tue, Dec 10, 2013 at 10:38:42AM +0100, Joseph Rushton Wakeling wrote: > On 10/12/13 09:21, H. S. Teoh wrote: > >It turned out that I had overlooked a simple but very significant > >optimization present in the C version that hadn't been implemented > >in the D version yet. [...] In the original C

Re: D vs Go in real life

2013-12-10 Thread Daniel Murphy
"Joseph Rushton Wakeling" wrote in message news:mailman.307.1386345047.3242.digitalmar...@puremagic.com... > On 06/12/13 16:37, Daniel Murphy wrote: > > Is there a documented TODO list anywhere? And is there anything that > those of us not contributing frontend code can do to help? (No, not >

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Francesco Cattoglio
On Tuesday, 10 December 2013 at 07:51:56 UTC, H. S. Teoh wrote: We need to work on the "compiler as a library" project. I hope everyone agrees on this. My wild guess is that the project will be the next "big thing" to work on after the frontend is moved to D.

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Daniel Murphy
"Francesco Cattoglio" wrote in message news:stpuvkzasctgyoryu...@forum.dlang.org... > On Tuesday, 10 December 2013 at 07:51:56 UTC, H. S. Teoh wrote: >> We need to work on the "compiler as a library" project. > > I hope everyone agrees on this. My wild guess is that the project will be > the nex

Re: D-Link with R/MATLAB/Julia/SQL

2013-12-10 Thread Joseph Rushton Wakeling
On 09/12/13 21:22, bachmeier wrote: I will write something up as soon as I can, but it might be a while before that happens. I will also share my code for the .Call interface. Hopefully I will get feedback from someone more knowledgeable about D. I'll leave DConf to the experts. I'm an economist

Option!T

2013-12-10 Thread Andrei Alexandrescu
I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the Option type - a zero or one element collection (range in D terminology). Here's an article discussing it: http://danielwestheide.com/blog/2012/12/19/the-neophytes-guide-to-scala-part-5-the-option-type.

Re: Option!T

2013-12-10 Thread JR
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a collection of exactly one value, but not a type for "a value of type T or nothing at all". Is this not what Nullable!T is?

Re: Option!T

2013-12-10 Thread Max Klyga
On 2013-12-10 17:28:26 +, Andrei Alexandrescu said: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the Option type - a zero or one element collection (range in D terminology). Here's an article discussing it: http://danielwestheide.com/blog/2012/

Re: Option!T

2013-12-10 Thread Yota
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the Option type - a zero or one element collection (range in D terminology). Here's an article discussing it: http://danielwesthei

Re: Lambda syntax for methods and functions

2013-12-10 Thread bearophile
http://adamralph.com/2013/12/06/ndc-diary-day-3/?1 Better explanations: http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illustrated Bye, bearophile

Re: Option!T

2013-12-10 Thread Andrei Alexandrescu
On 12/10/13 9:47 AM, Max Klyga wrote: On 2013-12-10 17:28:26 +, Andrei Alexandrescu said: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the Option type - a zero or one element collection (range in D terminology). Here's an article discussing it:

Re: Option!T

2013-12-10 Thread Andrei Alexandrescu
On 12/10/13 9:40 AM, JR wrote: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a collection of exactly one value, but not a type for "a value of type T or nothing at all". Is this not what Nullable!T

Re: Option!T

2013-12-10 Thread Paulo Pinto
Am 10.12.2013 18:54, schrieb Yota: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the Option type - a zero or one element collection (range in D terminology). Here's an article di

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/10/2013 1:58 AM, Timon Gehr wrote: Recovering all immutable and const qualifiers that are possible to assign to the program is simple to do if the whole program is available. I believe you are seriously mistaken about it being simple, or even possible. For example, malloc() returns a poi

Re: Option!T

2013-12-10 Thread Andrei Alexandrescu
On 12/10/13 10:21 AM, Paulo Pinto wrote: Am 10.12.2013 18:54, schrieb Yota: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the Option type - a zero or one element collection (ran

Re: Option!T

2013-12-10 Thread bearophile
Andrei Alexandrescu: Should we follow Scala's example and add it? Making an Option a D Range means it becomes a Mondad :-) There's then a need for more awareness of Option!T in map/filter/zip. Related: https://d.puremagic.com/issues/show_bug.cgi?id=9086 Bye, bearophile

2.0.64 progression

2013-12-10 Thread H. S. Teoh
This morning I decided to use 2.0.64 (well actually, git HEAD) to recompile a project that's been on the backburner for a while, and at first it appeared as though a regression has occurred, as dmd spewed out a screenful of compile errors. Upon closer inspection, though, the errors were caused by

Re: 2.0.64 progression

2013-12-10 Thread bearophile
H. S. Teoh: So this isn't a regression; it's *pro*gression! (And on that note, I'd like to propose that code breakage of this sort *should* be allowed in D. While we *should* be stabilizing the language, I don't think it's right to go to the opposite extreme of hindering language fixes just

Re: Option!T

2013-12-10 Thread Paulo Pinto
Am 10.12.2013 19:34, schrieb Andrei Alexandrescu: On 12/10/13 10:21 AM, Paulo Pinto wrote: Am 10.12.2013 18:54, schrieb Yota: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the

Probable C# 6.0 features

2013-12-10 Thread Suliman
Maybe it would be possible to get some good idea from next version of C# It's only ideas about next version, but new future maybe next: http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illustrated

Re: Option!T

2013-12-10 Thread monarch_dodra
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a collection of exactly one value, but not a type for "a value of type T or nothing at all" Option is being upgraded to handle an arbitrary (but compile

Re: Probable C# 6.0 features

2013-12-10 Thread bearophile
Suliman: Maybe it would be possible to get some good idea from next version of C# Discussed a little here: http://forum.dlang.org/thread/naeqxidypkpehynmi...@forum.dlang.org Bye, bearophile

Re: Option!T

2013-12-10 Thread Max Klyga
On 2013-12-10 18:35:37 +, bearophile said: Andrei Alexandrescu: Should we follow Scala's example and add it? Making an Option a D Range means it becomes a Mondad :-) There's then a need for more awareness of Option!T in map/filter/zip. Related: https://d.puremagic.com/issues/show_bug.

Re: Option!T

2013-12-10 Thread Andrei Alexandrescu
On 12/10/13 10:59 AM, monarch_dodra wrote: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a collection of exactly one value, but not a type for "a value of type T or nothing at all" Option is being u

Re: Lambda syntax for methods and functions

2013-12-10 Thread Joshua Niehus
On Saturday, 7 December 2013 at 17:29:43 UTC, bearophile wrote: Even Ada2012 has a similar syntax. I think it's worth having in D. The ER: https://d.puremagic.com/issues/show_bug.cgi?id=7176 Bye, bearophile similar to dart, my 2nd favorite lang :) https://www.dartlang.org/articles/idiomatic-

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Xavier Bigand
Le 10/12/2013 03:54, Manu a écrit : On 10 December 2013 11:42, deadalnix mailto:deadal...@gmail.com>> wrote: On Sunday, 8 December 2013 at 05:37:09 UTC, H. S. Teoh wrote: Or maybe this is just another one of those cultural old age indicators? Has the term "refactorin

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Atila Neves
* Underline in red errors without compiling I get this one for free in Emacs with flycheck. It's not _really_ without compiling since it calls the compiler behind my back, but it's essentially the same thing.

Re: Option!T

2013-12-10 Thread deadalnix
On Tuesday, 10 December 2013 at 19:26:27 UTC, Andrei Alexandrescu wrote: On 12/10/13 10:59 AM, monarch_dodra wrote: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a collection of exactly one value, b

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Marco Leise
Am Tue, 10 Dec 2013 00:21:16 -0800 schrieb "H. S. Teoh" : > D may not get you all the way to absolute every-last-drop-from-the-CPU > performance I firmly disagree. -- Marco

Re: Option!T

2013-12-10 Thread monarch_dodra
On Tuesday, 10 December 2013 at 19:26:27 UTC, Andrei Alexandrescu wrote: On 12/10/13 10:59 AM, monarch_dodra wrote: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: We have only(x) (http://dlang.org/phobos/std_range.html#.only) to be a collection of exactly one value, b

(OT) D Construction by BRIAN KERNIGHAN

2013-12-10 Thread MattCoder
Hi, Well, I was looking over Brian Kernighan's website when I saw an article titled: "D Construction". Link: http://dailyprincetonian.com/opinion/2012/11/d-construction/ The content wasn't what I expected but it was funny anyway. Quote from the article: "Just don’t slack off too much. Remem

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/10/2013 1:01 PM, Marco Leise wrote: Am Tue, 10 Dec 2013 00:21:16 -0800 schrieb "H. S. Teoh" : D may not get you all the way to absolute every-last-drop-from-the-CPU performance I firmly disagree. Especially since if you write C code in D, you will get exactly C results.

Re: Probable C# 6.0 features

2013-12-10 Thread Namespace
I love Monadic null checking. Would be great if D would have it.

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Dicebot
On Tuesday, 10 December 2013 at 20:36:22 UTC, Walter Bright wrote: On 12/10/2013 1:01 PM, Marco Leise wrote: Am Tue, 10 Dec 2013 00:21:16 -0800 schrieb "H. S. Teoh" : D may not get you all the way to absolute every-last-drop-from-the-CPU performance I firmly disagree. Especially since if

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/10/2013 12:39 PM, Dicebot wrote: I think it is better to rephrase it as "writing C code in D is possible but even less convenient than in C". Why would it be less convenient? At the least, it'll compile a lot faster!

Re: No household is perfect

2013-12-10 Thread Walter Bright
On 12/10/2013 4:28 AM, Russel Winder wrote: I think this position is too restrictive and just wrong. If D is really aiming to stop internal DSLs using operators then D is missing the whole point of abstraction. But as noted I want code not just waffle to further this discussion. Looking forward

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Adam D. Ruppe
On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote: At the least, it'll compile a lot faster! Small C programs compile a *lot* faster than small D programs that use Phobos. import std.stdio; == add half a second to your compile time. $ time dmd hellod.d real0m0.780s # YI

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Paulo Pinto
Am 10.12.2013 22:16, schrieb Adam D. Ruppe: On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote: At the least, it'll compile a lot faster! Small C programs compile a *lot* faster than small D programs that use Phobos. import std.stdio; == add half a second to your compile time.

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread H. S. Teoh
On Tue, Dec 10, 2013 at 10:16:25PM +0100, Adam D. Ruppe wrote: > On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote: > >At the least, it'll compile a lot faster! > > Small C programs compile a *lot* faster than small D programs that > use Phobos. > > import std.stdio; == add half a

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Dicebot
On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote: On 12/10/2013 12:39 PM, Dicebot wrote: I think it is better to rephrase it as "writing C code in D is possible but even less convenient than in C". Why would it be less convenient? At the least, it'll compile a lot faster!

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Adam D. Ruppe
On Tuesday, 10 December 2013 at 21:28:41 UTC, Paulo Pinto wrote: Those are implementation issues, right? Yeah, a lot of the blame can be placed on the intertwined phobos modules. D without phobos is a lot faster to compile (and produces significantly smaller exes).

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread H. S. Teoh
On Tue, Dec 10, 2013 at 10:52:10PM +0100, Adam D. Ruppe wrote: > On Tuesday, 10 December 2013 at 21:28:41 UTC, Paulo Pinto wrote: > >Those are implementation issues, right? > > Yeah, a lot of the blame can be placed on the intertwined phobos > modules. D without phobos is a lot faster to compile (

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Adam D. Ruppe
On Tuesday, 10 December 2013 at 21:39:12 UTC, H. S. Teoh wrote: One of my template-heavy projects take almost 10 seconds to compile just a single source file. Always compile all your D files at once, that's my tip, otherwise you'll pay that cost every time the file is imported! But yeah, my

Re: Option!T

2013-12-10 Thread Jesse Phillips
On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the Option type - a zero or one element collection (range in D terminology). Here's an article discussing it: http://danielwesthei

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Marco Leise
Am Tue, 10 Dec 2013 22:16:25 +0100 schrieb "Adam D. Ruppe" : > On Tuesday, 10 December 2013 at 21:05:53 UTC, Walter Bright wrote: > > At the least, it'll compile a lot faster! > > Small C programs compile a *lot* faster than small D programs > that use Phobos. > > import std.stdio; == add half

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Sean Kelly
On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote: "there is no way proper C code can be slower than those languages." Didn't Bjarne cover this in his C++ performance talk at SD West in 2007? Templates alone can make C++ and D code faster than even hand-optimized C. And that

Re: Probable C# 6.0 features

2013-12-10 Thread Adam Wilson
On Tue, 10 Dec 2013 10:57:59 -0800, Suliman wrote: Maybe it would be possible to get some good idea from next version of C# It's only ideas about next version, but new future maybe next: http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illustrated Let's not forget the biggest feat

Re: Probable C# 6.0 features

2013-12-10 Thread Paulo Pinto
Am 10.12.2013 23:49, schrieb Adam Wilson: On Tue, 10 Dec 2013 10:57:59 -0800, Suliman wrote: Maybe it would be possible to get some good idea from next version of C# It's only ideas about next version, but new future maybe next: http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illust

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Timon Gehr
On 12/10/2013 07:26 PM, Walter Bright wrote: On 12/10/2013 1:58 AM, Timon Gehr wrote: Recovering all immutable and const qualifiers that are possible to assign to the program is simple to do if the whole program is available. I believe you are seriously mistaken about it being simple, or even

Re: Probable C# 6.0 features

2013-12-10 Thread Idan Arye
On Tuesday, 10 December 2013 at 18:58:01 UTC, Suliman wrote: Maybe it would be possible to get some good idea from next version of C# It's only ideas about next version, but new future maybe next: http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illustrated I really like the "Inline

Re: Probable C# 6.0 features

2013-12-10 Thread Timon Gehr
On 12/10/2013 11:49 PM, Adam Wilson wrote: Also I was reading an interview with Anders and he talked about something VERY interesting. Immutable AST's... I wonder how they did that? I assume they just don't expose any mutating operations.

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/10/2013 3:04 PM, Timon Gehr wrote: Malloc is part of the language runtime. Everything needed is known about it, in particular that it is pure (in the D sense). Also, the source code of malloc will not be standard C code. All right, so write your own storage allocator. How are you going to

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/10/2013 3:23 PM, Marco Leise wrote: Isn't it fairer to compile only (-c): dmd -c std_stdio.d 0,30s user 0,07s system 99% cpu 0,374 total dmd -c printf.d 0,00s user 0,00s system 87% cpu 0,008 total gcc -c printf.c 0,02s user 0,01s system 93% cpu 0,031 total Yup, since gcc is not

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/10/2013 1:37 PM, H. S. Teoh wrote: That's not too bad. One of my template-heavy projects take almost 10 seconds to compile just a single source file. And a single string import can add up to 3-4 seconds (well, probably due to CTFE since I call split() on the string). That isn't C-style co

std.utf: use throw UTFException instead of assert(0) in stride, etc

2013-12-10 Thread Timothee Cour
in std.utf shouldn't we throw UTFException instead of assert(0) in stride, etc ?

Re: Probable C# 6.0 features

2013-12-10 Thread Adam Wilson
On Tue, 10 Dec 2013 14:54:23 -0800, Paulo Pinto wrote: Am 10.12.2013 23:49, schrieb Adam Wilson: On Tue, 10 Dec 2013 10:57:59 -0800, Suliman wrote: Maybe it would be possible to get some good idea from next version of C# It's only ideas about next version, but new future maybe next: htt

Re: Probable C# 6.0 features

2013-12-10 Thread Ary Borenszweig
On 12/10/13 5:35 PM, Namespace wrote: I love Monadic null checking. Would be great if D would have it. What does a monad have to do with that? (just out of curiosity... BTW, the other day I friend tried to explain me monads and he realized couldn't understand them himself)

Re: Probable C# 6.0 features

2013-12-10 Thread Manu
On 11 December 2013 06:35, Namespace wrote: > I love Monadic null checking. Would be great if D would have it. > Yeah that's awesome. Definitely the most interesting one to me too. It's that sort of little detail that can make code better/safer due to a convenient side-stepping of coder laziness

Re: Option!T

2013-12-10 Thread Idan Arye
On Tuesday, 10 December 2013 at 22:10:49 UTC, Jesse Phillips wrote: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness of the Option type - a zero or one element collection (range in D

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread H. S. Teoh
On Tue, Dec 10, 2013 at 03:48:51PM -0800, Walter Bright wrote: > On 12/10/2013 1:37 PM, H. S. Teoh wrote: > >That's not too bad. One of my template-heavy projects take almost 10 > >seconds to compile just a single source file. And a single string > >import can add up to 3-4 seconds (well, probably

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread H. S. Teoh
On Tue, Dec 10, 2013 at 11:47:47PM +0100, Sean Kelly wrote: > On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote: > > > >"there is no way proper C code can be slower than those > >languages." > > Didn't Bjarne cover this in his C++ performance talk at SD West in > 2007? Templates alo

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Sean Kelly
On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote: On Tue, Dec 10, 2013 at 11:47:47PM +0100, Sean Kelly wrote: On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote: > >"there is no way proper C code can be slower than those >languages." Didn't Bjarne cover this in his

Re: std.utf: use throw UTFException instead of assert(0) in stride, etc

2013-12-10 Thread Jonathan M Davis
On Tuesday, December 10, 2013 15:52:06 Timothee Cour wrote: > in std.utf shouldn't we throw UTFException instead of assert(0) in stride, > etc ? std.utf only uses assert(0) when that code should be unreachable. It's used to catch bugs in the implementation, not in a function's input. If anything

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread H. S. Teoh
On Wed, Dec 11, 2013 at 01:33:24AM +0100, Sean Kelly wrote: > On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote: > >On Tue, Dec 10, 2013 at 11:47:47PM +0100, Sean Kelly wrote: > >>On Friday, 6 December 2013 at 22:20:19 UTC, Walter Bright wrote: > >>> > >>>"there is no way proper C co

Re: std.utf: use throw UTFException instead of assert(0) in stride, etc

2013-12-10 Thread Timothee Cour
well then it's a bug: https://d.puremagic.com/issues/show_bug.cgi?id=11721 this is the 3rd regression I'm posting today! On Tue, Dec 10, 2013 at 4:45 PM, Jonathan M Davis wrote: > On Tuesday, December 10, 2013 15:52:06 Timothee Cour wrote: > > in std.utf shouldn't we throw UTFException instea

Re: Option!T

2013-12-10 Thread Idan Arye
On Wednesday, 11 December 2013 at 00:08:49 UTC, Idan Arye wrote: On Tuesday, 10 December 2013 at 22:10:49 UTC, Jesse Phillips wrote: On Tuesday, 10 December 2013 at 17:28:26 UTC, Andrei Alexandrescu wrote: I talked to a programmer who knows Scala (among others) and he mentioned the usefulness o

Re: Probable C# 6.0 features

2013-12-10 Thread Rikki Cattermole
On Tuesday, 10 December 2013 at 20:35:08 UTC, Namespace wrote: I love Monadic null checking. Would be great if D would have it. +1 on Monadic null checking. Do miss it from Groovy. For me at least its the only thing on that list that I think D could really use.

Re: Inherent code performance advantages of D over C?

2013-12-10 Thread Walter Bright
On 12/10/2013 4:10 PM, H. S. Teoh wrote: On Tue, Dec 10, 2013 at 03:48:51PM -0800, Walter Bright wrote: On 12/10/2013 1:37 PM, H. S. Teoh wrote: That's not too bad. One of my template-heavy projects take almost 10 seconds to compile just a single source file. And a single string import can add

Re: GUI libraries

2013-12-10 Thread Danni Coy
AFAIK the linux situation looks like this. GTK is the current native toolkit for the Gnome based environments and descendants including Unity. Canonical are trying to move towards Qt for Unity. Qt is the standard toolkit for KDE. However Qt can treat GTK as a native toolkit and will render native

Re: Probable C# 6.0 features

2013-12-10 Thread Xinok
On Tuesday, 10 December 2013 at 18:58:01 UTC, Suliman wrote: Maybe it would be possible to get some good idea from next version of C# It's only ideas about next version, but new future maybe next: http://damieng.com/blog/2013/12/09/probable-c-6-0-features-illustrated Regarding #1 (Primary Cons

Re: Probable C# 6.0 features

2013-12-10 Thread Walter Bright
On 12/10/2013 3:53 PM, Ary Borenszweig wrote: BTW, the other day I friend tried to explain me monads and he realized couldn't understand them himself The best way to learn something is to try to explain it to someone else.