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