Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 14:13:18 UTC, Patrick Schluter wrote: For the same reason it is in C. If the ambition for D is to be a system language then it should avoid introducing artificial abstractions and work with the machine it runs on, not against. The C model isn't much like x86 at all. You can do operations on 8 bit and 16 bit registers on x86, but C doesn't reflect that reality. I usually defend D's behavior of "blame C". Compatibility is useful for us and conservative programmers like familiarity, but I can't defend C's rules on the merits. They aren't like the processor and they aren't even that useful.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Sat, Apr 29, 2017 at 11:24:36AM +, Patrick Schluter via Digitalmars-d-announce wrote: > On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote: > > The latest WAT I found in D is this one, see if you can figure it > > out: > > > > char ch; > > wchar wch; > > dchar dch; > > > > pragma(msg, typeof(true ? ch : ch));// char - OK > > pragma(msg, typeof(true ? ch : wch)); // int - WAT? > > pragma(msg, typeof(true ? wch : wch)); // wchar - OK > > pragma(msg, typeof(true ? wch : dch)); // uint - WAT? > > pragma(msg, typeof(true ? dch : dch)); // dchar - OK > > > > How an alternation between two character types ends up being int is > > beyond me, but even more inscrutible is why ch : wch produces int > > but wch : dch produces uint. > > That's the C integer promotion rule, nothing suprising here. > > C99 says "if an int can represent all values of the original type, the > value is converted to an int; otherwise, it is converted to an > unsigned int." > > While quite often surprising for people coming from other languages, I > think that Walter's persistence in following the basic C rule is a > good thing. Maybe the documentation should cite more prominently from > the C standard on that point. While it is quite obvious, I noticed > that a lot of people do not know how it works. The problem is that while C integer promotion works well for C, it doesn't for D so much. Perhaps it worked well in the beginning days of D, when D was much closer to C, but today's D has significantly diverged from C in many respects, including making a clear(?) distinction between character types vs. integer types (e.g., char != ubyte). There has been a regression (at least) caused by the above adherence to C integer promotion rules: https://issues.dlang.org/show_bug.cgi?id=17358 There has also been bugs / problems related to overloading between int and char types of the same width (the wrong overload gets chosen). The problem is that because D makes it a point that char and ubyte are different (ditto for wchar / ushort, dchar / uint), people have come to expect that they should be consistently treated differently. But then we run into anachronisms like C integer promotion rules that basically disregard the distinction between integer and character types. So now you have this schizophrenic situation where part of the language (a good chunk of Phobos, for example, and some parts of the compiler/language -- e.g., char.init != ubyte.init) considers them as two different things, but other parts of the language (e.g. here) disregard their distinction. That this inconsistency should lead to bugs should be no surprise. The question now is, are we going to *fix* this situation at its root, or are we going to merely patch over it half-heartedly in the name of not OMG potentially breaking wrong codez! -- and thereby perpetuate this bug-prone situation? I sure hope it's not the latter. T -- The richest man is not he who has the most, but he who needs the least.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 14:13:18 UTC, Patrick Schluter wrote: That's not a simple assumption, it's acknowledgment that a C program runs on real hardware not a virtual machine like Java or C#. Modern X86s are basically virtual machines... The instruction set is decoded and executed on a completely different machine than the original X86. This is no longer true of course, as "registers" are "SIMD sized". SIMD and GP are not related and one will never replace the other. SIMD is generally for floating point, when it is used for integer, it is not for the usual integer semantics and requires special handling in any case. Huh? No, at least on X86 the register is only bits. You can mask floats with ints. So I am pretty sure it will lead to suboptimal code in some instances. Can also be said if it had another semantic. Not sure what you mean here. If every byte is recast to 32bit then you have to prove that it ends up with the same result when computed as 8bit. In C it is cast to the register size (16bit, 32bit or 64bit), because C was designed for 40 years old CPUs where you had a fixed word size (register size). D has locked int to 32 bit, so the register argument no longer makes sense. For the same reason it is in C. If the ambition for D is to be a system language then it should avoid introducing artificial abstractions and work with the machine it runs on, not against. But the C environment no longer works well with the machine it runs on. It is archaic and doesn't really reflect the underlying hardware well. It may seem like it does, but that's only because hardware vendors target C-generated code...
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 11:48:46 UTC, Ola Fosheim Grøstad wrote: On Saturday, 29 April 2017 at 11:24:36 UTC, Patrick Schluter wrote: C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." Well, C is making the simple assumption that registers are int-sized... That's not a simple assumption, it's acknowledgment that a C program runs on real hardware not a virtual machine like Java or C#. This is no longer true of course, as "registers" are "SIMD sized". SIMD and GP are not related and one will never replace the other. SIMD is generally for floating point, when it is used for integer, it is not for the usual integer semantics and requires special handling in any case. So I am pretty sure it will lead to suboptimal code in some instances. Can also be said if it had another semantic. While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing. Why is it a good thing? For the same reason it is in C. If the ambition for D is to be a system language then it should avoid introducing artificial abstractions and work with the machine it runs on, not against.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 11:24:36 UTC, Patrick Schluter wrote: C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." Well, C is making the simple assumption that registers are int-sized... This is no longer true of course, as "registers" are "SIMD sized". So I am pretty sure it will lead to suboptimal code in some instances. While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing. Why is it a good thing?
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote: The latest WAT I found in D is this one, see if you can figure it out: char ch; wchar wch; dchar dch; pragma(msg, typeof(true ? ch : ch));// char - OK pragma(msg, typeof(true ? ch : wch)); // int - WAT? pragma(msg, typeof(true ? wch : wch)); // wchar - OK pragma(msg, typeof(true ? wch : dch)); // uint - WAT? pragma(msg, typeof(true ? dch : dch)); // dchar - OK How an alternation between two character types ends up being int is beyond me, but even more inscrutible is why ch : wch produces int but wch : dch produces uint. That's the C integer promotion rule, nothing suprising here. C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing. Maybe the documentation should cite more prominently from the C standard on that point. While it is quite obvious, I noticed that a lot of people do not know how it works.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 03:44:50 UTC, Nick Sabalausky (Abscissa) wrote: On 04/28/2017 06:11 PM, H. S. Teoh via Digitalmars-d-announce wrote: https://bartoszmilewski.com/2013/09/19/edward-chands/ That is *awesome*! Although, I always saw Eddie Scissors as more of a retelling of Frankenstein. It is rather inaccurate. E.g.: «Imperative languages offer no protection against data races — maybe with the exception of D.» Sounds mostly like a sales pitch for Haskell over C++, glossing over the main reason for why the highest performance parallell algorithms are risky: the actual hardware design. If you don't want that highest speed then you most certainly can protect against data races for many problems in other languages, including C++. This won't change until the hardware changes. Oh well, it kinda has, with GPU programming.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 04/28/2017 06:11 PM, H. S. Teoh via Digitalmars-d-announce wrote: That's the thing about C++: The right way is the obscure way, and the straightforward way is the wrong way. And yesterday's right way is today's wrong way. And apparently (it would seem), the only way NOT to completely fuck *everything* up is to become an expert on every corner of the language, and STAY an expert on all the latest changes. In the immortal words (and voice) of Duke Nukem: "What a mess!" Yep, this always reminds me of: https://bartoszmilewski.com/2013/09/19/edward-chands/ That is *awesome*! Although, I always saw Eddie Scissors as more of a retelling of Frankenstein. D is not without its own flaws and WAT-worthy dark corners, mind you, but in spite it its warts, I still prefer D any day over the masochistic labyrinth of 99 wrong ways to do the same thing (and only 1 "right" way -- until next year) that is C++. Yea, I really think it's more important than many of us realize to heed Herb Sutter's warning and not allow too much worrying about backwards compatibility thus leading D down the same path. When I see people here fret over "Yea, but it may cause breakage", on one hand I understand that can be the responsible stance, but OTOH it also makes me cringe because it's one more "cat" nibbling us to death - I don't want to see it follow in C++'s footsteps and allow these unfixed mistakes build up and damage what made D great in the first place. Especially since "small things that add up to more than the sum of their parts" is a big part of what makes D good in the first place. The latest WAT I found in D is this one, see if you can figure it out: How an alternation between two character types ends up being int is beyond me, but even more inscrutible is why ch : wch produces int but wch : dch produces uint. Ouch. Although yea, guess that's another good reason to just decide Unicode == UTF-8 and be done with it ;) (I don't even care about UTF-8's supposed bloat in eastern alphabets - it's freaking *text* either way. Tale of Genji would be what, some tens of MB in UTF-8? Bah, trim down a few images and overengineered file formats and multimedia clutter if you need a shave a few measly MB so badly. If UTF-32'd won out, the complete works of Shakespeare would in the same boat, some tens of MB in the "wrong" format and we *still* wouldn't have the ASCII-simplicity of code points being equal to graphemes anyway. It's *text*. If your software's footprint or bandwidth is dominated by the size of a bloated text format, then *congratulations*, you officially have one of the smallest, most succinct software footprints in the world, so smile and be happy!)
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote: On Fri, Apr 28, 2017 at 05:11:29PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d-announce wrote: On 04/28/2017 04:26 PM, Atila Neves wrote: > The other day I was reminded that in C++ land one has to > manually write `operator<<` to print things out and > `operator==` to compare things. Not to mention you have to overload operator<, operator!=, operator==, operator>, operator<=, *and* operator>= in order to get the right results in all cases. In D, you have to overload opEquals and opCmp. Hmm, I wonder why I enjoy programming in D more than C++... Comparison is better in C++. This is a weak spot in D. You could do the same in C++ as D if you wanted to. You can detect the presence of operator< in overload templates, but being explicit is not much work and more flexible. Just cut'n'paste the set you want...
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 04/28/2017 02:11 PM, Nick Sabalausky (Abscissa) wrote: > D takes all the current (and former!) application domains > of C/C++, and brings to it basic programmer sanity. When I had asked Luís Marques what the title of the talk should be, he had said import sanity; :) Ali
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Fri, Apr 28, 2017 at 05:11:29PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d-announce wrote: > On 04/28/2017 04:26 PM, Atila Neves wrote: > > The other day I was reminded that in C++ land one has to manually > > write `operator<<` to print things out and `operator==` to compare > > things. Not to mention you have to overload operator<, operator!=, operator==, operator>, operator<=, *and* operator>= in order to get the right results in all cases. In D, you have to overload opEquals and opCmp. Hmm, I wonder why I enjoy programming in D more than C++... > What, seriously?!? > > That's the thing about C++: The right way is the obscure way, and the > straightforward way is the wrong way. And yesterday's right way is > today's wrong way. And apparently (it would seem), the only way NOT to > completely fuck *everything* up is to become an expert on every corner > of the language, and STAY an expert on all the latest changes. In the > immortal words (and voice) of Duke Nukem: "What a mess!" Yep, this always reminds me of: https://bartoszmilewski.com/2013/09/19/edward-chands/ > Seriously, I don't care about the political incorrectness of bashing > or comparing to other languages, this right here is and always was D's > killer feature, the whole reason I got into it in the first place and > have stayed: D takes all the current (and former!) application domains > of C/C++, and brings to it basic programmer sanity. 'Nuff said. D is not without its own flaws and WAT-worthy dark corners, mind you, but in spite it its warts, I still prefer D any day over the masochistic labyrinth of 99 wrong ways to do the same thing (and only 1 "right" way -- until next year) that is C++. The latest WAT I found in D is this one, see if you can figure it out: char ch; wchar wch; dchar dch; pragma(msg, typeof(true ? ch : ch));// char - OK pragma(msg, typeof(true ? ch : wch)); // int - WAT? pragma(msg, typeof(true ? wch : wch)); // wchar - OK pragma(msg, typeof(true ? wch : dch)); // uint - WAT? pragma(msg, typeof(true ? dch : dch)); // dchar - OK How an alternation between two character types ends up being int is beyond me, but even more inscrutible is why ch : wch produces int but wch : dch produces uint. See: https://issues.dlang.org/show_bug.cgi?id=17141 Unfortunately, my dmd-fu isn't up to snuff so my hamfisted PR to fix this problem didn't get very far: it broke a ton of stuff, which is a big no-no, oh noes, we cannot afford to break code, even though basically every dmd release breaks code! Oh well. T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 04/28/2017 04:26 PM, Atila Neves wrote: The other day I was reminded that in C++ land one has to manually write `operator<<` to print things out and `operator==` to compare things. What, seriously?!? That's the thing about C++: The right way is the obscure way, and the straightforward way is the wrong way. And yesterday's right way is today's wrong way. And apparently (it would seem), the only way NOT to completely fuck *everything* up is to become an expert on every corner of the language, and STAY an expert on all the latest changes. In the immortal words (and voice) of Duke Nukem: "What a mess!" Seriously, I don't care about the political incorrectness of bashing or comparing to other languages, this right here is and always was D's killer feature, the whole reason I got into it in the first place and have stayed: D takes all the current (and former!) application domains of C/C++, and brings to it basic programmer sanity. 'Nuff said.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 25 April 2017 at 13:57:53 UTC, XavierAP wrote: On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I have to say it took me a very long time to come up with the title and the abstract. How could I sell D to C++ experts? Luckily, I asked Manu and among a long list of ideas he said "it's about saving time" and "time is money". How can you argue with that? ;) I do agree, but C++ people may be less open to buy the whole package at once... The other speakers (Rust, Haskell) will talk about specific things that they regard as nicer in their languages compared to C++ (safe memory access, @safe concurrency in Rust; std.concurrency Funny story: the first ever (and really, only) program I wrote in Rust had a deadlock in it. I never did figure out why, I just stopped using threads to get rid of the problem. I know it's only anecdata, but "fearless concurrency" does not gel with my experience. I don't even remember the last time I wrote a deadlock in C++, if ever. Not once in D, that's for sure. It's hard to deadlock when you hardly ever lock. :) I have fearless concurrency now, in D. Message passing FTW. side effect safety in Haskell). pure C++ users can more easily agree to these individual points and later become interested in the other languages. Well, let's show them the same points then ;) It's true that D's paradigm is less different from C++ and it's more about being better designed and safer as a whole. It's like, sure you can write 80% of D programs in C++ with only twice the typing at most, In my experience, _at least_ twice the typing, and 3 times as many bugs. And I'm talking about C++14 here. The other day I was reminded that in C++ land one has to manually write `operator<<` to print things out and `operator==` to compare things. Atila
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I have to say it took me a very long time to come up with the title and the abstract. How could I sell D to C++ experts? Luckily, I asked Manu and among a long list of ideas he said "it's about saving time" and "time is money". How can you argue with that? ;) I do agree, but C++ people may be less open to buy the whole package at once... The other speakers (Rust, Haskell) will talk about specific things that they regard as nicer in their languages compared to C++ (safe memory access, concurrency in Rust; side effect safety in Haskell). C++ users can more easily agree to these individual points and later become interested in the other languages. It's true that D's paradigm is less different from C++ and it's more about being better designed and safer as a whole. It's like, sure you can write 80% of D programs in C++ with only twice the typing at most, as long as your compiler supports C++14 at least, and you're super careful with memory... but you'll still be driven insane by the remaining 20% ;)
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Sunday, 23 April 2017 at 12:29:24 UTC, Guillaume Piolat wrote: On Sunday, 23 April 2017 at 12:04:08 UTC, Guillaume Piolat wrote: Hence Rust that sanctified this style. And why it's not that interesting to the modern C++ programmer. Actually, writing Rust made me realise how bad my C++ code actually is. Even with unique_ptr et al. Atila
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 24.04.2017 19:02, Nick Sabalausky (Abscissa) wrote: On 04/24/2017 11:17 AM, Timon Gehr wrote: Also, Java's type system is unsound. Not doubting you, but this sounds interesting. Further info or links? https://dev.to/rosstate/java-is-unsound-the-industry-perspective
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 04/24/2017 11:17 AM, Timon Gehr wrote: Also, Java's type system is unsound. Not doubting you, but this sounds interesting. Further info or links?
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Monday, 24 April 2017 at 15:17:18 UTC, Timon Gehr wrote: Swift allows raw pointer manipulation. I didn't know that Swift had that as a language construct. Link? I know that it provides library solutions for raw pointers, but that can be said for most languages. Java implementations expose similar unsafe features. You think so?
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 24.04.2017 13:33, Ola Fosheim Grøstad wrote: On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote: The trouble is, one cannot look at a piece of code and tell if it follows the rules or not. I.e. it's not about it being possible to write memory safe code in C or C++ (it is), it's about verifying an arbitrary piece of code as being memory safe. I don't think D and Rust fare any better than modern C++ as far as ARBITRARY code goes. Swift and Java does... Swift allows raw pointer manipulation. Java implementations expose similar unsafe features. JVMs have bugs. Also, Java's type system is unsound.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote: The trouble is, one cannot look at a piece of code and tell if it follows the rules or not. I.e. it's not about it being possible to write memory safe code in C or C++ (it is), it's about verifying an arbitrary piece of code as being memory safe. I don't think D and Rust fare any better than modern C++ as far as ARBITRARY code goes. Swift and Java does...
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 4/23/2017 5:04 AM, Guillaume Piolat wrote: The rules of leak-free, exception-safe C++11 aren't so hard. - single-owneship for everything, invent fake owner if needed - std::unique_ptr for owning pointer, raw pointers for borrowed (unique_ptr neatly avoids to write a RAII wrapper for everything) When teams internalize these rules, no more leaks, no more double-free, etc. Hence Rust that sanctified this style. The trouble is, one cannot look at a piece of code and tell if it follows the rules or not. I.e. it's not about it being possible to write memory safe code in C or C++ (it is), it's about verifying an arbitrary piece of code as being memory safe.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 2017-04-22 13:35, David Nadlinger wrote: LDC officially supports shared libraries on macOS. -David That's great. -- /Jacob Carlborg
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Sunday, 23 April 2017 at 12:04:08 UTC, Guillaume Piolat wrote: Hence Rust that sanctified this style. And why it's not that interesting to the modern C++ programmer.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Sunday, 23 April 2017 at 10:16:14 UTC, Walter Bright wrote: On 4/11/2017 8:10 AM, Guillaume Piolat wrote: Newer C++ almost erased leaks and memory errors if you follow it. C and C++ don't have memory leaks if you are careful. The trouble is, there's no checking. The rules of leak-free, exception-safe C++11 aren't so hard. - single-owneship for everything, invent fake owner if needed - std::unique_ptr for owning pointer, raw pointers for borrowed (unique_ptr neatly avoids to write a RAII wrapper for everything) When teams internalize these rules, no more leaks, no more double-free, etc. Hence Rust that sanctified this style.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 4/11/2017 8:10 AM, Guillaume Piolat wrote: Newer C++ almost erased leaks and memory errors if you follow it. C and C++ don't have memory leaks if you are careful. The trouble is, there's no checking.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 22 April 2017 at 10:12:04 UTC, Arek wrote: And no output for ARM64. :/ LDC has beta-quality support for AArch64. --David
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 09:30:28 UTC, Jacob Carlborg wrote: And no official support on macOS. LDC officially supports shared libraries on macOS. -David
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 09:30:28 UTC, Jacob Carlborg wrote: On 2017-04-11 08:50, FreeSlave wrote: D can't compete with C++ until it gets proper dynamic library support on all platforms. As far as I understand there're still problems on Windows. And no official support on macOS. And no output for ARM64. :/ Arek
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 04/11/2017 02:22 AM, qznc wrote: On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ Looks like C++Now has two keynotes. One keynote on D and one keynote on Rust. Maybe they should change their name. ;) I *think* the third one will be related to Haskell but don't quote me on that. I applaud the organizers for inviting other languages. Their keynote theme for this year is "What can C++ learn from other languages?" Ali
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 14:36:18 UTC, Ali Çehreli wrote: On 04/11/2017 02:35 AM, Joseph Rushton Wakeling wrote: will we see you at DConf? :-) Yes. I'm looking forward to it. :) Great! And, likewise :-)
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Monday, April 10, 2017 23:08:16 Ali Çehreli via Digitalmars-d-announce wrote: > I will be presenting D as a time-saving tool at C++Now: > >http://cppnow.org/ > > I have to say it took me a very long time to come up with the title and > the abstract. How could I sell D to C++ experts? Luckily, I asked Manu > and among a long list of ideas he said "it's about saving time" and > "time is money". How can you argue with that? ;) > > Do you agree or disagree that D brings competitive advantage? Please let > me know. They may yet make it into C++ in some form or another, but the lack of ranges in C++ is one of the things that I find really frustrating when I doing stuff for work. In particular, it's incredibly quick and easy to write parsing code for stuff in D with Phobos, whereas it takes a lot more time and effort to write it in C++. But just in general, I find that putting stuff together in D is faster than using C++. C++ is very powerful, but it's also quite clunky. - Jonathan M Davis
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 09:35:39 UTC, Joseph Rushton Wakeling wrote: And the simple clarity of the syntax really helps compared to, say, C++. It's much easier to write and much easier to read and understand. So, once again, it's easier to move fast. As a D beginner I have to say that this one was very visible for me. I´m able to look at any D project read it and undertand it with ease. Very few times I was able to do it that easy looking on c++ sources.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 04/11/2017 08:50 AM, FreeSlave wrote: > D can't compete with C++ until it gets proper dynamic library support on > all platforms. As far as I understand there're still problems on Windows. Go fix it ;). Yes, we still need to make `export` work to replace `dllimport`/`dllexport`, then we can address the couple of low-level linking and TLS issues. Benjamin Thaut works on this and has a workable solution [¹]. Once this is done, DLL support should be on par with OSX/Linux/FreeBSD. Depending on what you want to do, you can already use D DLL's now, but atm. each DLL comes with it's own copy of the standard library, so different DLLs cannot talk to each other (see [²]). As with any ambitious project, we always want to do more than we have resources for, so things tend to not move as fast as everybody wants them to. -Martin [¹]: [pending PR dlang/DIPs#57](https://github.com/MartinNowak/DIPs/blob/fbad186cf9ac8dce335344e64d3b1d880bb750c0/DIPs/archive/DIP45.md) [²]: [Issue 7020 – Exception thrown across DLL is not caught.](https://issues.dlang.org/show_bug.cgi?id=7020)
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: Do you agree or disagree that D brings competitive advantage? Please let me know. Agree. There are different tradeoffs, obviously, and it won't suit all use-cases, but the ability to iterate fast through highly performant and provably correct code is very striking. If you manage your compile-time generics well -- i.e. using them to generalize for use cases that you definitely have, rather than premature generalization -- you can get a lot of power out of this that really helps with _effective_ code re-use. Compile time checks, contracts, and easy built-in unittests all make a big help in being able to make changes to code while maintaining confidence in its correctness -- again, making it faster to get things done. And the simple clarity of the syntax really helps compared to, say, C++. It's much easier to write and much easier to read and understand. So, once again, it's easier to move fast. Are you attending the conference? Not C++Now, I'm afraid. But will we see you at DConf? :-)
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ I have to say it took me a very long time to come up with the title and the abstract. How could I sell D to C++ experts? Luckily, I asked Manu and among a long list of ideas he said "it's about saving time" and "time is money". How can you argue with that? ;) Do you agree or disagree that D brings competitive advantage? Please let me know. Safety (bounds checking, @safe, memory safety) is huge for debugging. You can probably steal a lot from Walters DConf Talk. Compilation time, because a quick iteration of edit-compile-test is significant for productivity and really underrated. C++ interop, so you can migrate from C++ to D in small steps and without building a C API bridge. Little things C++ lacks because it is too old: A package manager, a standard string type. Meta programming naturally, but "static if" might trail into discussions about concepts, so it is a little bit dangerous?
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 2017-04-11 08:50, FreeSlave wrote: D can't compete with C++ until it gets proper dynamic library support on all platforms. As far as I understand there're still problems on Windows. And no official support on macOS. -- /Jacob Carlborg
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ Looks like C++Now has two keynotes. One keynote on D and one keynote on Rust. Maybe they should change their name. ;)
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ I have to say it took me a very long time to come up with the title and the abstract. How could I sell D to C++ experts? Luckily, I asked Manu and among a long list of ideas he said "it's about saving time" and "time is money". How can you argue with that? ;) Do you agree or disagree that D brings competitive advantage? Please let me know. Are you attending the conference? Ali D can't compete with C++ until it gets proper dynamic library support on all platforms. As far as I understand there're still problems on Windows.
