www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D as a betterC a game changer ?

reply Dan Partelly <i i.com> writes:
It is a game chager for D, or a least huge step forward  but what 
is the killer feature against a betterC done through C++ + STL ? 
Can anyone who really know both D and C++ godlike say why  D as 
betterC and not C++ as better C? Maybe Andrei or Walter ?

Learning a new language (as opposed to playing with it, which 
takes hours) takes a lot if investment in time. So please somone 
help us pople new to it.

1. D BetterC blogs says no RAII.
2. No high level library available. C++ has the whole power of 
STL which can be used in a better C mode. D has to use only C 
standard lib. STL gets you covered for a lot. This is *huge* win 
for C++. I cannot overstate how important this is.
3. No exceptions. (Blessing or curse ?) C++ in a betterC mode
4. saftey. Full saftey is neither D as better C in C++. Arrays ? 
use STL. Uninit locals varibales ?  good compiler implementation 
-Wall -Werror.
5. Most C++ features cannot be inhibited with a compiler switch. 
Oh well. This sucks.
6. No array overflows in D. STL solves this. Design by contract 
in D and not in C++. Usefull for some projects.
7. Modules. This is big for keeping things neat. Not in C++.
8. metaprogramming. better in D no question about it, even after 
a couple of days one can see this. Static introspection. Not in 
C++, but it will come. D wins for now.
9. Easy to port C to D. Should be as easier to port to C++ with 
saftey features.
10. Ecosystem. C++... the whole computing world rests on a C/C++ 
titan. A lot of quality code which have run sometimes in exces of 
40 years getting mentenance and bug fixes. What is D situation.
11. Sintax. D prolly wins here especially for metaprogramming.
12. Speed of compiles. D is fast to compile needs quantifying. 
LDC/CLANG not dmd/clang comparisions. same lvel of optimizations. 
Then you can get an accurate ideea. Speed of compilation is king 
for bottom up design.
13. Refactors. C++ is meh. Tools arrise to make this easier. How 
is D here ? Also
great feature for bottom up design.
14. Debugging. How are debugging tools in D compared to C++ ?


 D as betterC really is a game changer, for anyone who cares to 
 give it a try.
Yes, it really is.
Dec 24 2017
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly wrote:
 It is a game chager for D, or a least huge step forward  but 
 what is the killer feature against a betterC done through C++ + 
 STL ? Can anyone who really know both D and C++ godlike say why
  D as betterC and not C++ as better C? Maybe Andrei or Walter ?
The motivation behind the -betterC flag is *not* to write new programs in the general case. It's to make it a whole lot easier to a) port existing C code to D and b) enable D code to be used in places where one might otherwise use C. That's hard to do with the full range of D features because of the dependency on DRuntime. By taking away that dependency and treating D solely as a "better C", it becomes much easier. For example, say you have a program written in C that you'd like to port to D. With -betterC, you can move each function into a D module one at a time, compile to an object file and link in to the program without worrying about linking in DRuntime or creating your own object.d stub. Your program continues to work just as if it were sill all in C. Then, once the program is ported you can start refactoring it to use regular D features. This approach reduces the chance for errors and makes it easier to ensure the program works as it always has. From that perspective, comparing "D as a better C" to C++ is not appropriate. Comparing regular D (without -betterC) to C++ makes more sense. That said, some things that currently are not supported in -betterC mode may be in the future. For example, the upcoming 2.078.0 release will add RAII support (including scope(exit))[1] to -betterC mode. Future versions might support exception handling of some kind. But for new code, D is already a better C without the -betterC flag. https://dlang.org/changelog/2.078.0.html#raii
Dec 24 2017
parent bpr <brogoff gmail.com> writes:
On Sunday, 24 December 2017 at 10:57:28 UTC, Mike Parker wrote:
 The motivation behind the -betterC flag is *not* to write new 
 programs in the general case.
Whether you agree or not, that is *exactly* how some programmers would like to use it. I think that's a good thing, and I hope lots of other people do too, and start writing lots of betterC code. Let a thousand flowers bloom.
 From that perspective, comparing "D as a better C" to C++ is 
 not appropriate. Comparing regular D (without -betterC) to C++ 
 makes more sense.
If you think that GCs suck, or at least, that the D GC sucks, then D doesn't fare well in the comparison with C++. Rust might, by that criteria. I'd have preferred not to have worded it that way, since I don't think GCs suck in general, but it seems there's a big failure to communicate between different camps of programmers, which affects D more than other languages since it is intended to be a very general purpose language, much like C++. GC is not an unqualified positive
 That said, some things that currently are not supported in 
 -betterC mode may be in the future. For example, the upcoming 
 2.078.0 release will add RAII support (including 
 scope(exit))[1] to -betterC mode. Future versions might support 
 exception handling of some kind.
That's great!
 But for new code, D is already a better C without the -betterC 
 flag.
In general, GCs and runtimes don't compose well, so if you write a D library that you want to be called from a language with its own GC and runtime, that's yet another hoop to jump through. Go might be a better C for some people, but extending Python with Go libraries hasn't caught on. New D libraries written as betterC handle this case.
Dec 24 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/24/2017 2:11 AM, Dan Partelly wrote:
 
 It is a game chager for D, or a least huge step forward  but what is the
killer 
 feature against a betterC done through C++ + STL ? Can anyone who really know 
 both D and C++ godlike say why  D as betterC and not C++ as better C? Maybe 
 Andrei or Walter ?
Anyone using C that wanted to move to C++ has already done so. For those left, C++ is not an option for whatever reason. D is not billed as betterC++ (yet), though Andrei is working on it (essentially building an interface to C++ STL).
 Learning a new language (as opposed to playing with it, which takes hours)
takes 
 a lot if investment in time. So please somone help us pople new to it.
 
 1. D BetterC blogs says no RAII.
It has RAII now (recently added).
 2. No high level library available. C++ has the whole power of STL which can
be 
 used in a better C mode. D has to use only C standard lib. STL gets you
covered 
 for a lot. This is *huge* win for C++. I cannot overstate how important this
is.
Most of Phobos is actually workable with betterC, it's just that nobody had gone through and figured out what is.
 3. No exceptions. (Blessing or curse ?) C++ in a betterC mode
People who use C are not really interested in exceptions. EH adds overhead (there is no such thing as zero cost exceptions).
 4. saftey. Full saftey is neither D as better C in C++. Arrays ? use STL.
Uninit 
 locals varibales ?  good compiler implementation -Wall -Werror.
D as betterC has full safety built in, via dip1000 etc. Experience shows that C is not a safe language, neither is C++, despite STL.
 5. Most C++ features cannot be inhibited with a compiler switch. Oh well. This 
 sucks.
 6. No array overflows in D. STL solves this. Design by contract in D and not
in 
 C++. Usefull for some projects.
STL solves it only if STL is used. That's a large barrier.
Dec 24 2017
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Sunday, 24 December 2017 at 22:33:38 UTC, Walter Bright wrote:
 On 12/24/2017 2:11 AM, Dan Partelly wrote:
 D is not billed as betterC++ (yet), though Andrei is working on 
 it (essentially building an interface to C++ STL).
You piqued my interest. Link?
Dec 24 2017
parent Joakim <dlang joakim.fea.st> writes:
On Monday, 25 December 2017 at 00:05:07 UTC, 12345swordy wrote:
 On Sunday, 24 December 2017 at 22:33:38 UTC, Walter Bright 
 wrote:
 On 12/24/2017 2:11 AM, Dan Partelly wrote:
 D is not billed as betterC++ (yet), though Andrei is working 
 on it (essentially building an interface to C++ STL).
You piqued my interest. Link?
I think this is what he's referring to: http://dconf.org/2017/talks/caciulescu.html https://youtube.com/watch?v=c5zGnOWKaGo
Dec 25 2017
prev sibling parent reply Dan Partelly <i i.com> writes:
On Sunday, 24 December 2017 at 22:33:38 UTC, Walter Bright wrote:

Most of Phobos is actually workable with betterC, it's just 
that nobody had gone through >>and figured out what is.
Could you "fix" Phobos so it works out of the box regardless with no GC runtime ? Or at least properly label the each thing whatever it works in "betterC' or not ?
 3. No exceptions. (Blessing or curse ?) C++ in a betterC mode
People who use C are not really interested in exceptions. EH adds overhead (there is no such thing as zero cost exceptions).
I disagree: 1. Exceptions can be done "you do not use it, you do not pay for them". Also, compiler switches to diable exceptions totally exist in most compilers. 2. Expceptions can be implemented in such a way that the run-time cost, when used ,is minimal. 3. In several extensive C programs I seen, expception handling was used. A poor man's version implemented with setjmp/longjmp, but neverthless was there. And it was very well used, it was not code done by somone who learned a gimmick and abused it everywhere. It was the sanest way to handle errors in that portion of the code. The use was confined where needed. 4. Windows C compilers long had access to SEH mechanisms. __except{} __finally{} where might usefull. This is yet another form of exception handling. It was used extensivly by people workin on NT platform. It was even used in kernel code, if you look in kernel you can find handlers for try/finally in a lot of places. Yes, NT's kernel engineers agreed that in some places it was well worth to pay the run-time cost. 5. When I wrote for unices, the thing I missed most in C as compared to writting in C for NT was SEH support. It really solved some problems very elgantly, and as Im sure you agree __finally is very valuable, after all you put it in D with a different syntax.
Dec 25 2017
next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Monday, 25 December 2017 at 09:25:46 UTC, Dan Partelly wrote:

 2. Expceptions can be implemented in such a way that the 
 run-time cost, when used ,is minimal.
I did some testing a few years ago with g++ and the ARM Cortex-M platform. I found that, compared with checking return values, using exceptions improved performance of the no-throw path, but paid a heavy cost for the throw path. I think that is a useful tradeoff if exceptions are used judiciously. Mike
Dec 25 2017
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Monday, 25 December 2017 at 09:25:46 UTC, Dan Partelly wrote:
 On Sunday, 24 December 2017 at 22:33:38 UTC, Walter Bright 
 wrote:

Most of Phobos is actually workable with betterC, it's just 
that nobody had gone through >>and figured out what is.
Could you "fix" Phobos so it works out of the box regardless with no GC runtime ? Or at least properly label the each thing whatever it works in "betterC' or not ?
WIP: https://github.com/dlang/phobos/pull/5952
Dec 25 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2017 1:25 AM, Dan Partelly wrote:
 1. Exceptions can be done "you do not use it, you do not pay for them". Also, 
 compiler switches to diable exceptions totally exist in most compilers.
Those switches exist because it is not free.
 3. In several extensive C programs I seen, expception handling was used. A
poor 
 man's version implemented with setjmp/longjmp, but neverthless was there. And
it 
 was very well used, it was not code done by somone who learned a gimmick and 
 abused it everywhere. It was the sanest way to handle errors in that portion
of 
 the code. The use was confined where needed.
You can use setjmp/longjmp in betterC. After all, they are just library functions.
Dec 25 2017
parent reply Dan Partelly <i i.com> writes:
On Monday, 25 December 2017 at 20:36:56 UTC, Walter Bright wrote:
 You can use setjmp/longjmp in betterC. After all, they are just 
 library functions.
This is self evident. However, this was not the point of my post. My point was to refute your statement that no C programmer would care about exceptions. If what you say is true, how comes SEH was used so intensively on Windows by C programmers , and how come many programmers homebreaw their own using setjmp/longjmp to use it?
Dec 26 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/26/2017 12:40 AM, Dan Partelly wrote:
 This is self evident. However, this was not the point of my post. My point was 
 to refute your statement that no C programmer would care about exceptions. If 
 what you say is true, how comes SEH was used so intensively on Windows by C 
 programmers , and how come many programmers homebreaw their own using 
 setjmp/longjmp to use it?
Standard C has always had setjmp/longjmp, so "exceptions" are part of the language. SEH is used on Windows because Microsoft designed the Windows API to pretty much force people to use it. Its absence on every other OS suggests it is hardly that desirable.
Dec 26 2017
parent reply Dan Partelly <i i.com> writes:
rammers homebreaw their
On Tuesday, 26 December 2017 at 23:02:18 UTC, Walter Bright wrote:
 own using setjmp/longjmp to use it?
Standard C has always had setjmp/longjmp, so "exceptions" are part of the language.
So then why not have first class support for them in language instead of having the programmer go through hoops to use them ?
 SEH is used on Windows because Microsoft designed the Windows 
 API to pretty much force people to use it. Its absence on every 
 other OS suggests it is hardly that desirable.
There where no successful operating system written after NT(1993). It's presence on NT might suggest that it got it right, not that it got it wrong. You and I might **feel** differently on the area. Surely SEH its much better than the state on POSIX in this area. Besides, the point is the C programmers used this feature. It was not "forced" on you. It was also used in kernel, where it was not "forced" on programmers by any API, since they designed the APIs. Cutler's pose considered OK to pay the price in many situation. Truth is, It was convenient to use it. This is why people used it. Not that the terrific API design of Windows forced them. I seen programs for NT written in C which barely used any Win API but used SEH. Made code much simpler and easier to maintain imo. __finally alone was a stroke of genius for that time.
Dec 27 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 12:24 AM, Dan Partelly wrote:
 So then why not have first class support for them in language instead of
having 
 the programmer go through hoops to use them ?
Because then it is no longer betterC, because it will require the druntime.
Dec 27 2017
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly wrote:

 D as betterC really is a game changer, for anyone who cares 
 to give it a try.
Yes, it really is.
The fact that -betterC exists is a glaring admission that D "got it wrong". -betterC was an idea that I heard Walter propose a few years ago, and probably existed in his mind long before that, but has only been actively developed in the past year, maybe two. AIUI the primary motivation for the current development around -betterC is to use it for DMD's backend, which is still written in C+ (not a typo). So that begs the rhetorical question: What did D get so wrong that makes it unsuitable for DMD's backend. Or more generally, what did D get so wrong that -betterC was required? Why not fix the language so such things aren't required? Mike
Dec 25 2017
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 25 December 2017 at 10:06:31 UTC, Mike Franklin wrote:
 On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly wrote:

 D as betterC really is a game changer, for anyone who cares 
 to give it a try.
Yes, it really is.
The fact that -betterC exists is a glaring admission that D "got it wrong".
I strongly disagree. D got it right, but when there's a heavy investment in an existing code base, there has to be a strong incentive to port to a different language. The less work required to do so, the lower that barrier becomes. Support for inner classes was motivated by a desire to make porting Java code easier. Support for COFF was motivated by requests to better integrate with existing Windows toolchains. extern(C), extern(C++), -betterC, and a future "Better C++" are all in that vein. None of this is evidence of anything D got wrong, but rather that the range of excuses for not adopting D is shrinking.
Dec 25 2017
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 25 December 2017 at 10:40:09 UTC, Mike Parker wrote:
 On Monday, 25 December 2017 at 10:06:31 UTC, Mike Franklin 
 wrote:
 On Sunday, 24 December 2017 at 10:11:37 UTC, Dan Partelly 
 wrote:

 D as betterC really is a game changer, for anyone who cares 
 to give it a try.
Yes, it really is.
The fact that -betterC exists is a glaring admission that D "got it wrong".
I strongly disagree. D got it right, but when there's a heavy investment in an existing code base, there has to be a strong incentive to port to a different language. The less work required to do so, the lower that barrier becomes. Support for inner classes was motivated by a desire to make porting Java code easier. Support for COFF was motivated by requests to better integrate with existing Windows toolchains. extern(C), extern(C++), -betterC, and a future "Better C++" are all in that vein. None of this is evidence of anything D got wrong, but rather that the range of excuses for not adopting D is shrinking.
To clarify Mike's point, the dmd backend was taken from the existing dmc C/C++ compiler, which started in the '80s. It wasn't written in D because D didn't exist back then! The backend could be turned into normal GC'ed D, but Walter still supports dmc and I guess it's easier to just port it all to betterC D. IOW, it's not a matter of what D got wrong that it needs betterC but what those old languages got wrong that D must adapt to, because of all the old C/C++ code out there.
Dec 25 2017
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, December 25, 2017 11:18:58 Joakim via Digitalmars-d wrote:
 To clarify Mike's point, the dmd backend was taken from the
 existing dmc C/C++ compiler, which started in the '80s.  It
 wasn't written in D because D didn't exist back then!  The
 backend could be turned into normal GC'ed D, but Walter still
 supports dmc and I guess it's easier to just port it all to
 betterC D.
Using betterC, it's fairly easy to port a program over in a piecemeal manner, whereas that's a royal pain if you're using the full language and druntime. Once the port to D is completed, then normal D can be used without problems. Honestly, I don't think that there's really any reason to use betterC for most programs, but it does make calling D from C much easier, so folks who are in an environment where they need to call D from C/C++ may want to use betterC to make that more reasonable (though at the cost of a number of useful language features). I expect that there will be some indivuals who will latch onto betterC for one reason or another, but I also expect that the vast majority of D programmers aren't going to want to put up with its restrictions. Personally, I don't see much point in using D if I'm going to be restricted to betterC. At that point, I'd much rather just use C++. I might port something using betterC, but that's the most that I'd ever consider. I actually want a fully featured language, and D without a runtime is doomed to be severely crippled even if it doesn't have to be quite as crippled as it is now. - Jonathan M Davis
Dec 25 2017
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Monday, 25 December 2017 at 11:18:58 UTC, Joakim wrote:

 IOW, it's not a matter of what D got wrong that it needs 
 betterC but what those old languages got wrong that D must 
 adapt to, because of all the old C/C++ code out there.
Rust is an example of a language that got it right. It is inherently memory-safe, can interface with legacy code requiring essentially no runtime, and still has optional reference counting, and plans for an optional garbage collector [1]. The key innovation in Rust is that it didn't bake such things into the language. That's where D got it wrong, requiring D to now back out such things with features like -betterC and nogc. There is hope for D, however. It may be possible to obsolete -betterC, by levereging design-by-introspection directly in the compiler (i.e. the compiler introspects the runtime, or the lack thereof). I'm researching this and the first of such PRs was recently merged [2]. Following this pattern, it may be possible to use D without the runtime by simply avoiding those D features that require it (assuming I can figure out how to get the implementation right). Users will be able to implement the full runtime, no runtime, and everything in between. In other words, pay for only what you choose to use. Mike [1] - https://www.rust-lang.org/en-US/faq.html#is-rust-garbage-collected [2] - https://github.com/dlang/dmd/pull/7395
Dec 26 2017
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 26 December 2017 at 19:34:35 UTC, Mike Franklin wrote:

 Rust is an example of a language that got it right.
Rust got it right for a single, very specialized use case. The cost is that the language is of interest to the tiny fraction of programmers for whom that use case is relevant. Most don't want to read a dissertation on memory management to write Hello World, and having a weirder syntax than Haskell doesn't help either. D is a programming language appropriate for many use cases.
Dec 26 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 01:39 +0000, bachmeier via Digitalmars-d wrote:
 On Tuesday, 26 December 2017 at 19:34:35 UTC, Mike Franklin wrote:
=20
 Rust is an example of a language that got it right.
=20 Rust got it right for a single, very specialized use case. The=20 cost is that the language is of interest to the tiny fraction of=20 programmers for whom that use case is relevant. Most don't want=20 to read a dissertation on memory management to write Hello World,=20 and having a weirder syntax than Haskell doesn't help either. D=20 is a programming language appropriate for many use cases.
Don't you believe it. Rust is attracting a lot of people and financial support from people who used C and failed to be interested in C++ because it didn't add memory safety. The example I am interested in is GStreamer. It's a C system that has C++, Python, D, etc. bindings but had no interested in not being a C system until Rust arrived. Now there is a huge push to it being a Rust system, exactly because Rust provides something C doesn't have and C++ didn't support. D wasn't an option here due to lack of knowledge by the GStreamer crew. Now D has no future in this arena despite GtkD providing a D binding, it is all Rust-bound. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 27 2017
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 27 December 2017 at 16:42:49 UTC, Russel Winder 
wrote:

 D wasn't an  option here due to lack of knowledge by the 
 GStreamer crew.
That's another things I really don't understand... /Paolo
Dec 27 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 16:50 +0000, Paolo Invernizzi via Digitalmars-d
wrote:
 [=E2=80=A6]
=20
 That's another things I really don't understand...
The community know of C, obviously. They know of C++ and have consciously ignored it. They know of Rust and have embraced it. They have never heard of D. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 27 2017
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 27 December 2017 at 18:01:46 UTC, Russel Winder 
wrote:
 On Wed, 2017-12-27 at 16:50 +0000, Paolo Invernizzi via 
 Digitalmars-d wrote:
 […]
 
 That's another things I really don't understand...
The community know of C, obviously. They know of C++ and have consciously ignored it. They know of Rust and have embraced it. They have never heard of D.
I still think that's just a matter of doing well the homework. If you are searching for alternatives to C, D is not so hidden, if alone I alone managed to find it, long ago... /** * KickStart provides logic to upgrade\start\watchdog a target process. * * Author: Paolo Invernizzi * Date: Jun 26, 2006 * * License: All rights are reserved. Reproduction or transmission in whole or * in part, in any form or by any means, electronic, mechanical or otherwise, is * prohibited without prior written permission of the copyright owner. * */ module kickstart.kickstart;
Dec 27 2017
prev sibling parent reply Dan Partelly <i i.com> writes:
On Tuesday, 26 December 2017 at 19:34:35 UTC, Mike Franklin wrote:

 Rust is an example of a language that got it right.  It is 
 inherently memory-safe, can interface with legacy code 
 requiring essentially no runtime, and still has optional 
 reference counting, and plans for an optional garbage collector 
 [1].
I could not agree more with this. It is unfortunate D has dependencies on a garbage collector in language proper and in std. Of course, only if it wants to go against C/C++, and the fact a -betterC exists suggests that it does. If it wants a place with industrial strength GC implementation and live happily ever after. The situation is a bit weird today for an outsider like me. Make no mistake, outsider first impressions count , even if they contain errors. This is because the adoption of a language will rather be a function of social factors then technical excellence, as I mentioned before on this board The D personality is mixed: 1. A language and a std depending on GC, but with an imprecise GC (do they really want that marginal speed ??) suggesting they want to go against Java like 2. Promoted as language which can be used with no GC (but practically you cannot, at least not easily because a lot of the core language depends on GC, and what is worst std depends on it too, and made the mistake to put hashes vectors and strings in language proper rather than lib ) . This marketing suggest they care about 0 cost abstractions , but they where an afterthought added when they realized they are useful. Which is weird since they also have second to none compatibility linking against C, which suggest they where aware of how important this whole business is. 3. Now seeing a -betterC mode, which is really 0 cost abstraction and delivers , but removes from language what it should have been a library in the first place, without providing a library alternative from it and a crippled std. All could have been prevented by going the C++ route of 0 cost abstraction, and have a stellar std which also offered a GC for those who want it. *ALL* language features could have been implemented in this mode.
Dec 27 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Wednesday, 27 December 2017 at 08:59:10 UTC, Dan Partelly 
wrote:
 The D personality is mixed:
...
I think stating it that way implies some kind of psychopathology ;-) It would be better, and more accurate, to state that 'The D personality has had to evolve over a long period of time'. Rust appeared..what..only 7 years ago? It has the advantage of not having to evolve from a period beginning at least 10 years before that.. IMHO..What will help the cause, in terms of keeping D as a 'modern' programming language, is the willingness of its designers and its community to make and embrace 'breaking changes' ... for example, making safe the default, instead of system.
Dec 27 2017
next sibling parent reply Pawn <pawn011102 gmail.com> writes:
On Wednesday, 27 December 2017 at 09:39:22 UTC, codephantom wrote:
 IMHO..What will help the cause, in terms of keeping D as a 
 'modern' programming language, is the willingness of its 
 designers and its community to make and embrace 'breaking 
 changes' ... for example, making  safe the default, instead of 
  system.
It's been expressed that there are now too many codebases such that introducing "breaking changes" would upset many people and companies. D is a mature language, not a young one.
Dec 27 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Wednesday, 27 December 2017 at 10:10:03 UTC, Pawn wrote:
 It's been expressed that there are now too many codebases such 
 that introducing "breaking changes" would upset many people and 
 companies. D is a mature language, not a young one.
To that.. I say...tuff ;-) A breaking change between major version releases, should be something users can accomodate. If they are not willing to accomodate that, then fine, they can stay stuck on a working version that works on their code. But let that be a decision for them, rather than a decision they force on everyone else. D needs to be bold, and go where no one as has gone before... .. . I just finished watching Walter's opening talk at D conf 2017, and it seems that a lot of work has gone on to make D safe by default, and yet, it is still not safe 'by default'.
Dec 27 2017
parent Pawn <pawn011102 gmail.com> writes:
On Wednesday, 27 December 2017 at 12:46:20 UTC, codephantom wrote:
 To that.. I say...tuff ;-)

 A breaking change between major version releases, should be 
 something users can accomodate. If they are not willing to 
 accomodate that, then fine, they can stay stuck on a working 
 version that works on their code.

 But let that be a decision for them, rather than a decision 
 they force on everyone else.

 D needs to be bold, and go where no one as has gone before... 
 .. .

 I just finished watching Walter's opening talk at D conf 2017, 
 and it seems that a lot of work has gone on to make D safe by 
 default, and yet, it is still not safe 'by default'.
I'd love for safe to be the default, and yeah, a major version change should implicate breaking changes. With that said, it's still D2. So perhaps D3 can include these "radical" ideas? On Wednesday, 27 December 2017 at 13:37:17 UTC, Adam D. Ruppe wrote:
 Just make it opt in at the module level and have the opposite 
 attributes added. I suggest:

  strict module foo;


 And that little  strict (or whatever name) thing indicates you 
 want newer stuff for the entire module.

 No breakage, no community split, very little hassle. Javascript 
 has had a fair amount of success with opt in stuff like this.
This is a good compromise!
Dec 27 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 27 December 2017 at 10:10:03 UTC, Pawn wrote:
 It's been expressed that there are now too many codebases such 
 that introducing "breaking changes" would upset many people and 
 companies. D is a mature language, not a young one.
Just make it opt in at the module level and have the opposite attributes added. I suggest: strict module foo; And that little strict (or whatever name) thing indicates you want newer stuff for the entire module. No breakage, no community split, very little hassle. Javascript has had a fair amount of success with opt in stuff like this.
Dec 27 2017
parent codephantom <me noyb.com> writes:
On Wednesday, 27 December 2017 at 13:37:17 UTC, Adam D. Ruppe 
wrote:
 On Wednesday, 27 December 2017 at 10:10:03 UTC, Pawn wrote:
 It's been expressed that there are now too many codebases such 
 that introducing "breaking changes" would upset many people 
 and companies. D is a mature language, not a young one.
Just make it opt in at the module level and have the opposite attributes added. I suggest: strict module foo; And that little strict (or whatever name) thing indicates you want newer stuff for the entire module. No breakage, no community split, very little hassle. Javascript has had a fair amount of success with opt in stuff like this.
Well, to advance the language, I think we need to start breaking some egss, but, we also need a magic wand. Scott Meyers makes the case well, for C++. http://scottmeyers.blogspot.com.au/2015/11/breaking-all-eggs-in-c.html Someone needs to make the case for D too.
Dec 27 2017
prev sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 12/27/17 00:10, Pawn wrote:
 On Wednesday, 27 December 2017 at 09:39:22 UTC, codephantom wrote:
 IMHO..What will help the cause, in terms of keeping D as a 'modern'
 programming language, is the willingness of its designers and its
 community to make and embrace 'breaking changes' ... for example,
 making  safe the default, instead of  system.
It's been expressed that there are now too many codebases such that introducing "breaking changes" would upset many people and companies. D is a mature language, not a young one.
This is not true. I was at DConf one year (can't remember which) and I watched the representative of one of D's larger corporate users do everything but actually get on his knees and beg Walter to make a breaking change. IIRC they demonstrated their work around for the missing change a couple of DConf's later. The reason that D isn't making breaking changes is that the language has enough broken stuff as it is. It does not make much sense to fork a code-base with significant known issues, break more things without fixing the existing things, and then release as a new version. It would create even more bugs and perpetuate the 'D is broken' meme. Once D2 has been thoroughly vetted and is free of known-bugs (sometimes called Zero Bug Bounce, there may be unknown bugs that are discovered, but all known bugs are fixed). Additionally, consider that if we have a stable base in D2 it will be much easier to merge bug-fixes into D3 while D3 is being worked on. Let's fix the crap we have now. It'll take a while, it's not sexy, and it certainly won't make headlines on HN or Reddit. But it will have the effect of combating the biggest negative that D has to adoption. The perception of instability. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Dec 30 2017
parent codephantom <me noyb.com> writes:
On Saturday, 30 December 2017 at 21:40:29 UTC, Adam Wilson wrote:
 This is not true. I was at DConf one year (can't remember 
 which) and I watched the representative of one of D's larger 
 corporate users do everything but actually get on his knees and 
 beg Walter to make a breaking change. IIRC they demonstrated 
 their work around for the missing change a couple of DConf's 
 later.
Are you referring to this: https://www.youtube.com/watch?v=DinkkD6Pt34 We don't all need to be that "ruthless with memory efficiency" ( e.g.I have 24GB of memory on my desktop pc! GC kicks in at what...20MB??) But some really good points were made nonetheless, and I enjoyed the perspective he offered.
 Let's fix the crap we have now. It'll take a while, it's not 
 sexy, and it certainly won't make headlines on HN or Reddit. 
 But it will have the effect of combating the biggest negative 
 that D has to adoption. The perception of instability.
A little overstated perhaps.. I certainly would not be using the word 'crap' or 'instability' describe the current state of D. But D could benefit from some focused tender love, and care ;-)
Dec 30 2017
prev sibling parent reply Dan Partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 09:39:22 UTC, codephantom wrote:
 I think stating it that way implies some kind of 
 psychopathology ;-)

 It would be better, and more accurate, to state that 'The D 
 personality has had to evolve over a long period of time'.
Well, C++ had to evolve over a very long period of time, and maintain compatibility with C. No other programming language had to deal with technical and social issues C++ had to deal with. By comparison, D is young, and had the advantage it had no constrains to be compatible (language wise) with another language. Evolution time is not an excuse to a mixed personality (even if perceived). For all it's evolution time and mistakes and idiotic size of the language to pay for C's sins and omissions I do not see C++ as mixed personality. I never did. It evolved consistently. Also, another language, Ada went through 1 standard and 3 major revisions in almost 35 years and retained it's personality basically unchanged. Too bad it was designed with a Wirthian syntax, which IMO was one of the factors it doomed it. D went GC, but no quite mandatory GC, also not quite able to run its in entirety without GC, then in it's old age, went for cosmetic surgery to look like slim and sexy miss C. Much like a beautiful and capricious women with commitment issues and a fear of aging which went through 5 husbands. And it all started with a GC and several wrong defaults ....
 IMHO..What will help the cause, in terms of keeping D as a 
 'modern' programming language, is the willingness of its 
 designers and its community to make and embrace 'breaking 
 changes' ... for example, making  safe the default, instead of 
  system.
God knows. All "x" users of D would scream bloody murder, imo.
Dec 27 2017
next sibling parent Mengu <mengukagan gmail.com> writes:
On Wednesday, 27 December 2017 at 14:06:51 UTC, Dan Partelly 
wrote:
 On Wednesday, 27 December 2017 at 09:39:22 UTC, codephantom 
 wrote:
[...]
Well, C++ had to evolve over a very long period of time, and maintain compatibility with C. No other programming language had to deal with technical and social issues C++ had to deal with. By comparison, D is young, and had the advantage it had no constrains to be compatible (language wise) with another language. Evolution time is not an excuse to a mixed personality (even if perceived). For all it's evolution time and mistakes and idiotic size of the language to pay for C's sins and omissions I do not see C++ as mixed personality. I never did. It evolved consistently. Also, another language, Ada went through 1 standard and 3 major revisions in almost 35 years and retained it's personality basically unchanged. Too bad it was designed with a Wirthian syntax, which IMO was one of the factors it doomed it. D went GC, but no quite mandatory GC, also not quite able to run its in entirety without GC, then in it's old age, went for cosmetic surgery to look like slim and sexy miss C. Much like a beautiful and capricious women with commitment issues and a fear of aging which went through 5 husbands. And it all started with a GC and several wrong defaults ....
 [...]
God knows. All "x" users of D would scream bloody murder, imo.
if that would become the d way and made us write memory safe code, why not? rust developers already have to write code under compiler dictated terms and nobody's complaining. d developers who write d code like java are small in numbers compared to those who don't. heck, i'll go even further and wish pure was also default.
Dec 27 2017
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 14:06 +0000, Dan Partelly via Digitalmars-d
wrote:
=20
[=E2=80=A6]
 By comparison, D is young, and had the advantage it had no=20
=20
[=E2=80=A6] In the grand scheme of programming languages, D is old-ish. Bit this is not a problem per se. -- Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 27 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/27/2017 12:59 AM, Dan Partelly wrote:
 All could have been prevented by going the C++ route of 0 cost abstraction,
C++ is not 0 cost abstraction, despite the marketing. It's why C++ compilers have switches to disable things like EH and RTTI.
Dec 27 2017
parent reply ChangLong <changlon gmail.com> writes:
On Wednesday, 27 December 2017 at 10:08:37 UTC, Walter Bright 
wrote:
 On 12/27/2017 12:59 AM, Dan Partelly wrote:
 All could have been prevented by going the C++ route of 0 cost 
 abstraction,
C++ is not 0 cost abstraction, despite the marketing. It's why C++ compilers have switches to disable things like EH and RTTI.
Hi Walter, Can you take a look at this betterC bug: https://issues.dlang.org/show_bug.cgi?id=18099 ========== struct D() { struct V { ~this() { } } auto get() { V v ; return v ; } } alias T = D!(); ============ Error: Cannot use throw statements with -betterC a.d(12): Error: template instance a.D!() error instantiating It is a block for implement auto RefCount in betterC. Since there is no GC, auto RefCount is the way to make D work far more useable then pure C, and it relay on this bug to be fixed.
Dec 27 2017
next sibling parent ChangLong <changlon gmail.com> writes:
On Thursday, 28 December 2017 at 03:31:19 UTC, ChangLong wrote:
 On Wednesday, 27 December 2017 at 10:08:37 UTC, Walter Bright 
 wrote:
 On 12/27/2017 12:59 AM, Dan Partelly wrote:
 All could have been prevented by going the C++ route of 0 
 cost abstraction,
C++ is not 0 cost abstraction, despite the marketing. It's why C++ compilers have switches to disable things like EH and RTTI.
Hi Walter, Can you take a look at this betterC bug: https://issues.dlang.org/show_bug.cgi?id=18099 ========== struct D() { struct V { ~this() { } } auto get() { V v ; return v ; } } alias T = D!(); ============ Error: Cannot use throw statements with -betterC a.d(12): Error: template instance a.D!() error instantiating It is a block for implement auto RefCount in betterC. Since there is no GC, auto RefCount is the way to make D work far more useable then pure C, and it relay on this bug to be fixed.
With BetterC and Auto RefCount, Simple template can simulation Rust Box, Arc behavior. I has try made a BetterC lib to work with libuv, Fiber(implement by struct), Thread local storage(use libuv api with Thread in struct). There is noGc and Boxed data auto release by auto RefCount. BetterC made D generate extreme fast and small binary execute code. And the powerful template can easy simulation Rust Box and Go Channel. If I add a D version to made the code at single thread mode, the speed is even more fast since the Channel lock and Tls is removed without change code. With D version Box template, Boxed struct resource are allocate in a pool, and auto release into pool after the refCount to zero. It make the code look like normal D Code without betterC, and get the noGC benefit. The defect is I can not use Class and Exception, It has be done with a custom object.d.
Dec 27 2017
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 28 December 2017 at 03:31:19 UTC, ChangLong wrote:
 Hi Walter, Can you take a look at this betterC bug:  
 https://issues.dlang.org/show_bug.cgi?id=18099

 ==========
         struct D()
         {
                 struct V {
                         ~this() {
                         }
                 }
                 auto get() {
                         V v ;
                         return v ;
                 }
         }
         alias T = D!();
 ============
 Error: Cannot use throw statements with -betterC
 a.d(12): Error: template instance a.D!() error instantiating


 It is a block for implement auto RefCount in betterC.  Since 
 there is no GC,  auto RefCount is the way to make D work far 
 more useable then pure C, and it relay on this bug to be fixed.
I can hear him already, "Post it on buzzkill or it won't get fixed!"
Dec 30 2017
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 30 December 2017 at 23:04:21 UTC, Nicholas Wilson 
wrote:
 I can hear him already, "Post it on buzzkill or it won't get 
 fixed!"
Stupid autocorrect. Bugzilla.
Dec 30 2017
prev sibling next sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Sat, 30 Dec 2017 23:04:21 +0000, Nicholas Wilson wrote:

 I can hear him already, "Post it on buzzkill or it won't get fixed!"
He does have a point. At work, people often email me directly, or stop me in the hallway, to report things that belong on the issue tracker. I consistently tell people that if I don't fix something the same day, it likely isn't going to happen unless it's on the issue tracker, yet again and again they'll tell me of a problem in person, quite often when I've left my organizer in my office. There is an official method of dealing with bugs, so that needs to be the system used, and consistently used. If the current system is insufficient, it should be improved or replaced, but you can't run reports from IRC or the NG.
Dec 30 2017
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2017 3:47 PM, rjframe wrote:
 He does have a point. At work, people often email me directly, or stop me
 in the hallway, to report things that belong on the issue tracker. I
 consistently tell people that if I don't fix something the same day, it
 likely isn't going to happen unless it's on the issue tracker, yet again
 and again they'll tell me of a problem in person, quite often when I've
 left my organizer in my office.
 
 There is an official method of dealing with bugs, so that needs to be the
 system used, and consistently used. If the current system is insufficient,
 it should be improved or replaced, but you can't run reports from IRC or
 the NG.
You're exactly right. Before Brad Roberts set up bugzilla, the bug reporting system was an email folder on my system. Such a thing does not scale, was completely disorganized and erratic, was not accessible by anyone but me, etc. Having a centralized, organized, professional bug reporting system is the *only* practical way of managing bug reports, discussions about them, status, statistics, and resolutions. Verbal reports, emails, forum postings, chat logs, reddit, etc., is completely impractical as a bug reporting system once a project exceeds a certain size, and D exceeded that threshold a long, long time ago. While filing a bugzilla issue does not guarantee action, not filing an issue pretty much guarantees no action.
Dec 30 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2017 3:04 PM, Nicholas Wilson wrote:
 I can hear him already, "Post it on buzzkill or it won't get fixed!"
It's already on bugzilla, and was already fixed.
Dec 30 2017
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 08:59 +0000, Dan Partelly via Digitalmars-d
wrote:
=20
[=E2=80=A6]
 I could not agree more with this. It is unfortunate D has=20
 dependencies on a garbage collector in language proper and in std.
Given the current situation, D's best route to traction is to embrace GC and ignore all complaints other than "give us a better GC". (*) It is all about differentiation. Forget competing against C, C++, and Rust. D is the C++ inspired language with GC that isn't Go. =20
 [=E2=80=A6]
(*) "Better C" is a specialist use case for Walter and the D backend. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 27 2017
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:

 Given the current situation, D's best route to traction is to 
 embrace GC and ignore all complaints other than "give us a 
 better GC". (*)
I disagree strongly with this. Otherwise D won't have nogc attributes, and functions like emplace for instance. GC is best to view as useful tool in certain situations that require it while other situations require manual memory management. There no reason why D can't have the best of both worlds.
 It is all about differentiation. Forget competing against C, 
 C++, and
 Rust. D is the   C++ inspired language with GC that isn't Go.
Competing in terms of what exactly?
Dec 27 2017
parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 17:46 +0000, 12345swordy via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Competing in terms of what exactly?
not simply a side show of history. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 27 2017
prev sibling next sibling parent reply Dan Partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:
 It is all about differentiation. Forget competing against C, 
 C++, and
 Rust. D is the   C++ inspired language with GC that isn't Go.
So what I hear is: if D wants a future embrace one personality only. Given current state of affairs, it should compete against like better C and competing against zero cost abstraction languages. For this to happen D must focus all its energy on implementation of a second to none GC. This of course , has both sense and sensibility, but given that D has been unable to commit to one personality in it's life-spawn, how likely is to happen ? Walter, what says you ? Where do you actually want to go with D ? What you and D foundation wants, not Russel or I or whatever else ?
Dec 27 2017
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 December 2017 at 18:23:37 UTC, Dan Partelly 
wrote:
 On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
 wrote:
 It is all about differentiation. Forget competing against C, 
 C++, and
 Rust. D is the   C++ inspired language with GC that isn't Go.
So what I hear is: if D wants a future embrace one personality only. Given current state of affairs, it should compete against like better C and competing against zero cost abstraction languages. For this to happen D must focus all its energy on implementation of a second to none GC. This of course , has both sense and sensibility, but given that D has been unable to commit to one personality in it's life-spawn, how likely is to happen ? Walter, what says you ? Where do you actually want to go with D ? What you and D foundation wants, not Russel or I or whatever else ?
'Competition is for losers', according to Peter Thiel. It's completely the wrong mindset to succeed in a free society. What you're supposed to do is create a monopoly that you earn and keep earning every day. Economic quasi-rent, or pure profit, is the reward for noticing ways to better organise resources to serve customers needs in a way that others have overlooked. (See the work of Israel Kirzner and Schumpeter). D shouldn't compete against anything any more than it has tried to compete in the past. The way to success is to listen to people who like what you are doing anyway and would like you to develop along the path of development that already exists and maybe are willing to encourage that in some way. [Of course stealing useful ideas that fit what you are doing is always good, patent and IP law permitting]. If you do that, it becomes a ridiculous question to ask 'how are you differentiated from other languages; what is your edge?' because it's obvious to anyone with eyes and the willingness to study a bit what that is. In my view, this is also good career advice I have taken myself and that I have found personally to be profitable, as well as the right way for a language to develop. And it's what Walter has done anyway based on his long experience in flourishing as a one-man band in a market where Microsoft - with its very large resources - was then the dominant player. People also continue to think and write as if the D Foundation has this inexhaustible fund of resources (pecuniary and people) that it can command to work on whatever Andrei and Walter think best. It's open source! It doesn't work like that. If you want people to work on something, write a proof of concept and talk about it. Talking to the aether about what people ought to be doing will be less effective than finding one guy who agrees with you and working on the project together. And if not working on it yourself, then organising a fund and making an initial contribution towards a prize for someone who will. And if one isn't willing either to work on something oneself, or to contribute financially towards its development, just how likely is it you will persuade somebody else to do the work in a community of highly intelligent, spirited, and independent-minded people?
Dec 27 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 19:11:14 UTC, Laeeth Isharc 
wrote:
'Competition is for losers', according to Peter Thiel.  It's 
completely the wrong mindset >to succeed in a free society.  
What you're supposed to do is create a monopoly that you >earn 
and keep earning every day.  Economic quasi-rent, or pure profit,
I dont really know who Peter Thiel guys is but economic quasi-rent assumes that you already have something of value, which feels a real void. For example Gabe Newell and his Steam store. In each one of us there is lazy rentier, it is only natural to cash in without doing any real effort(altough today;s rentiers are not like the nobles of the past, they do work 12h / day , but yeah .. ). But this destroys innovation, and in the long run is of little value to society since it doesn't produce more advances.
D shouldn't compete against anything any more than it has tried 
to compete in the past.  >The way to success is to listen to 
people who like what you are doing anyway and would >like you to 
develop along
D doesnt exist in a void where it can form a natural monopoly.Also, in this world things do not sell themselves, no matter how good they are. Try what you suggest, no marketing, just excellent decisions and D will kill itself. On Wednesday, 27 December 2017 at 19:11:14 UTC, Laeeth Isharc wrote:
 
 It's open source!  It doesn't work like that.

 If you want people to work on something, write a proof of 
 concept and talk about it.  T......  do the work in a community 
 of highly intelligent, spirited, and independent-minded people?
Don't put the carriage before the horses. I understand enthusiasm but this is too much. You cannot in good faith ask anyone which is interested in your cause to contribute his time in development or organize fund raising. Im not here to save the world , the baby seals , or D (if it needs saving), or whatever other crusade. Im here because Im curious about D, curious enough to want to know future direction and what the bright people around here think on it. I ask nobody yet to implement anything, neither do I try to shift its development in any way. I gather cursory information and for the rest ... I simply don't care.. yet. That is all. Dont try to see more.
Dec 27 2017
parent reply codephantom <me noyb.com> writes:
On Wednesday, 27 December 2017 at 19:42:50 UTC, Dan Partelly 
wrote:
 Im not here to save the world , the baby seals , or D (if it 
 needs saving), or whatever other crusade. Im here because Im 
 curious about D, curious enough to want to know future 
 direction and what the bright people around here think on it. I 
 ask nobody yet to implement anything, neither do I try to shift 
 its development in any way. I gather cursory information and 
 for the rest ... I simply don't care.. yet.

 That is all. Dont try to see more.
Well, you're doing what most people do, when they hear about a new programming language - i.e. start comparing it to others.... there is a psychological basis for that phenomena - it's human. But honestly, the best way to learn about a programming language, is to start using it. So I ask you...what have you written in D lately?
Dec 27 2017
next sibling parent reply Dan Partelly <i i.com> writes:
On Thursday, 28 December 2017 at 01:09:34 UTC, codephantom wrote:
 But honestly, the best way to learn about a programming 
 language, is to start using it.
Sure , **if** you decide it worth to be learned. And honestly, almost everybody knows that to get better at a task you must perform the task itself.
 So I ask you...what have you written in D lately?
Small snippets. I believe is the best way to start with a new language. Then you decide if you like it, and if it serves any purpose for you. Adopting a new language for anything serious is a big commitment. My problem currently is that I have no freaking idea what niche D serves, since as I said I perceive multiple personalities in it. I like a lot in the language, but I do not like that I perceive it as a indecisive language. This is one of the reasons I asked Walter in this thread what is the future of the language ? Where does it to go ? No clear answer yet.
Dec 27 2017
next sibling parent codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 02:21:09 UTC, Dan Partelly wrote:
 Small snippets. I believe is the best way to start with a new 
 language. Then you decide if you like it, and if it serves any 
 purpose for you. Adopting a new language for anything serious 
 is a big commitment.
This is what I do to. Only discovered D a few months ago..have 300+ snippets and growing... It's the best way to learn about various features ...
 My problem currently is that I have no freaking idea what niche 
 D serves, since as I said I perceive multiple personalities in 
 it. I like a lot in the language, but I do not like that I 
 perceive it as a indecisive language.
I see it as an alternative to C++ - i.e a powerful and flexible compiled language that I can actually understand, and enjoy using.
 This is one of the reasons I asked Walter in this thread what 
 is the future of the language ?
 Where does it to go ? No clear answer yet.
That really depends on what people (not just Walter) do with it, and want to do with it. This varies alot, and will continue to vary alot, as we don't all think the same way, or want to solve the same problems. Clearly though, D is targetted as a better C, an increasingly better C++, as well as better general use, multiparadigm, powerful, flexible, fast, compiled langauge..that is understandable and pleasant to work with. It that's not enough to get people interested in it, then what is?
Dec 27 2017
prev sibling parent Laeeth Isharc <laeeth nospamlaeeth.com> writes:
On Thursday, 28 December 2017 at 02:21:09 UTC, Dan Partelly wrote:
 On Thursday, 28 December 2017 at 01:09:34 UTC, codephantom 
 wrote:
 But honestly, the best way to learn about a programming 
 language, is to start using it.
Sure , **if** you decide it worth to be learned. And honestly, almost everybody knows that to get better at a task you must perform the task itself.
 So I ask you...what have you written in D lately?
My problem currently is that I have no freaking idea what niche D serves, since as I said I perceive multiple personalities in it. I like a lot in the language, but I do not like that I perceive it as a indecisive language. This is one of the reasons I asked Walter in this thread what is the future of the language ? Where does it to go ? No clear answer yet.
It's a practical language for getting stuff done in a way thats plastic, efficient, powerful. So I think the ecological niche is restricted mostly by capabilities of the people using it (it wasn't designed as golang was as a restricted and simple language for people who have limited experience, though I personally found it easy enough to learn), by the tolerance people have for discomfort upfront, by the ability to pay upfront costs in wrapping any necessary libraries, by the ability to pick your own tools rather than needing to persuade others first. It's not as polished as more mature languages. It has fewer targets, so for example it doesn't yet have a production ready ARM 64 or web assembly target, and if you run it on Alpine Linux, FreeBSD or SmartOS it will probably work but you might have some work to do yourself. Embedded targets will need you to do work. If it's super important not to use the GC probably you will have some work to do. If you work with younger people who expect Python style docs and an abundance of Stack Overflow answers you may have some work to do there. Beyond that, it's pretty good for many things,from scripting to applications to numerical code, to systems programming. That's really the point. It's also especially good as glue because of ctfe and compile time reflection. Pegged and other parser generators mean that it's a pretty nice language for writing DSLs in.
Dec 27 2017
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2017-12-28 at 01:09 +0000, codephantom via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Well, you're doing what most people do, when they hear about a=20
 new programming language - i.e. start comparing it to others....=20
 there is a psychological basis for that phenomena - it's human.
[=E2=80=A6] And is the way every programmer learns their non-first language. All newly learned programming languages are merged into a person's "head language" which is based on their first language but then evolves as new languages, especially of new computational mode, are learned. See Marian Petre and others work over the last 30 years for scientific evidence of this. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 28 2017
next sibling parent Dan Partelly <i i.com> writes:
On Thursday, 28 December 2017 at 11:56:24 UTC, Russel Winder 
wrote:
 And is the way every programmer learns their non-first 
 language. All newly learned programming languages are merged 
 into a person's "head language" which is based on their first 
 language but then evolves as new languages, especially of new 
 computational mode, are learned.
One of the reasons I asked Walter to provide an insight into what he wants D to become, why betterC, GC or lack-thereof dilemma , and future evolution is to minimize a bit the biases I have. What I learned the most in the last days is what other people than the creator of D think of D (valuable too), and that is hard to get a straight answer from the people developing D language on my predicament with seeing it with multiple personalities. Also, no matter hope great D is, I practically live in a D-less void. No one cares about it around me and no one I know cares to learn it. This is another social aspect. As I learn it and learn how the creator sees the language I could try to change this in my immediate surrounding if it worth. It would be up to me once I am convinced to seduce people I work with to consider it and learning it.
Dec 28 2017
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 28 December 2017 at 11:56:24 UTC, Russel Winder 
wrote:
 And is the way every programmer learns their non-first 
 language. All newly learned programming languages are merged 
 into a person's "head language" which is based on their first 
 language but then evolves as new languages, especially of new 
 computational mode, are learned.

 See Marian Petre and others work over the last 30 years for 
 scientific evidence of this.
Hm… I have some problem with this. I can see how it would apply to Algol-like languages, but for I don't see how it fits on very different concepts like SQL/datalog/prolog, scheme, machine language, OO etc… There might be some empirical issues here as _most_ programmers would move to something similar, but statistical significance doesn't imply causality…
Dec 30 2017
parent reply Russel Winder <russel winder.org.uk> writes:
On Sat, 2017-12-30 at 17:53 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:
 On Thursday, 28 December 2017 at 11:56:24 UTC, Russel Winder=20
 wrote:
 And is the way every programmer learns their non-first=20
 language. All newly learned programming languages are merged=20
 into a person's "head language" which is based on their first=20
 language but then evolves as new languages, especially of new=20
 computational mode, are learned.
=20
 See Marian Petre and others work over the last 30 years for=20
 scientific evidence of this.
=20 Hm=E2=80=A6 I have some problem with this. I can see how it would apply=
=20
 to Algol-like languages, but for I don't see how it fits on very=20
 different concepts like SQL/datalog/prolog, scheme, machine=20
 language, OO etc=E2=80=A6
The core differentiator is the number of computational models, not programming language, that can be worked with with competence. So C++/Lisp/Prolog represents a better triad than C/C++/D. If you have doubts read the papers, the science is good, the hypotheses are confirmed.
 There might be some empirical issues here as _most_ programmers=20
 would move to something similar, but statistical significance=20
 doesn't imply causality=E2=80=A6
The results are based on experimental data. Read the papers rather than my waffle about them. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Dec 31 2017
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 31 December 2017 at 14:51:24 UTC, Russel Winder wrote:
 The results are based on experimental data. Read the papers 
 rather than my waffle about them.
I'd love to, but I haven't found the specific paper. She seems to work on many different things related to software design and visual tooling.
Dec 31 2017
parent Russel Winder <russel winder.org.uk> writes:
On Sun, 2017-12-31 at 17:32 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-
d wrote:
=20
[=E2=80=A6]
 I'd love to, but I haven't found the specific paper. She seems to=20
 work on many different things related to software design and=20
 visual tooling.
I'll email her and get the best start point citation for you. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jan 01 2018
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2017-12-27 at 19:11 +0000, Laeeth Isharc via Digitalmars-d
wrote:
[=E2=80=A6]
 People also continue to think and write as if the D Foundation=20
 has this inexhaustible fund of resources (pecuniary and people)=20
 that it can command to work on whatever Andrei and Walter think=20
 best.
But on the other hand there is little or no presence of The D Foundation in online places I frequent. The D Foundation does need to have a plan for becoming a thing that people would put resource into.
 It's open source!  It doesn't work like that.
=20
 If you want people to work on something, write a proof of concept=20
 and talk about it.  Talking to the aether about what people ought=20
 to be doing will be less effective than finding one guy who=20
 agrees with you and working on the project together.  And if not=20
 working on it yourself, then organising a fund and making an=20
 initial contribution towards a prize for someone who will.
=20
 And if one isn't willing either to work on something oneself, or=20
 to contribute financially towards its development, just how=20
 likely is it you will persuade somebody else to do the work in a=20
 community of highly intelligent, spirited, and independent-minded=20
 people?
This bears repeating, so I have done by resending. The ASF has the idea of a project being a "do-ocracy" Those that do have rights of credit and opinion. It a bit more complicated than that since it doesn't stop people from having opinions as long as they are constructive rather than rhetorical. However, it is a nice headline. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jan 29 2018
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 29 January 2018 at 10:34:35 UTC, Russel Winder wrote:
 On Wed, 2017-12-27 at 19:11 +0000, Laeeth Isharc via 
 Digitalmars-d
 wrote:
 […]
 People also continue to think and write as if the D Foundation 
 has this inexhaustible fund of resources (pecuniary and 
 people) that it can command to work on whatever Andrei and 
 Walter think best.
But on the other hand there is little or no presence of The D Foundation in online places I frequent. The D Foundation does need to have a plan for becoming a thing that people would put resource into.
For example, any news on the new CTFE? /Paolo
Jan 29 2018
prev sibling next sibling parent reply Dan Partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:

 (*) "Better C" is a specialist use case for Walter and the D 
 backend.
Also, if betterC is a specialist use case for Walter only, why does Walter call it "a game changer for D" ?
Dec 27 2017
parent reply codephantom <me noyb.com> writes:
On Wednesday, 27 December 2017 at 18:32:43 UTC, Dan Partelly 
wrote:
 On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
 wrote:

 (*) "Better C" is a specialist use case for Walter and the D 
 backend.
Also, if betterC is a specialist use case for Walter only, why does Walter call it "a game changer for D" ?
I am pretty sure Walter put a question mark after the wording, which makes it a question, not a statement ;-) -betterC (or as I prefer to call it, -slimD, since I also use C, which is the better C) is needed in D, because otherwise it would exclude a whole class of programmers, and problems that could not be solved. Its' not being forced on anyone. It's there to use if is suits your needs, or peaks your interest. Is it a game changer? That remains an open question. But D certainly needs it, for those that want/need to use it (which is not just Walter). But if you want to write 'System D', aka Dos (D operating system), then you will certainly need -slimD (aka -betterC) .. with all its enhancements to come.
Dec 27 2017
parent reply Dan Partelly <i i.com> writes:
On Thursday, 28 December 2017 at 01:21:42 UTC, codephantom wrote:

 I am pretty sure Walter put a question mark after the wording, 
 which makes it a question, not a statement ;-)
This is marketing. Many times in marketing questions are used to try to pass a certain perspective as a fact to the target population. You guys here are all pretty smart, so prolly you all seen it ;-)
Dec 27 2017
parent codephantom <me noyb.com> writes:
On Thursday, 28 December 2017 at 02:28:20 UTC, Dan Partelly wrote:
 This is marketing. Many times in marketing questions are used 
 to try to pass a certain perspective as a fact to the target 
 population. You guys here are all pretty smart, so prolly you 
 all seen it ;-)
Yeah, true.. but Walter likes a debate too ;-) So I agree, it was part marketing... but it was more .. what do you all think?
Dec 27 2017
prev sibling parent reply John Gabriele <jgabriele fastmail.fm> writes:
On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:
 On Wed, 2017-12-27 at 08:59 +0000, Dan Partelly via 
 Digitalmars-d wrote:
 
[…]
 I could not agree more with this. It is unfortunate D has 
 dependencies on a garbage collector in language proper and in 
 std.
Given the current situation, D's best route to traction is to embrace GC and ignore all complaints other than "give us a better GC". (*) It is all about differentiation. Forget competing against C, C++, and Rust. D is the C++ inspired language with GC that isn't Go.
 […]
(*) "Better C" is a specialist use case for Walter and the D backend.
Although I don't know D very well yet, it sounds like Russel hits the nail precisely on the head here. FWICT, folks have lately used scripting languages (ex. Python, Perl, Ruby) for larger and larger programs (and even JS+Node for local apps), but it seems to me like the pendulum is swinging back the other way as everyone wants optional types and also JIT implementations like [PyPy](http://pypy.org/). I think the D wiki would benefit from an article on how D competes-with/differs-from Go. Also, as a related aside, another language that D competes with is Vala. Now that D is part of GCC, I wonder if D could replace Vala.
Dec 27 2017
parent reply Dan Partelly <i i.com> writes:
On Wednesday, 27 December 2017 at 19:13:15 UTC, John Gabriele 
wrote:
 Although I don't know D very well yet, it sounds like Russel 
 hits the nail precisely on the head here. FWICT, folks have 
 lately used scripting languages (ex. Python, Perl, Ruby) for 
 larger and larger programs (and even JS+Node for local apps),
Resulting in terrible software. Take text editors written in JS+Electron. Slow bloated crap.Noticeable slow on a 2 core i5 MacBook Pro with 8Gb RAM. Press key , notice delay, see char on sceen. Really ???? I mean, REALLY ? I had a 8086 which could edit text with no issue. Had a C64 with 64kb or RAM too which was up to the task of editing text. Look at how slow Visual Studio became in time as more and more of it was written in managed languages and non-native code. Android is pitifully slow , and not because of Linux. Democratization of programming through JS/ PhP / Perl and other scripts was great for society because it empowered a lot of humans. But also created means to write bloated, inefficient, terribly slow software. Nuclear weapons used where a surgeon's tool is mandated.
Dec 27 2017
parent John Gabriele <jgabriele fastmail.fm> writes:
On Wednesday, 27 December 2017 at 20:53:46 UTC, Dan Partelly 
wrote:
 On Wednesday, 27 December 2017 at 19:13:15 UTC, John Gabriele 
 wrote:
 Although I don't know D very well yet, it sounds like Russel 
 hits the nail precisely on the head here. FWICT, folks have 
 lately used scripting languages (ex. Python, Perl, Ruby) for 
 larger and larger programs (and even JS+Node for local apps),
Resulting in terrible software. Take text editors written in JS+Electron. Slow bloated crap. {snip}
Maybe I wasn't being very clear there. Also, my unedited comment on that was:
 Although I don't know D very well yet, it sounds like Russel 
 hits the nail precisely on the head here. FWICT, folks have 
 lately used scripting languages (ex. Python, Perl, Ruby) for 
 larger and larger programs (and even JS+Node for local apps), 
 but it seems to me like the pendulum is swinging back the other 
 way as everyone wants optional types and also JIT 
 implementations like [PyPy](http://pypy.org/).
with my point being that I think we're seeing many scripting language users now wanting the features that D already has (types, type inference, high performance and less resource usage (natively compiled)). I think it's a good time for D to attract those users.
Dec 27 2017