Re: What are the worst parts of D?

2014-10-13 Thread ketmar via Digitalmars-d
On Tue, 14 Oct 2014 00:09:17 +0300
ketmar via Digitalmars-d  wrote:

let's stop hijacking this thread. here is The Official Thread for
cmdcon-ng:
http://forum.dlang.org/thread/mailman.772.1413240502.9932.digitalmar...@puremagic.com


signature.asc
Description: PGP signature


Re: What are the worst parts of D?

2014-10-13 Thread ketmar via Digitalmars-d
as i see that some peopele are eager to play with cmdcon-ng, i setup a
git repo with it: http://repo.or.cz/w/cong.d.git

lay your hands while it hot!

the code is little messy (there are some napoleonian plans which aren't
made into it), but it should work. at least with unittests and sample.

enjoy, and happy hacking!


signature.asc
Description: PGP signature


Re: What are the worst parts of D?

2014-10-13 Thread via Digitalmars-d
On Monday, 13 October 2014 at 21:09:29 UTC, ketmar via 
Digitalmars-d wrote:
as i can't publish my current version of cmdcon, i decided to 
write another one from scratch.


Cool, looks like a fun module to play with! :-)


Re: What are the worst parts of D?

2014-10-13 Thread Martin Drašar via Digitalmars-d
Dne 13.10.2014 v 23:09 ketmar via Digitalmars-d napsal(a):
> as i can't publish my current version of cmdcon, i decided to write
> another one from scratch. it contains alot less of mixin() codegens,
> can do everything cmdcon.d can do and has structs/classes already
> working. this is the excerpt from testing code:

Nice! That's what I call a can-do attitude :) I just happen to have a
nice place in code where it can get used. I'm looking forward for
playing with it.

Martin



smime.p7s
Description: Elektronicky podpis S/MIME


Re: What are the worst parts of D?

2014-10-13 Thread ketmar via Digitalmars-d
On Mon, 06 Oct 2014 13:34:23 +0200
Martin Drašar via Digitalmars-d  wrote:

> Ok, thanks for your answers. If you get your code to publishable
> state, I am sure a lot of people will be interested.
as i can't publish my current version of cmdcon, i decided to write
another one from scratch. it contains alot less of mixin() codegens,
can do everything cmdcon.d can do and has structs/classes already
working. this is the excerpt from testing code:


import cong; // our console module

@ConName("intVar00")
@ConHelp("simple int variable")
@ConDescription("this is just an int variable.\nordinary one, nothing
special.")
__gshared int v0 = 42;

__gshared string v1 = "hi!";

class A {
  int i = 42;
  string s = "hello";
  this () {}
  this (string v) { s = v; }
  int bar () { writeln("BAR: s=", s); return 666; }
  void foo (float[] ff) {}
}

__gshared A a; // yes, this can be null

void foo (int n, string s="hi", double d=0.666) {
  writefln("n=%s; s=[%s]; d=%s", n, s, d);
}

struct S {
  int i = 666;
  string s = "bye";
  int sbar () { writeln("SBAR: s=", s); return 666; }
  void sfoo (float[] ff) {}
}

__gshared S s;
S s1;


void main (string[] args) {
  writeln("known commands:");
  foreach (auto n; conGetKnownNames()) writeln("  ", n);
  writeln("---");

  a = new A();
  conExecute("a bar"); // virtual method call for object instance
  a.s = "first change";
  conExecute("a bar");
  a = new A("second change");
  conExecute("a bar");  // virtual method call for ANOTHER object
  instance

  foreach (auto arg; args[1..$]) {
try {
  writeln("# ", arg);
  conExecute(arg);
} catch (Exception e) {
  writeln("***ERROR: ", e.msg);
}
  }
}

mixin(ConRegisterAll); // register 'em all!

==

known commands:
  intVar00
  a
  foo
  v1
  s
---
(autoregistration rocks!)

some sample commands and results:

# intVar00
intVar00 42 (Int)
# foo 42
n=42; s=[hi]; d=0.666
# a i
a.i 42 (Int)
# a bar
BAR: s=second change
# s sbar
SBAR: s=bye


by default `mixin(ConRegisterAll);` tries to register all suitable
public symbols. one can use @ConIgnore UDA to ignore symbol and some
other UDAs to change name, add help and so on. alas, there is no way to
get Ddoc info in compile-time (what a pity!).

you can't register pointer objects (i.e. `__gshared int *a` will not
pass). it's doable (class fields are such objects internally), but i
just don't need this.

i also found some bugs in compilers (both dmd and gdc), but aren't
ready to dustmite and report 'em yet. GDC just segfaults now, but DMD
works.

there is also bug in CDGC, which took me a whole day of useless code
motion (i forgot that i'm using DMD built with CDGC ;-).


so the base mechanics is in place, i need to debug some things and
write simple sample with eventloop and telnet.

new code includes only WTFPL'ed parts, so it probably will be WTFPLed
too.


hope to finish this until weekend.


signature.asc
Description: PGP signature


Re: What are the worst parts of D?

2014-10-11 Thread Dicebot via Digitalmars-d

On Saturday, 11 October 2014 at 09:26:28 UTC, Marc Schütz wrote:
I understand that. My argument is that the same should apply to 
the entire heap: After you've allocated and released a certain 
amount of objects via GC.malloc() and GC.free(), the heap will 
have grown to a size large enough that any subsequent 
allocations of temporary objects can be satisfied from the 
existing heap without triggering a collection, so that only the 
overhead of actual allocation and freeing should be relevant.


But it still requires GC to check its pool state upon each 
request and make relevant adjustments for malloc/free combo. For 
something like a hundred of temporary allocations per request it 
accumulates into notable time (and milliseconds matter). In 
absence of collection it is cheap enough to not care about single 
malloc call on its own but still not cheap enough to ignore costs 
of many calls.


You have interested me in doing some related benchmarks though.


Re: What are the worst parts of D?

2014-10-11 Thread yawniek via Digitalmars-d
Exactly. C++ support is of no interest at all, and GC is 
something we contribute to, rather than something we expect 
from the community.
Interestingly we don't even care much about libraries, we've 
done everything ourselves.


So what do we care about? Mainly, we care about improving the 
core product.


In general I think that in D we have always suffered from 
spreading ourselves too thin. We've always had a bunch of cool 
new features that don't actually work properly. Always, the 
focus shifts to something else, before the previous feature was 
finished.


At Sociomantic, we've been successful in our industry using 
only the features of D1. We're restricted to using D's features 
from 2007!! Feature-wise, practically nothing from the last 
seven years has helped us!


With something like C++ support, it's only going to win 
companies over when it is essentially complete. That means that 
working on it is a huge investment that doesn't start to pay 
for itself for a very long time. So although it's a great goal, 
with a huge potential payoff, I don't think that it should be 
consuming a whole lot of energy right now.


And personally, I doubt that many companies would use D, even 
if with perfect C++ interop, if the toolchain stayed at the 
current level.


As I said in my Dconf 2013 talk -- I advocate a focus on Return 
On Investment.

I'd love to see us chasing the easy wins.


disclaimer: i am rather new to D and thus have a bit of a distant 
view.


i think the above touches an important point. One thing GO does 
right is that they focused on feature rich stdlib/library 
ecosystem even though the language was very young. i'm coming 
from Ruby/Python and the reason i use those languages is that 
they have two things:
a) they are fun to use (as andrei said in the floss interview: 
the creators had "taste").

b) huge set of libs that help me to get stuff done.

now i think a) is fine, but with b) i am not sure if the strategy 
to get full C/C++ interop will not take too long and scare those 
people off that are not coming from C/C++.


i think D is a fantastic tool to write expressive, fast and 
readable code. I don't need much more language features (again, 
look at GO...) but a solid foundation of libs to gain 
"competitive advantage" in my daily work.




Re: What are the worst parts of D?

2014-10-11 Thread via Digitalmars-d

On Saturday, 11 October 2014 at 03:39:10 UTC, Dicebot wrote:
I am not speaking about O(1) internal heap increases but O(1) 
GC.malloc calls
Typical pattern is to encapsulate "temporary" buffer with the 
algorithm in a single class object and never release it, 
reusing with new incoming requests (wiping the buffer data each 
time). Such buffer quickly gets to the point where it is large 
enough to contain all algorithm temporaries for a single 
request and never touches GC from there.


In a well-written program which follows such pattern there are 
close to zero temporaries and GC only manages more persistent 
entities like cache elements.


I understand that. My argument is that the same should apply to 
the entire heap: After you've allocated and released a certain 
amount of objects via GC.malloc() and GC.free(), the heap will 
have grown to a size large enough that any subsequent allocations 
of temporary objects can be satisfied from the existing heap 
without triggering a collection, so that only the overhead of 
actual allocation and freeing should be relevant.


Re: What are the worst parts of D?

2014-10-11 Thread K.K. via Digitalmars-d

On Wednesday, 8 October 2014 at 19:00:44 UTC, Jonathan wrote:
3) Taking a hint from the early success of Flash, add Derelict3 
(or some basic OpenGL library) directly into Phobos. Despite 
some of the negatives (slower update cycle versus external 
lib), it would greatly add to D's attractiveness for new 
developers. I nearly left D after having a host issues putting 
Derelict3 into my project. If I had this issue, we may be 
missing out from attracting newbies looking to do gfx related 
work.



This reminds of an idea I've been pondering over for a while now.
What if there was a language, that came with a standard toolkit
for the more fun stuff such as OpenGL (There could be one already
and I just don't know of it). But if we take that idea and try to
apply it to D, we sortof get Deimos. Problem is Deimos, is pretty
disjointed and is only updated every now and then, so then as an
alternative I suppose there is Derelict. However, Derelict is
maintained primarily by one person it seems (he does a great job
though!), but Derelict isn't a standard feature (I know Deimos
isn't either) and I *personally* don't care much for it's heavy
leaning on dub. +Derelict isn't always a walk in the park to get
running

The alternative I'm suggesting, not by any means a top priority,
is give Deimos a makeover (Derelict could possibly be a big part
of this) and turn it into a semi-standard feature. So you can
import phobos modules to do the stuff phobos normally does, but
if you feel like making a quick tool or two, you can import
deimos to get Tcl/tk like you would in python, or call OpenGl, or
whatever other tool you need (doesn't have to be a graphics
thing). Then at compile time the compiler could just copy or
build the required dll's\so's & object files into the specified
directory, or whatever works best.

On Wednesday, 8 October 2014 at 19:47:05 UTC, Jeremy Powers via
Digitalmars-d wrote:


Personally I take the opposite view - I'd much prefer a strong 
and easily
consumed third-party library ecosystem than to shove everything 
into
Phobos.  Dub is a wonderful thing for D, and needs to be so 
good that

people use it by default.


Not to initiate my biweekly "not a fan of dub" conversation, but
just wanna say real quick: Not everyone really likes to use dub.
The only thing I like about it, is using it as the build script
for a library to get the .lib files and whatnot. Though I don't
feel like it really adds a drastic improvement over a .d build
script. However, I don't work on any open source libraries, but
maybe if I did, I'd like it better then..? Not something I would
have an answer to right now, soo... yea:P




Aside from what I mentioned above, I'm not sure where I'd like D
to be at next to be perfectly honest. Stuff like no GC or C++
integration sound cool, but for me personally they just seem like
'neat' feature, not something that I feel like would change my
current workflow for better or worse.
Refinement of what's already in place sounds the best if anything.


So those are just some passing thoughts of a stranger.. carry on,
this thread has been very interesting so far ;P


Re: What are the worst parts of D?

2014-10-10 Thread Dicebot via Digitalmars-d

On Friday, 10 October 2014 at 08:45:38 UTC, Marc Schütz wrote:
Yes and quite notably so as GC.malloc can potentially trigger 
collection. With concurrent GC collection is not a disaster 
but it still affects the latency and should be avoided.


Is it just the potentially triggered collection, or is the 
actual allocation+deallocation too expensive?


collection - for sure.
allocation+deallocation - maybe, I have never measured it. It is 
surely slower than not allocating at all though.


Because the effects of the former can of course be reduced 
greatly by tweaking the GC to not collect every time the heap 
needs to grow, at the cost of slightly more memory consumption.


This is likely to work better but still will be slower than our 
current approach because of tracking many small objects. Though 
of course it is just speculation until RC stuff is implemented 
for experiments.


Also let's note that extending existing chunks may result in 
new allocations.


Yes. But as those chunks never get free'd it comes to O(1) 
allocation count over process lifetime with most allocations 
happening during program startup / warmup.


Hmm... but shouldn't this just as well apply to the temporary 
allocations? After some warming up phase, the available space 
on the heap should be large enough that all further temporary 
allocations can be satisfied without growing the heap.


I am not speaking about O(1) internal heap increases but O(1) 
GC.malloc calls
Typical pattern is to encapsulate "temporary" buffer with the 
algorithm in a single class object and never release it, reusing 
with new incoming requests (wiping the buffer data each time). 
Such buffer quickly gets to the point where it is large enough to 
contain all algorithm temporaries for a single request and never 
touches GC from there.


In a well-written program which follows such pattern there are 
close to zero temporaries and GC only manages more persistent 
entities like cache elements.


Re: What are the worst parts of D?

2014-10-10 Thread bearophile via Digitalmars-d

Tofu Ninja:


What do you think are the worst parts of D?


There are several problems in D/Phobos, but I think the biggest 
one is the development process, that is currently toxic:

http://forum.dlang.org/thread/54374de0.6040...@digitalmars.com

In my opinion an Open Source language with such development 
problem goes nowhere, so I think this needs to be improved.


There are several possible ways to improve this situation, but 
perhaps the may one that can work is: Walter has to delegate 
another slice of its authority to the community of core dmd 
developers. This will cause some problems, perhaps an increase in 
confusion and pull reversions, Walter may lose a bit of his grasp 
of the dmd codebase (but this can be avoided if he reads the pull 
requests code), but I think overall the advantages in the long 
term are going to be bigger than the disadvantages.


Regarding the product (and not the process), the design of a 
principled, sound, and flexible memory ownership system is an 
important part of D design to work on in the following months. 
It's going to add some complexity to D, but this is not the kind 
of complexity that kills a language, because if it's well 
designed it's going to give easy to read compile-time errors, 
it's not going to limit too much the variety of things that are 
currently allowed in D, and it's going to statically remove a 
significant amount of run-time bugs that are currently easy to do 
in D. The complexity that causes problems is not the one that 
requires you to understand a part of a well designed type system: 
it's the pile of arbitrary special cases and special cases of 
special cases you see in C++. D considers safety and correctness 
very important points of its design, and I agree with the 
importance of such points.


Bye,
bearophile


Re: What are the worst parts of D?

2014-10-10 Thread eles via Digitalmars-d

On Friday, 10 October 2014 at 08:45:38 UTC, Marc Schütz wrote:

On Thursday, 9 October 2014 at 17:29:01 UTC, Dicebot wrote:
On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei 
Alexandrescu wrote:


I think the worst of D is summarized quite well by the following:

http://forum.dlang.org/post/m15i9c$51b$1...@digitalmars.com

http://forum.dlang.org/post/54374de0.6040...@digitalmars.com

And that is: the focus is no longer to do the right things about 
D, but to make D do the right thing for some shadowy customers 
that don't even care enough to come here and grumble.


Let's put D2 in maintenance mode and take on D3 with this nice 
motto, taken from here:


http://forum.dlang.org/post/3af85684-7728-4165-acf9-520a240f6...@me.com

"why didn't work like that from the beginning?"


Re: What are the worst parts of D?

2014-10-10 Thread via Digitalmars-d

On Thursday, 9 October 2014 at 17:29:01 UTC, Dicebot wrote:
On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei 
Alexandrescu wrote:

To clarify: calling GC.free does remove the root, correct?


Not before it creates one. When I mean "avoid creating new GC 
roots" I
mean "no GC activity at all other than extending existing 
chunks"


That's interesting. So GC.malloc followed by GC.free does 
actually affect things negatively?


Yes and quite notably so as GC.malloc can potentially trigger 
collection. With concurrent GC collection is not a disaster but 
it still affects the latency and should be avoided.


Is it just the potentially triggered collection, or is the actual 
allocation+deallocation too expensive?


Because the effects of the former can of course be reduced 
greatly by tweaking the GC to not collect every time the heap 
needs to grow, at the cost of slightly more memory consumption.


If it's the latter, that would indicate that maybe a different 
allocator with less overhead needs to be used.




Also let's note that extending existing chunks may result in 
new allocations.


Yes. But as those chunks never get free'd it comes to O(1) 
allocation count over process lifetime with most allocations 
happening during program startup / warmup.


Hmm... but shouldn't this just as well apply to the temporary 
allocations? After some warming up phase, the available space on 
the heap should be large enough that all further temporary 
allocations can be satisfied without growing the heap.


Re: What are the worst parts of D?

2014-10-09 Thread Jacob Carlborg via Digitalmars-d

On 09/10/14 18:41, Andrei Alexandrescu wrote:


With structured outputs there are a lot more issues to address: one can
think of a JSONObject as an output range with put() but that's only
moving the real issues around. How would the JSONObject allocate memory
internally, give it out to its own users, and dispose of it timely, all
in good safety?


The XML DOM module in Tango uses, if I recall correctly, a free list 
internally for the nodes. It will reuse the nodes, if you want to keep 
some information you need to copy it yourself.


--
/Jacob Carlborg


Re: What are the worst parts of D?

2014-10-09 Thread Walter Bright via Digitalmars-d

On 10/9/2014 7:15 AM, Dicebot wrote:

That can possibly be done though it will take some efforts to formalize issues
from the casual chat rants. More important issue is - what will happen next? I
am pretty sure many of those easy wins are not easy at all in a sense that
breaking changes are needed.


That's why I'd like to know what Don has in mind.


Re: What are the worst parts of D?

2014-10-09 Thread Nick Sabalausky via Digitalmars-d

On 09/25/2014 02:49 PM, H. S. Teoh via Digitalmars-d wrote:


Make-heads find the idea of the compiler being part of the input to a
build rule "strange"; to me, it's common sense.


Yes. This is exactly why (unless it's been reverted or regressed? I only 
mention that because I haven't looked lately) RDMD counts the compiler 
itself as a dependency. Because:


$ dvm use 2.065.0
$ rdmd stuff.d
[compiles]
$ dvm use 2.066.0
$ rdmd stuff.d
[silently *doesn't* recompile?!? Why is *that* useful?]

Is *not* remotely useful behavior, basically makes no sense at all, 
*and* gives the programmer bad information. ("Oh, it compiles fine on 
this new version? Great! I'm done here! Wait, why are other people 
reporting compile errors on the new compiler? It worked for me.")




Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d
On Thursday, 9 October 2014 at 16:41:22 UTC, Andrei Alexandrescu 
wrote:
Usage of output range is simply a generalization of out array 
parameter
used in both Tango and our code. It is _already_ proved to 
work for our

cases.


Got it. Output ranges work great with unstructured/linear 
outputs - preallocate an array, fill it with stuff, all's nice 
save for the occasional reallocation when things don't fit etc.


With structured outputs there are a lot more issues to address: 
one can think of a JSONObject as an output range with put() but 
that's only moving the real issues around. How would the 
JSONObject allocate memory internally, give it out to its own 
users, and dispose of it timely, all in good safety?


That's why JSON tokenization is relatively easy to do 
lazily/with output ranges, but full-blown parsing becomes a 
different proposition.


This reminds me of our custom binary serialization utilities, 
intentionally designed in a way that deserialization can happen 
in-place using same contiguous data buffer as serialized chunk. 
It essentially stores all indirections in the same buffer one 
after other.


Implementation is far from being trivial and adds certain usage 
restrictions but it allows for the same extremely performant 
linear buffer approach even with non-linear data structures.


In general I am not trying to argue that range-based approach is 
a silver bullet though. It isn't and stuff like ref counting will 
be necessary at least in some domains.


What I am arguing is that it won't solve _our_ issues with Phobos 
(contrary to previous range-based proposal) and this is the 
reason for being dissapointed. Twice as so because you suggested 
to close PR that turns setExtension into range because of your 
new proposal (which implies that efforts can't co-exist)


Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d
On Thursday, 9 October 2014 at 16:22:52 UTC, Andrei Alexandrescu 
wrote:

To clarify: calling GC.free does remove the root, correct?


Not before it creates one. When I mean "avoid creating new GC 
roots" I
mean "no GC activity at all other than extending existing 
chunks"


That's interesting. So GC.malloc followed by GC.free does 
actually affect things negatively?


Yes and quite notably so as GC.malloc can potentially trigger 
collection. With concurrent GC collection is not a disaster but 
it still affects the latency and should be avoided.


Also let's note that extending existing chunks may result in 
new allocations.


Yes. But as those chunks never get free'd it comes to O(1) 
allocation count over process lifetime with most allocations 
happening during program startup / warmup.


Don has mentioned this as one of important points during his 
DConf 2014 talk but it probably didn't catch as much attention as 
it should.


Re: What are the worst parts of D?

2014-10-09 Thread Andrei Alexandrescu via Digitalmars-d

On 10/9/14, 9:27 AM, Johannes Pfau wrote:

Am Thu, 09 Oct 2014 15:57:15 +
schrieb "Dicebot" :


Unfortunately it doesn't. RC does. Lazy computation relies on
escaping ranges all over the place (i.e. as fields inside
structs implementing the lazy computation). If there's no way
to track those many tidbits, resources cannot be reclaimed
timely.


Are you trying to tell me programs I work with do not exist? :)

Usage of output range is simply a generalization of out array
parameter used in both Tango and our code. It is _already_ proved
to work for our cases. Usage of input ranges is less important
but it fits existing Phobos style better.

We also don't usually reclaim resources. Out application usually
work by growing constant amount of buffers to the point where
they can handle routine workload and staying there will almost 0
GC activity.

I don't understand statement about storing the ranges. The way I
have it in mind ranges are tool for algorithm composition. Once
you want to store it as a struct field you force range evaluation
via output range and store resulting allocated buffer. In user
code.


I think Andrei means at some point you have to 'store the range' or
create an (often dynamic) array from the range and then you still need
some sort of memory management.

Ultimately you still need some sort of memory management there and RC
will be nice for that if you don't want to use the GC. You can also
store the range to a stack buffer or use manual memory management. But
ranges alone do not solve this problem and forcing everyone to do
manual memory management is not a good replacement for GC, so we need
the discussed RC scheme. At least this is how I understood Andrei's
point.


Yes, that's accurate. Thanks! -- Andrei




Re: What are the worst parts of D?

2014-10-09 Thread Andrei Alexandrescu via Digitalmars-d

On 10/9/14, 8:57 AM, Dicebot wrote:

On Thursday, 9 October 2014 at 15:32:06 UTC, Andrei Alexandrescu wrote:

Unfortunately it doesn't. RC does. Lazy computation relies on escaping
ranges all over the place (i.e. as fields inside structs implementing
the lazy computation). If there's no way to track those many tidbits,
resources cannot be reclaimed timely.


Are you trying to tell me programs I work with do not exist? :)


In all likelihood it's a small misunderstanding.


Usage of output range is simply a generalization of out array parameter
used in both Tango and our code. It is _already_ proved to work for our
cases.


Got it. Output ranges work great with unstructured/linear outputs - 
preallocate an array, fill it with stuff, all's nice save for the 
occasional reallocation when things don't fit etc.


With structured outputs there are a lot more issues to address: one can 
think of a JSONObject as an output range with put() but that's only 
moving the real issues around. How would the JSONObject allocate memory 
internally, give it out to its own users, and dispose of it timely, all 
in good safety?


That's why JSON tokenization is relatively easy to do lazily/with output 
ranges, but full-blown parsing becomes a different proposition.



Andrei



Re: What are the worst parts of D?

2014-10-09 Thread Johannes Pfau via Digitalmars-d
Am Thu, 09 Oct 2014 15:57:15 +
schrieb "Dicebot" :

> > Unfortunately it doesn't. RC does. Lazy computation relies on 
> > escaping ranges all over the place (i.e. as fields inside 
> > structs implementing the lazy computation). If there's no way 
> > to track those many tidbits, resources cannot be reclaimed 
> > timely.  
> 
> Are you trying to tell me programs I work with do not exist? :)
> 
> Usage of output range is simply a generalization of out array 
> parameter used in both Tango and our code. It is _already_ proved 
> to work for our cases. Usage of input ranges is less important 
> but it fits existing Phobos style better.
> 
> We also don't usually reclaim resources. Out application usually 
> work by growing constant amount of buffers to the point where 
> they can handle routine workload and staying there will almost 0 
> GC activity.
> 
> I don't understand statement about storing the ranges. The way I 
> have it in mind ranges are tool for algorithm composition. Once 
> you want to store it as a struct field you force range evaluation 
> via output range and store resulting allocated buffer. In user 
> code.

I think Andrei means at some point you have to 'store the range' or
create an (often dynamic) array from the range and then you still need
some sort of memory management.

Ultimately you still need some sort of memory management there and RC
will be nice for that if you don't want to use the GC. You can also
store the range to a stack buffer or use manual memory management. But
ranges alone do not solve this problem and forcing everyone to do
manual memory management is not a good replacement for GC, so we need
the discussed RC scheme. At least this is how I understood Andrei's
point.


Re: What are the worst parts of D?

2014-10-09 Thread Andrei Alexandrescu via Digitalmars-d

On 10/9/14, 9:00 AM, Dicebot wrote:

On Thursday, 9 October 2014 at 15:59:12 UTC, Andrei Alexandrescu wrote:

"Dicebot"  wrote:

On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:

Multiple approaches to how library functions can handle memory.


As long as it allows us avoid creating new GC roots and keep using GC
for
all allocations at the same time.


To clarify: calling GC.free does remove the root, correct?


Not before it creates one. When I mean "avoid creating new GC roots" I
mean "no GC activity at all other than extending existing chunks"


That's interesting. So GC.malloc followed by GC.free does actually 
affect things negatively? Also let's note that extending existing chunks 
may result in new allocations.


Andrei



Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d
On Thursday, 9 October 2014 at 15:59:12 UTC, Andrei Alexandrescu 
wrote:

"Dicebot"  wrote:

On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
Multiple approaches to how library functions can handle 
memory.


As long as it allows us avoid creating new GC roots and keep 
using GC for

all allocations at the same time.


To clarify: calling GC.free does remove the root, correct?


Not before it creates one. When I mean "avoid creating new GC 
roots" I mean "no GC activity at all other than extending 
existing chunks"


Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d
On Thursday, 9 October 2014 at 15:32:06 UTC, Andrei Alexandrescu 
wrote:

On 10/9/14, 7:09 AM, Dicebot wrote:
Yes and this is exactly why I am that concerned about recent 
memory
management policy thread. Don has already stated it in his 
talks but I

will repeat important points:

1) We don't try to avoid GC in any way
2) However it is critical for performance to avoid creating 
garbage in a

form of new GC roots
3) Worst part of Phobos is not GC allocations but specifically 
lot of

temporarily garbage allocations


What would be a few good examples of (3)? Thanks.


Infamous setExtensions 
(https://github.com/D-Programming-Language/phobos/blob/master/std/path.d#L843) 
immediately comes to mind. Usage of concatenation operators there 
allocates a new GC root for a new string.



This is a very simple issue that will prevent us from using and
contributing to majority of Phobos even when D2 port is 
finished.


Switch to input/output ranges as API fundamentals was supposed 
to fix

it.


Unfortunately it doesn't. RC does. Lazy computation relies on 
escaping ranges all over the place (i.e. as fields inside 
structs implementing the lazy computation). If there's no way 
to track those many tidbits, resources cannot be reclaimed 
timely.


Are you trying to tell me programs I work with do not exist? :)

Usage of output range is simply a generalization of out array 
parameter used in both Tango and our code. It is _already_ proved 
to work for our cases. Usage of input ranges is less important 
but it fits existing Phobos style better.


We also don't usually reclaim resources. Out application usually 
work by growing constant amount of buffers to the point where 
they can handle routine workload and staying there will almost 0 
GC activity.


I don't understand statement about storing the ranges. The way I 
have it in mind ranges are tool for algorithm composition. Once 
you want to store it as a struct field you force range evaluation 
via output range and store resulting allocated buffer. In user 
code.



Custom management policies as you propose won't fix it at all
because garbage will still be there, simply managed in a 
different way.


I'm not sure I understand this.


Typical pattern from existing D1 code:

// bad
auto foo(char[] arg)
{
return arg ~ "aaa";
}

vs

// good
auto foo(char[] arg, ref char[] result)
{
result.length = arg.length +3; // won't allocate if already 
has capacity

result[0 .. arg.length] = arg[];
result[arg.length .. arg.length + 3] = "aaa"[];
}

It doesn't matter if first snippet allocates GC root or 
ref-counted root. We need the version that does not allocate new 
root at all (second snippet).


Re: What are the worst parts of D?

2014-10-09 Thread Andrei Alexandrescu via Digitalmars-d
"Dicebot"  wrote:
> On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
>> Multiple approaches to how library functions can handle memory.
> 
> As long as it allows us avoid creating new GC roots and keep using GC for
> all allocations at the same time.

To clarify: calling GC.free does remove the root, correct?


Re: What are the worst parts of D?

2014-10-09 Thread Andrei Alexandrescu via Digitalmars-d

On 10/9/14, 7:09 AM, Dicebot wrote:

Yes and this is exactly why I am that concerned about recent memory
management policy thread. Don has already stated it in his talks but I
will repeat important points:

1) We don't try to avoid GC in any way
2) However it is critical for performance to avoid creating garbage in a
form of new GC roots
3) Worst part of Phobos is not GC allocations but specifically lot of
temporarily garbage allocations


What would be a few good examples of (3)? Thanks.


This is a very simple issue that will prevent us from using and
contributing to majority of Phobos even when D2 port is finished.

Switch to input/output ranges as API fundamentals was supposed to fix
it.


Unfortunately it doesn't. RC does. Lazy computation relies on escaping 
ranges all over the place (i.e. as fields inside structs implementing 
the lazy computation). If there's no way to track those many tidbits, 
resources cannot be reclaimed timely.


Walter and I have only recently achieved clarity on this.


Custom management policies as you propose won't fix it at all
because garbage will still be there, simply managed in a different way.


I'm not sure I understand this.


This is especially dissapointing because it was a first time when
declared big effort seemed to help our needs but it got abandoned after
very first attempts.


It hasn't gotten abandoned; it's on the back burner. Lazification is a 
good thing to do, but won't get us closer to taking the garbage out.



Andrei



Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d

On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:

Multiple approaches to how library functions can handle memory.


As long as it allows us avoid creating new GC roots and keep 
using GC for all allocations at the same time.


Re: What are the worst parts of D?

2014-10-09 Thread Daniel Murphy via Digitalmars-d
"Manu via Digitalmars-d"  wrote in message 
news:mailman.559.1412859804.9932.digitalmar...@puremagic.com...



Dan Murphy seemed to think ddmd would have some focus on usage as a lib?


Yes, but it's a long way off. 



Re: What are the worst parts of D?

2014-10-09 Thread ixid via Digitalmars-d

On Thursday, 9 October 2014 at 14:47:00 UTC, Dicebot wrote:

On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote:

Dicebot wrote:

Switch to input/output ranges as API fundamentals was 
supposed to fix it. Custom management policies as you propose 
won't fix it at all because garbage will still be there, 
simply managed in a different way.



Would it be impractical to support multiple approaches through
templates? There seemed to be clear use cases where supplying
memory to a function was a good idea and some where it wasn't.


Multiple approaches for what? Adnrei proposal is not 
fundamentally incompatible with range-fication our using our 
array parameters, it simply moves the focus in a different 
direction (which is of no use to us).


Looking at 
http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage I 
also feel that ranges + reusable exceptions pools (needs 
refcounting for exceptions to implement) alone can take care of 
majority of issue, new proposal being more of a niche thing.


Multiple approaches to how library functions can handle memory.


Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d

On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote:

Dicebot wrote:

Switch to input/output ranges as API fundamentals was supposed 
to fix it. Custom management policies as you propose won't fix 
it at all because garbage will still be there, simply managed 
in a different way.



Would it be impractical to support multiple approaches through
templates? There seemed to be clear use cases where supplying
memory to a function was a good idea and some where it wasn't.


Multiple approaches for what? Adnrei proposal is not 
fundamentally incompatible with range-fication our using our 
array parameters, it simply moves the focus in a different 
direction (which is of no use to us).


Looking at 
http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage I 
also feel that ranges + reusable exceptions pools (needs 
refcounting for exceptions to implement) alone can take care of 
majority of issue, new proposal being more of a niche thing.


Re: What are the worst parts of D?

2014-10-09 Thread ixid via Digitalmars-d

Dicebot wrote:

Switch to input/output ranges as API fundamentals was supposed 
to fix it. Custom management policies as you propose won't fix 
it at all because garbage will still be there, simply managed 
in a different way.



Would it be impractical to support multiple approaches through
templates? There seemed to be clear use cases where supplying
memory to a function was a good idea and some where it wasn't.


Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d
On Thursday, 9 October 2014 at 09:37:29 UTC, Danni Coy via 
Digitalmars-d wrote:
It might be unfair but it is still a massive problem. The 
tooling
compared to what I have with say C++ and Qt is not a fun 
experience.
The language is nicer but the difference in tooling is making 
the

difference seem a lot smaller than it should be.


This tooling does not exist in C++ magically. It exists there 
because many people were willing to work on it and much more were 
willing to pay for it. So unless you personally are ready to do 
one of those things those expectations will never come true.


Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d

On Wednesday, 8 October 2014 at 20:07:09 UTC, Walter Bright wrote:

On 10/8/2014 4:17 AM, Don wrote:
As I said in my Dconf 2013 talk -- I advocate a focus on 
Return On Investment.

I'd love to see us chasing the easy wins.


I love the easy wins, too. It'd be great if you'd start a 
thread about "Top 10 Easy Wins" from yours and Sociomantic's 
perspective.


Note that I've done some work on the deprecations you've 
mentioned before.


That can possibly be done though it will take some efforts to 
formalize issues from the casual chat rants. More important issue 
is - what will happen next? I am pretty sure many of those easy 
wins are not easy at all in a sense that breaking changes are 
needed.


Re: What are the worst parts of D?

2014-10-09 Thread Dicebot via Digitalmars-d
On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via 
Digitalmars-d wrote:
On Monday, 6 October 2014 at 16:06:04 UTC, Andrei 
Alexandrescu wrote:

[...]
It would be terrific if Sociomantic would improve its 
communication
with the community about their experience with D and their 
needs

going forward.


How about someone starts paying attention to what Don posts? 
That
could be an incredible start. I spend great deal of time both 
reading
this NG (to be aware of what comes next) and writing (to 
express both
personal and Sociomantic concerns) and have literally no idea 
what can

be done to make communication more clear.


I don't remember who it was, but I'm pretty sure *somebody* at
Sociomantic has stated clearly their request recently: Please 
break our
code *now*, if it helps to fix language design issues, rather 
than

later.


More particulars would be definitely welcome. I should add that 
Sociomantic has an interesting position: it's a 100% D shop so 
interoperability is not a concern for them, and they did their 
own GC so GC-related improvements are unlikely to make a large 
difference for them. So "C++ and GC" is likely not to be high 
priority for them. -- Andrei


Yes and this is exactly why I am that concerned about recent 
memory management policy thread. Don has already stated it in his 
talks but I will repeat important points:


1) We don't try to avoid GC in any way
2) However it is critical for performance to avoid creating 
garbage in a form of new GC roots
3) Worst part of Phobos is not GC allocations but specifically 
lot of temporarily garbage allocations


This is a very simple issue that will prevent us from using and 
contributing to majority of Phobos even when D2 port is finished.


Switch to input/output ranges as API fundamentals was supposed to 
fix it. Custom management policies as you propose won't fix it at 
all because garbage will still be there, simply managed in a 
different way.


This is especially dissapointing because it was a first time when 
declared big effort seemed to help our needs but it got abandoned 
after very first attempts.


Re: What are the worst parts of D?

2014-10-09 Thread Manu via Digitalmars-d
On 09/10/2014 10:15 pm, "Atila Neves via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
>
>> Debugging, ldc (for windows), and editor integrations (auto complete,
>> navigation, refactoring tools) are my impersonal (and hopefully
>> non-controversial) short list. They trump everything else I've
>
>
> I don't know how well DCD works with other editors, but in Emacs at least
(when DCD doesn't throw an exception, I need to chase those down),
autocomplete and code navigation just work. _Including_ dub dependencies.

I haven't found a way to make use of dub yet; all my projects involve other
languages too.
Also, I'm a primary windows user, so I haven't tried DCD to any great
length.
Alexander's auto complete is getting better, but it still gets easily
confused, and the refactor and navigation tools are still basically missing.

I feel like it would all be much easier if dmd was a lib that tooling could
make use of. It seems like a lot of redundant effort to rewrite the
language parser over and over when dmd already does it perfectly...

Dan Murphy seemed to think ddmd would have some focus on usage as a lib?

>> The debugging experience is the worst of any language I've used since the
>> 90's, and I would make that top priority.
>
>
> Debugging can definitely be improved on. Even with Iain's fork of gdb I
end up using writeln instead because it's frequently easier.

Iain's work doesn't help on windows sadly. But I think the biggest problem
is the local scope doesn't seem to be properly expressed in the debug info.
It's a compiler problem more than a back end problem. The step cursor is
all over the shop, and local variables alias each other and confuse the
debugger lots. Also I can't inspect the contents of classes.


Re: What are the worst parts of D?

2014-10-09 Thread Atila Neves via Digitalmars-d


Debugging, ldc (for windows), and editor integrations (auto 
complete,

navigation, refactoring tools) are my impersonal (and hopefully
non-controversial) short list. They trump everything else I've


I don't know how well DCD works with other editors, but in Emacs 
at least (when DCD doesn't throw an exception, I need to chase 
those down), autocomplete and code navigation just work. 
_Including_ dub dependencies.


The debugging experience is the worst of any language I've used 
since the

90's, and I would make that top priority.


Debugging can definitely be improved on. Even with Iain's fork of 
gdb I end up using writeln instead because it's frequently easier.


Atila


Re: What are the worst parts of D?

2014-10-09 Thread Danni Coy via Digitalmars-d
> While it would be great if there were a company devoted to such D tooling,
> it doesn't exist right now.  It is completely unrealistic to expect a D
> community of unpaid volunteers to work on these features for your paid
> projects.  If anybody in the community cared as much about these features as
> you, they'd have done it already.

It might be unfair but it is still a massive problem. The tooling
compared to what I have with say C++ and Qt is not a fun experience.
The language is nicer but the difference in tooling is making the
difference seem a lot smaller than it should be.


Re: What are the worst parts of D?

2014-10-09 Thread Don via Digitalmars-d

On Wednesday, 8 October 2014 at 21:07:24 UTC, Walter Bright wrote:

On 10/6/2014 11:13 AM, Dicebot wrote:

Especially because
you have stated that previous proposal (range-fication) which 
did fix the issue

_for me_ is not on the table anymore.


I think it's more stalled because of the setExtension 
controversy.



How about someone starts paying attention to what Don posts? 
That could be an

incredible start.


I don't always agree with Don, but he's almost always right and 
his last post was almost entirely implemented.


Wow, thanks, Walter! I'm wrong pretty regularly, though. A 
reasonable rule of thumb is to ask Daniel Murphy, aka yebblies. 
If he disagrees with me, and I can't change his mind within 30 
minutes, you can be certain that I'm wrong. 


Re: What are the worst parts of D?

2014-10-08 Thread Paolo Invernizzi via Digitalmars-d
On Wednesday, 8 October 2014 at 20:35:05 UTC, Andrei Alexandrescu 
wrote:

On 10/8/14, 4:17 AM, Don wrote:
On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu 
wrote:


And personally, I doubt that many companies would use D, even 
if with
perfect C++ interop, if the toolchain stayed at the current 
level.


That speculation turns out to not be true for Facebook. My turn 
to speculate - many other companies have existing codebases in 
C++, so Sociomantic is "special".


Well, when IMHO, when discussing 'strategies', pretty everything 
it's a speculation...
C++ interlope can also be attrattive when you need to start a new 
project, a you need C++ libs.


But, the point it's that, again, IMHO, you tend to conflate 
Facebook need with D need (I know I'll receive pain back for this 
;-).


Sociomantic is not so special at all, about not having a previous 
C++ codebase: I personally know plenty of cases like that.


But if D don't stop thinking about "new feature" and never 
terminate the previous plans, well, my speculations is that I 
donno about future adopters, but for sure it's scouring actual 
adopters; and the for sure it's based on what we feel here in SR 
Labs company.


That's of course good, but the reality is we're in a 
complicated trade-off space with "important", "urgent", "easy 
to do", "return on investment", "resource allocation" as axes. 
An example of the latter - ideally we'd put Walter on the more 
difficult tasks and others on the easy wins. Walter working on 
improving documentation might not be the best use of his time, 
although better documentation is an easy win.


Well, I've read your and Walter comment on the multiple alias 
this PR, so good: but the point that it was the community that 
pushed both of you on that track, it's systematic about an 
attitude.


And now, shields up, Ms Sulu!
--
/Paolo


Re: What are the worst parts of D?

2014-10-08 Thread Paolo Invernizzi via Digitalmars-d

On Thursday, 9 October 2014 at 00:30:53 UTC, Walter Bright wrote:

On 9/25/2014 4:08 AM, Don wrote:


And adding a @ in front of pure, nothrow.


https://issues.dlang.org/show_bug.cgi?id=13388

It has generated considerable discussion.


Please break the language, now.

---
/Paolo





Re: What are the worst parts of D?

2014-10-08 Thread Walter Bright via Digitalmars-d

On 9/25/2014 4:08 AM, Don wrote:

I'd also like to see us getting rid of those warts like assert(float.nan) being
true.


https://issues.dlang.org/show_bug.cgi?id=13489

It has some serious issues with it - I suspect it'll cause uglier problems than 
it fixes.




And adding a @ in front of pure, nothrow.


https://issues.dlang.org/show_bug.cgi?id=13388

It has generated considerable discussion.


Re: What are the worst parts of D?

2014-10-08 Thread Manu via Digitalmars-d
On 09/10/2014 2:40 am, "Joakim via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 8 October 2014 at 13:55:11 UTC, Manu via Digitalmars-d
wrote:
>>
>> On 08/10/2014 9:20 pm, "Don via Digitalmars-d"
>>>
>>> So what do we care about? Mainly, we care about improving the core
>>
>> product.
>>>
>>>
>>> In general I think that in D we have always suffered from spreading
>>
>> ourselves too thin. We've always had a bunch of cool new features that
>> don't actually work properly. Always, the focus shifts to something else,
>> before the previous feature was finished.
>>>
>>>
>>> And personally, I doubt that many companies would use D, even if with
>>
>> perfect C++ interop, if the toolchain stayed at the current level.
>>
>> As someone who previously represented a business interest, I couldn't
agree
>> more.
>> Aside from my random frustrated outbursts on a very small set of language
>> issues, the main thing I've been banging on from day 1 is the tooling.
Much
>> has improved, but it's still a long way from 'good'.
>>
>> Debugging, ldc (for windows), and editor integrations (auto complete,
>> navigation, refactoring tools) are my impersonal (and hopefully
>> non-controversial) short list. They trump everything else I've ever
>> complained about.
>> The debugging experience is the worst of any language I've used since the
>> 90's, and I would make that top priority.
>
>
> While it would be great if there were a company devoted to such D
tooling, it doesn't exist right now.  It is completely unrealistic to
expect a D community of unpaid volunteers to work on these features for
your paid projects.  If anybody in the community cared as much about these
features as you, they'd have done it already.
>
> I suggest you two open bugzilla issues for all these specific bugs or
enhancements and put up bounties for their development.  If you're not
willing to do that, expecting the community to do work for you for free is
just whining that is easily ignored.

We're just talking about what we think would best drive adoption.
Businesses aren't likely to adopt a language with the understanding that
they need to write it's tooling. Debugging, code competition and
refactoring are all expert tasks that probably require compiler involvement.

I know it's easy to say that businesses with budget should contribute more.
But it's a tough proposition. Businesses will look to change language if it
saves them time and money. If it's going to cost them money, and the state
of tooling is likely to cost them time, then it's not a strong proposition.
It's a chicken and egg problem. I'm sure business will be happy to
contribute financially when it's a risk free investment; ie, when it's
demonstrated that that stuff works for them.


Re: What are the worst parts of D?

2014-10-08 Thread Walter Bright via Digitalmars-d

On 10/6/2014 11:13 AM, Dicebot wrote:

Especially because
you have stated that previous proposal (range-fication) which did fix the issue
_for me_ is not on the table anymore.


I think it's more stalled because of the setExtension controversy.



How about someone starts paying attention to what Don posts? That could be an
incredible start.


I don't always agree with Don, but he's almost always right and his last post 
was almost entirely implemented.




Re: What are the worst parts of D?

2014-10-08 Thread Andrei Alexandrescu via Digitalmars-d

On 10/8/14, 4:17 AM, Don wrote:

On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:

More particulars would be definitely welcome. I should add that
Sociomantic has an interesting position: it's a 100% D shop so
interoperability is not a concern for them, and they did their own GC
so GC-related improvements are unlikely to make a large difference for
them. So "C++ and GC" is likely not to be high priority for them. --
Andrei


Exactly. C++ support is of no interest at all, and GC is something we
contribute to, rather than something we expect from the community.


That's awesome, thanks!


Interestingly we don't even care much about libraries, we've done
everything ourselves.

So what do we care about? Mainly, we care about improving the core product.

In general I think that in D we have always suffered from spreading
ourselves too thin. We've always had a bunch of cool new features that
don't actually work properly. Always, the focus shifts to something
else, before the previous feature was finished.

At Sociomantic, we've been successful in our industry using only the
features of D1. We're restricted to using D's features from 2007!!
Feature-wise, practically nothing from the last seven years has helped us!

With something like C++ support, it's only going to win companies over
when it is essentially complete. That means that working on it is a huge
investment that doesn't start to pay for itself for a very long time. So
although it's a great goal, with a huge potential payoff, I don't think
that it should be consuming a whole lot of energy right now.

And personally, I doubt that many companies would use D, even if with
perfect C++ interop, if the toolchain stayed at the current level.


That speculation turns out to not be true for Facebook. My turn to 
speculate - many other companies have existing codebases in C++, so 
Sociomantic is "special".



As I said in my Dconf 2013 talk -- I advocate a focus on Return On
Investment.
I'd love to see us chasing the easy wins.


That's of course good, but the reality is we're in a complicated 
trade-off space with "important", "urgent", "easy to do", "return on 
investment", "resource allocation" as axes. An example of the latter - 
ideally we'd put Walter on the more difficult tasks and others on the 
easy wins. Walter working on improving documentation might not be the 
best use of his time, although better documentation is an easy win.



Andrei



Re: What are the worst parts of D?

2014-10-08 Thread Walter Bright via Digitalmars-d

On 10/8/2014 4:17 AM, Don wrote:

As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment.
I'd love to see us chasing the easy wins.


I love the easy wins, too. It'd be great if you'd start a thread about "Top 10 
Easy Wins" from yours and Sociomantic's perspective.


Note that I've done some work on the deprecations you've mentioned before.



Re: What are the worst parts of D?

2014-10-08 Thread Jeremy Powers via Digitalmars-d
On Wed, Oct 8, 2014 at 12:00 PM, Jonathan via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
...

> 3) Taking a hint from the early success of Flash, add Derelict3 (or some
> basic OpenGL library) directly into Phobos. Despite some of the negatives
> (slower update cycle versus external lib), it would greatly add to D's
> attractiveness for new developers. I nearly left D after having a host
> issues putting Derelict3 into my project. If I had this issue, we may be
> missing out from attracting newbies looking to do gfx related work.
>

Personally I take the opposite view - I'd much prefer a strong and easily
consumed third-party library ecosystem than to shove everything into
Phobos.  Dub is a wonderful thing for D, and needs to be so good that
people use it by default.


Re: What are the worst parts of D?

2014-10-08 Thread Jonathan via Digitalmars-d

My small list of D critiques/wishes from a pragmatic stance:

1) Replace the Stop the World GC
2) It would be great if dmd could provide a code-hinting 
facility, instead of relying on DCD which continually breaks for 
me. It would open more doors for editors to support better code 
completion.
3) Taking a hint from the early success of Flash, add Derelict3 
(or some basic OpenGL library) directly into Phobos. Despite some 
of the negatives (slower update cycle versus external lib), it 
would greatly add to D's attractiveness for new developers. I 
nearly left D after having a host issues putting Derelict3 into 
my project. If I had this issue, we may be missing out from 
attracting newbies looking to do gfx related work.


I'm sure this has been talked about, but I'll bring it up anyway:
To focus our efforts, consider switching to ldc. Is it worth 
people's time to continue to optimize DMD when we can accelerate 
our own efforts by relying on an existing compiler? As some have 
pointed out, our community is spread thin over so many efforts... 
perhaps there are ways to consolidate that.


Just my 2cents from a D hobbyist..


Re: What are the worst parts of D?

2014-10-08 Thread Joakim via Digitalmars-d
On Wednesday, 8 October 2014 at 13:55:11 UTC, Manu via 
Digitalmars-d wrote:

On 08/10/2014 9:20 pm, "Don via Digitalmars-d"
So what do we care about? Mainly, we care about improving the 
core

product.


In general I think that in D we have always suffered from 
spreading
ourselves too thin. We've always had a bunch of cool new 
features that
don't actually work properly. Always, the focus shifts to 
something else,

before the previous feature was finished.


And personally, I doubt that many companies would use D, even 
if with
perfect C++ interop, if the toolchain stayed at the current 
level.


As someone who previously represented a business interest, I 
couldn't agree

more.
Aside from my random frustrated outbursts on a very small set 
of language
issues, the main thing I've been banging on from day 1 is the 
tooling. Much

has improved, but it's still a long way from 'good'.

Debugging, ldc (for windows), and editor integrations (auto 
complete,

navigation, refactoring tools) are my impersonal (and hopefully
non-controversial) short list. They trump everything else I've 
ever

complained about.
The debugging experience is the worst of any language I've used 
since the

90's, and I would make that top priority.


While it would be great if there were a company devoted to such D 
tooling, it doesn't exist right now.  It is completely 
unrealistic to expect a D community of unpaid volunteers to work 
on these features for your paid projects.  If anybody in the 
community cared as much about these features as you, they'd have 
done it already.


I suggest you two open bugzilla issues for all these specific 
bugs or enhancements and put up bounties for their development.  
If you're not willing to do that, expecting the community to do 
work for you for free is just whining that is easily ignored.


Re: What are the worst parts of D?

2014-10-08 Thread Manu via Digitalmars-d
On 08/10/2014 11:55 pm, "Manu"  wrote:
>
> On 08/10/2014 9:20 pm, "Don via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
> >
> > On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
> >>
> >> On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
> >>>
> >>> On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d
wrote:
> 
>  On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:
> >>>
> >>> [...]
> >
> > It would be terrific if Sociomantic would improve its communication
> > with the community about their experience with D and their needs
> > going forward.
> 
> 
>  How about someone starts paying attention to what Don posts? That
>  could be an incredible start. I spend great deal of time both reading
>  this NG (to be aware of what comes next) and writing (to express both
>  personal and Sociomantic concerns) and have literally no idea what
can
>  be done to make communication more clear.
> >>>
> >>>
> >>> I don't remember who it was, but I'm pretty sure *somebody* at
> >>> Sociomantic has stated clearly their request recently: Please break
our
> >>> code *now*, if it helps to fix language design issues, rather than
> >>> later.
> >>
> >>
> >> More particulars would be definitely welcome. I should add that
Sociomantic has an interesting position: it's a 100% D shop so
interoperability is not a concern for them, and they did their own GC so
GC-related improvements are unlikely to make a large difference for them.
So "C++ and GC" is likely not to be high priority for them. -- Andrei
> >
> >
> > Exactly. C++ support is of no interest at all, and GC is something we
contribute to, rather than something we expect from the community.
> > Interestingly we don't even care much about libraries, we've done
everything ourselves.
> >
> > So what do we care about? Mainly, we care about improving the core
product.
> >
> > In general I think that in D we have always suffered from spreading
ourselves too thin. We've always had a bunch of cool new features that
don't actually work properly. Always, the focus shifts to something else,
before the previous feature was finished.
> >
> > At Sociomantic, we've been successful in our industry using only the
features of D1. We're restricted to using D's features from 2007!!
Feature-wise, practically nothing from the last seven years has helped us!
> >
> > With something like C++ support, it's only going to win companies over
when it is essentially complete. That means that working on it is a huge
investment that doesn't start to pay for itself for a very long time. So
although it's a great goal, with a huge potential payoff, I don't think
that it should be consuming a whole lot of energy right now.
> >
> > And personally, I doubt that many companies would use D, even if with
perfect C++ interop, if the toolchain stayed at the current level.
> >
> > As I said in my Dconf 2013 talk -- I advocate a focus on Return On
Investment.
> > I'd love to see us chasing the easy wins.
>
> As someone who previously represented a business interest, I couldn't
agree more.
> Aside from my random frustrated outbursts on a very small set of language
issues, the main thing I've been banging on from day 1 is the tooling. Much
has improved, but it's still a long way from 'good'.
>
> Debugging, ldc (for windows), and editor integrations (auto complete,
navigation, refactoring tools) are my impersonal (and hopefully
non-controversial) short list. They trump everything else I've ever
complained about.
> The debugging experience is the worst of any language I've used since the
90's, and I would make that top priority.
>
> C++ might have helped us years ago, but I already solved those issues
creatively. Debugging can't be solved without tooling and compiler support.

Just to clarify, I'm all for nogc work; that is very important to us and I
appreciate the work, but I support that I wouldn't rate it top priority.
C++ is no significant value to me personally, or professionally. Game
studios don't use much C++, and like I said, we already worked around those
edges.

I can't speak for remedy now, but I'm confident that they will *need* ldc
working before the game ships. DMD codegen is just not good enough,
particularly relating to float; it uses the x87! O_O


Re: What are the worst parts of D?

2014-10-08 Thread Manu via Digitalmars-d
On 08/10/2014 9:20 pm, "Don via Digitalmars-d" 
wrote:
>
> On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
>>
>> On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
>>>
>>> On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d
wrote:

 On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:
>>>
>>> [...]
>
> It would be terrific if Sociomantic would improve its communication
> with the community about their experience with D and their needs
> going forward.


 How about someone starts paying attention to what Don posts? That
 could be an incredible start. I spend great deal of time both reading
 this NG (to be aware of what comes next) and writing (to express both
 personal and Sociomantic concerns) and have literally no idea what can
 be done to make communication more clear.
>>>
>>>
>>> I don't remember who it was, but I'm pretty sure *somebody* at
>>> Sociomantic has stated clearly their request recently: Please break our
>>> code *now*, if it helps to fix language design issues, rather than
>>> later.
>>
>>
>> More particulars would be definitely welcome. I should add that
Sociomantic has an interesting position: it's a 100% D shop so
interoperability is not a concern for them, and they did their own GC so
GC-related improvements are unlikely to make a large difference for them.
So "C++ and GC" is likely not to be high priority for them. -- Andrei
>
>
> Exactly. C++ support is of no interest at all, and GC is something we
contribute to, rather than something we expect from the community.
> Interestingly we don't even care much about libraries, we've done
everything ourselves.
>
> So what do we care about? Mainly, we care about improving the core
product.
>
> In general I think that in D we have always suffered from spreading
ourselves too thin. We've always had a bunch of cool new features that
don't actually work properly. Always, the focus shifts to something else,
before the previous feature was finished.
>
> At Sociomantic, we've been successful in our industry using only the
features of D1. We're restricted to using D's features from 2007!!
Feature-wise, practically nothing from the last seven years has helped us!
>
> With something like C++ support, it's only going to win companies over
when it is essentially complete. That means that working on it is a huge
investment that doesn't start to pay for itself for a very long time. So
although it's a great goal, with a huge potential payoff, I don't think
that it should be consuming a whole lot of energy right now.
>
> And personally, I doubt that many companies would use D, even if with
perfect C++ interop, if the toolchain stayed at the current level.
>
> As I said in my Dconf 2013 talk -- I advocate a focus on Return On
Investment.
> I'd love to see us chasing the easy wins.

As someone who previously represented a business interest, I couldn't agree
more.
Aside from my random frustrated outbursts on a very small set of language
issues, the main thing I've been banging on from day 1 is the tooling. Much
has improved, but it's still a long way from 'good'.

Debugging, ldc (for windows), and editor integrations (auto complete,
navigation, refactoring tools) are my impersonal (and hopefully
non-controversial) short list. They trump everything else I've ever
complained about.
The debugging experience is the worst of any language I've used since the
90's, and I would make that top priority.

C++ might have helped us years ago, but I already solved those issues
creatively. Debugging can't be solved without tooling and compiler support.


Re: What are the worst parts of D?

2014-10-08 Thread Don via Digitalmars-d
On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via 
Digitalmars-d wrote:
On Monday, 6 October 2014 at 16:06:04 UTC, Andrei 
Alexandrescu wrote:

[...]
It would be terrific if Sociomantic would improve its 
communication
with the community about their experience with D and their 
needs

going forward.


How about someone starts paying attention to what Don posts? 
That
could be an incredible start. I spend great deal of time both 
reading
this NG (to be aware of what comes next) and writing (to 
express both
personal and Sociomantic concerns) and have literally no idea 
what can

be done to make communication more clear.


I don't remember who it was, but I'm pretty sure *somebody* at
Sociomantic has stated clearly their request recently: Please 
break our
code *now*, if it helps to fix language design issues, rather 
than

later.


More particulars would be definitely welcome. I should add that 
Sociomantic has an interesting position: it's a 100% D shop so 
interoperability is not a concern for them, and they did their 
own GC so GC-related improvements are unlikely to make a large 
difference for them. So "C++ and GC" is likely not to be high 
priority for them. -- Andrei


Exactly. C++ support is of no interest at all, and GC is 
something we contribute to, rather than something we expect from 
the community.
Interestingly we don't even care much about libraries, we've done 
everything ourselves.


So what do we care about? Mainly, we care about improving the 
core product.


In general I think that in D we have always suffered from 
spreading ourselves too thin. We've always had a bunch of cool 
new features that don't actually work properly. Always, the focus 
shifts to something else, before the previous feature was 
finished.


At Sociomantic, we've been successful in our industry using only 
the features of D1. We're restricted to using D's features from 
2007!! Feature-wise, practically nothing from the last seven 
years has helped us!


With something like C++ support, it's only going to win companies 
over when it is essentially complete. That means that working on 
it is a huge investment that doesn't start to pay for itself for 
a very long time. So although it's a great goal, with a huge 
potential payoff, I don't think that it should be consuming a 
whole lot of energy right now.


And personally, I doubt that many companies would use D, even if 
with perfect C++ interop, if the toolchain stayed at the current 
level.


As I said in my Dconf 2013 talk -- I advocate a focus on Return 
On Investment.

I'd love to see us chasing the easy wins.






Re: What are the worst parts of D?

2014-10-06 Thread Paolo Invernizzi via Digitalmars-d
On Monday, 6 October 2014 at 19:08:24 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 12:00 PM, Dicebot wrote:
On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via 
Digitalmars-d

wrote:
Or, if you'll allow me to paraphrase it, pay the one-time 
cost of broken
code now, rather than incur the ongoing cost of needing to 
continually

workaround language issues.


Don in this very thread. Multiple times.


He made a few good and very specific points that subsequently 
saw action. This is the kind of feedback we need more of. -- 
Andrei


And here we go again for the multiple alias this: I'm pleased to 
have seen that it will be merged sooner than later.


Just to clarify, taking as an example our company:

- TDPL is a very good training book for C++/Java minions, and 
turns them in, well, not-so-good-but-not-so-terrible D 
programmers. It solve the "boss" perplexity about "there's 
basically no markets for D language programmers: how can we hire 
them in the future?".
For the chronicle, the next lecture is the EXCELLENT "D 
Templates: a tutorial", of Philippe Sigaud, an invaluable 
resource (thank Philippe for that!).


- TDPL is exactly what Dicebot wrote: a plan! Having to bet on 
something, a CTO like me *likes* to bet on a good plan (like the 
A-Team!)


- Being a good plan, and an ambitious one, as a company we 
scrutiny the efforts devoted to complete it, and that set the bar 
for future evaluation of the reliability of _future_ plans and 
proposal.


As an example, the *not resolution* of the shared qualifier mess, 
has a costs in term of how reliable we judge other proposed 
improvements (I know, that may be not fare, but that's it).


I'm not telling that the language must be crystallised, and I 
also understand that as times goes by, other priorities and good 
ideas may come up.


As a company, we don't mind if we are discussing about ARC, GC, 
or C++ interop, but we care about the efforts and time placed on 
the _taken_ decision, especially for the  _past_ plans, and we 
judge that care as strictly correlated to language maturity for 
business adoption.


Just my 2c... again, no pun intended! ;-P
---
/Paolo


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 12:00 PM, Dicebot wrote:

On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via Digitalmars-d
wrote:

Or, if you'll allow me to paraphrase it, pay the one-time cost of broken
code now, rather than incur the ongoing cost of needing to continually
workaround language issues.


Don in this very thread. Multiple times.


He made a few good and very specific points that subsequently saw 
action. This is the kind of feedback we need more of. -- Andrei


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:

On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote:

On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:

[...]

It would be terrific if Sociomantic would improve its communication
with the community about their experience with D and their needs
going forward.


How about someone starts paying attention to what Don posts? That
could be an incredible start. I spend great deal of time both reading
this NG (to be aware of what comes next) and writing (to express both
personal and Sociomantic concerns) and have literally no idea what can
be done to make communication more clear.


I don't remember who it was, but I'm pretty sure *somebody* at
Sociomantic has stated clearly their request recently: Please break our
code *now*, if it helps to fix language design issues, rather than
later.


More particulars would be definitely welcome. I should add that 
Sociomantic has an interesting position: it's a 100% D shop so 
interoperability is not a concern for them, and they did their own GC so 
GC-related improvements are unlikely to make a large difference for 
them. So "C++ and GC" is likely not to be high priority for them. -- Andrei


Re: What are the worst parts of D?

2014-10-06 Thread Dicebot via Digitalmars-d
On Monday, 6 October 2014 at 18:57:04 UTC, H. S. Teoh via 
Digitalmars-d wrote:
Or, if you'll allow me to paraphrase it, pay the one-time cost 
of broken
code now, rather than incur the ongoing cost of needing to 
continually

workaround language issues.


Don in this very thread. Multiple times.


Re: What are the worst parts of D?

2014-10-06 Thread H. S. Teoh via Digitalmars-d
On Mon, Oct 06, 2014 at 06:13:41PM +, Dicebot via Digitalmars-d wrote:
> On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:
[...]
> >It would be terrific if Sociomantic would improve its communication
> >with the community about their experience with D and their needs
> >going forward.
> 
> How about someone starts paying attention to what Don posts? That
> could be an incredible start. I spend great deal of time both reading
> this NG (to be aware of what comes next) and writing (to express both
> personal and Sociomantic concerns) and have literally no idea what can
> be done to make communication more clear.

I don't remember who it was, but I'm pretty sure *somebody* at
Sociomantic has stated clearly their request recently: Please break our
code *now*, if it helps to fix language design issues, rather than
later.

Or, if you'll allow me to paraphrase it, pay the one-time cost of broken
code now, rather than incur the ongoing cost of needing to continually
workaround language issues.


T

-- 
Too many people have open minds but closed eyes.


Re: What are the worst parts of D?

2014-10-06 Thread Dicebot via Digitalmars-d
On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu 
wrote:
I'm confused. Why would anyone who just comes to dlang.org see 
unformed ideas and incomplete designs? Wouldn't newcomers be 
more attracted by e.g. stuff coming in the next release?


Because he is interested in language development direction but 
does not want to actively participate? It can be someone with bad 
early D experience wondering if anything has changed in last 
year. Or it can be developer from some company using D wanting to 
get quick overview what to expect from the language for the next 
year or so.


For example I don't have time to follow Rust mail lists or GitHub 
commits but I do read blog posts of its developers regularly 
(including speculative ones) to see where it is heading. It is 
both interesting and educating and helps to spread the image 
among wider audience as well.


The fact that you don't seem to have a consensus with Walter 
on some
topic (auto-decoding, yeah) doesn't help either. Language 
marketing is

not about posting links on reddit, it is a very hard work of
communicating your vision so that it is clear even to random 
by-passer.


I think one good thing we can do is approach things in private 
before discussing them publicly.


Agreed. I don't propose to stop paying attention to forums or 
drop all discussions but to put a bit more efforts into 
popularizing resulting decisions and plans. So that someone can 
safely ignore some of discussions without fearing that it will 
surprisingly appear in next release catching one off guard.



We now have Martin Nowak as the point of contact.


And what if he gets busy too? :)


Maybe you'll volunteer.


I have already considered that and can be pretty sure this won't 
ever happen (at least not while this implies paying to Apple a 
single cent)


Let's get it straight - I don't care much about D success in 
general. It is a nice language to use here and there, I got an 
awesome job because of it but this is pretty much all the scope. 
There is no way I will ever work on something that is not needed 
to me only because it is important for language success in 
general.


This is pretty much the difference between language author / core 
developer and random contributor and why handling releases is 
safer in the hands of former.


No doubt its design could be done better. But inout was not 
motivated theoretically. It came from the practical need of not 
duplicating code over qualifiers.


I don't mean feature itself was "theoretical". I mean that it was 
implemented and released before it got at least some practical 
usage in live projects with relevant feedback and thus have 
missed some corner cases.


Sean proposed that. In fact that's a very good success story of 
sharing stuff for discussion sooner rather than later: he 
answered a Request For Comments with a great comment.


Well when I have initially asked the same question (why not 
user-controllable policies?) you straight out rejected it. I must 
be very bad at wording questions :(


Again: I don't have a complete design, that's why I'm asking 
for comments in the Request For Comments threads. Would you 
rather have me come up alone with a complete design and then 
show it to the community as a fait accompli? What part of 
"let's do this together" I need to clarify?


"let's do this together" implies agreeing on some base to further 
work on. When I come and see that proposed solution does not 
address a problem I have at all I can't do anything but ask "how 
is this supposed to address my problem?" because that is _your_ 
proposal and I am not gifted with telepathy. Especially because 
you have stated that previous proposal (range-fication) which did 
fix the issue _for me_ is not on the table anymore.


You risk balkanization by keeping the things as they are. We 
do have
talks at work sometimes that simply forking the language may 
be a more
practical approach than pushing necessary breaking changes 
upstream by
the time D2 port is complete. Those are just talks of course 
and until
porting is done it is all just speculations but it does 
indicate certain

level of unhappinness.


It would be terrific if Sociomantic would improve its 
communication with the community about their experience with D 
and their needs going forward.


How about someone starts paying attention to what Don posts? That 
could be an incredible start. I spend great deal of time both 
reading this NG (to be aware of what comes next) and writing (to 
express both personal and Sociomantic concerns) and have 
literally no idea what can be done to make communication more 
clear.



Have you ever considered starting a blog about your vision of D
development to communicate it better to wider audience? :)


Yah, apparently there's no shortage of ideas of things I should 
work on. Perhaps I should do the same. Dicebot, I think you 
should work on making exceptions refcounted :o).


As soon as it becomes a priority issue for me 

Re: What are the worst parts of D?

2014-10-06 Thread Wyatt via Digitalmars-d
On Monday, 6 October 2014 at 15:05:31 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 7:36 AM, Wyatt wrote:


D is going to have C++ support.  That's cool and compelling as
a bare statement, but in what manner?


We don't know yet, we're designing it


The exact list is in the air. We're looking e.g. for the best 
policy on exceptions. Possible vs. impossible is btw a matter 
of scale, for example wrapping everything you need from C++ in 
C functions is possible in the small but impossible at scale.


Ah, I see what happened now!  The way you've been pushing it, I 
was given to believe you had something resembling a "grand 
vision" of how you wanted "C++ interoperability" to work with 
some proposed syntax and semantics.  If not something so 
grandiose, at least a pool of ideas written down?  Or even just a 
mental list of things you think are important to cover?  
Regardless, these things ARE important to communicate clearly.


This was discussed already: we should be able to pass an 
std::vector by reference/pointer from C++ into D and use 
it within D directly, with no intervening marshaling.



Awesome, this is a start.

It seems this is a simple misunderstanding. You're looking for 
a virtually finished product


It really is a misunderstanding.  Heck, I think it still is one 
because all we're really looking for is some inkling of what's on 
your agenda at a granularity finer than "C++ and GC".  If nothing 
else, a list like that gets people thinking about a feature ahead 
of the dedicated thread to discuss it.


-Wyatt

PS: Come to think of it, I may have been expecting a DIP?


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 9:58 AM, H. S. Teoh via Digitalmars-d wrote:

It would be*very*  nice if once in a while (say once a week, or once a
month) you and/or Walter can do a little write-up about the current
status of things. Say a list of top 5 projects currently being worked
on, a list of the top 5 current priorities, a short blurb about
"progress this past week/month" (which could be as simple as "we've been
swamped with fixing regressions, haven't been able to work on anything
else", or "Facebook has me on a short leash, I haven't been able to work
on D", etc.). This should be in its own thread, titled something like
"Weekly [or monthly] status update", not buried underneath mountains of
posts in one of our infamous interminable threads about some
controversial topic, like to autodecode or not to autodecode.

Of course, who am I to tell you what to do... but IMO a periodical
high-level status update like the above would go a*long*  way in
dispelling complaints of "lack of direction" or "unclear/unknown
priorities". It doesn't have to be long, either. Even a 1 page (OK, OK,
*half*  a page), bullet-point post is good enough.


That's a really nice idea. -- Andrei


Re: What are the worst parts of D?

2014-10-06 Thread H. S. Teoh via Digitalmars-d
On Mon, Oct 06, 2014 at 09:39:44AM -0700, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 10/6/14, 9:16 AM, eles wrote:
> >On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote:
> >>On 10/6/14, 7:05 AM, Paolo Invernizzi wrote:
> >>>On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote:
> On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:
> >On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:
> >>
> >
> >>To interpret my lack of time politically is really amusing. You guys
> >>have too much time on your hands :o).
> >
> >At least give such an explanation from time to time. Silence is the
> >worst.
> 
> Wait, are we too active in the forums or too silent? -- Andrei

It would be *very* nice if once in a while (say once a week, or once a
month) you and/or Walter can do a little write-up about the current
status of things. Say a list of top 5 projects currently being worked
on, a list of the top 5 current priorities, a short blurb about
"progress this past week/month" (which could be as simple as "we've been
swamped with fixing regressions, haven't been able to work on anything
else", or "Facebook has me on a short leash, I haven't been able to work
on D", etc.). This should be in its own thread, titled something like
"Weekly [or monthly] status update", not buried underneath mountains of
posts in one of our infamous interminable threads about some
controversial topic, like to autodecode or not to autodecode.

Of course, who am I to tell you what to do... but IMO a periodical
high-level status update like the above would go a *long* way in
dispelling complaints of "lack of direction" or "unclear/unknown
priorities". It doesn't have to be long, either. Even a 1 page (OK, OK,
*half* a page), bullet-point post is good enough.


T

-- 
In theory, software is implemented according to the design that has been
carefully worked out beforehand. In practice, design documents are
written after the fact to describe the sorry mess that has gone on
before.


Re: What are the worst parts of D?

2014-10-06 Thread Paulo Pinto via Digitalmars-d

Am 06.10.2014 10:12, schrieb eles:

On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote:

On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote:

On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:

On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote:

On 10/5/14, 3:08 PM, eles wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


I like the safety that a GC guarantees, but is a too big price to
be paid for that...


Just look at this abomination from here:

http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html


sqlConnection.Close();
sqlConnection.Dispose();
sqlConnection = null;

Is this your idea about releasing a resource? Why is this better than
writing delete/dispose sqlConnection?

If you ask to use structs for RAII, I am afraid that you will receive a
DFront proposal.


This abomination tends to be written by developers that don't care to 
learn how to use properly their tools.


It is quite easy to just use "using" on every IDisposable resource.

As for setting something to null just to let the GC know about it, a 
sign of premature optimization and a sign of not neither knowing how a 
GC works nor how to use a memory profiler.


--
Paulo


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 9:14 AM, eles wrote:

On Monday, 6 October 2014 at 13:55:05 UTC, Andrei Alexandrescu wrote:

On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote:



We will accept multiple "alias this". -- Andrei


=
IgorStepanov  commented 6 days ago

Please, someone, add label "Needs Approval" to this PR. We need discuss
a conflict resolving, and determine right algorithm, if implemented
algorithm isn't right. Thanks.

yebblies added Enhancement Needs Approval labels 6 days ago
=

Please grand approval there.


Will do, thanks. -- Andrei


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 9:16 AM, eles wrote:

On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu wrote:

On 10/6/14, 7:05 AM, Paolo Invernizzi wrote:

On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote:

On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:





To interpret my lack of time politically is really amusing. You guys
have too much time on your hands :o).


At least give such an explanation from time to time. Silence is the worst.


Wait, are we too active in the forums or too silent? -- Andrei



Re: What are the worst parts of D?

2014-10-06 Thread eles via Digitalmars-d
On Monday, 6 October 2014 at 14:53:23 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 7:05 AM, Paolo Invernizzi wrote:
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:




To interpret my lack of time politically is really amusing. You 
guys have too much time on your hands :o).


At least give such an explanation from time to time. Silence is 
the worst.


Re: What are the worst parts of D?

2014-10-06 Thread eles via Digitalmars-d
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:



I did comment in this group. -- Andrei


==
IgorStepanov  commented 17 days ago

Ping

===
quickfur  commented 14 days ago

Wow. I have been waiting for this feature for a long time! Can't 
wait to see this merged. Ping @WalterBright ?

==

IgorStepanov  commented 13 days ago

@andralex Ping. Please comment the tests and conflict resolving 
semantic.


===

IgorStepanov  commented 8 days ago

@andralex ping

==


Re: What are the worst parts of D?

2014-10-06 Thread eles via Digitalmars-d
On Monday, 6 October 2014 at 13:55:05 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote:



We will accept multiple "alias this". -- Andrei


=
IgorStepanov  commented 6 days ago

Please, someone, add label "Needs Approval" to this PR. We need 
discuss a conflict resolving, and determine right algorithm, if 
implemented algorithm isn't right. Thanks.


yebblies added Enhancement Needs Approval labels 6 days ago
=

Please grand approval there.


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/5/14, 9:14 AM, Dicebot wrote:

On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu wrote:

1. C++ support is good for attracting companies featuring large C++
codebases to get into D for new code without disruptions.

2. Auto-decoding is blown out of proportion and a distraction at this
time.

3. Ref counting is necessary again for encouraging adoption. We've
framed GC as an user education matter for years. We might have even
been right for the most part, but it doesn't matter. Fact is that a
large potential user base will simply not consider a GC language.


No need to explain it here. When I speak about vision I mean something
that anyone coming to dlang.org page or GitHub repo sees. Something that
is explained in a bit more details, possibly with code examples. I know
I am asking much but seeing quick reference for "imagine this stuff is
implemented, this is how your program code will be affected and this is
why it is a good thing" could have been huge deal.


I'm confused. Why would anyone who just comes to dlang.org see unformed 
ideas and incomplete designs? Wouldn't newcomers be more attracted by 
e.g. stuff coming in the next release?



Right now your rationales get lost in forum discussion threads and it is
hard to understand what really is Next Big Thing and what is just forum
argument blown out of proportion. There was a go at properties, at
eliminating destructors, at rvalue references and whatever else I have
forgotten by now. It all pretty much ended with "do nothing" outcome for
one reason or the other.


Let's see. We have properties, which indeed need some work done but 
don't seem to prevent people from getting work done. The discussion on 
eliminating destructors concluded with "we don't want to do that for 
good reasons". For binding rvalues Walter has a tentative design that's 
due for an RFC soon.



The fact that you don't seem to have a consensus with Walter on some
topic (auto-decoding, yeah) doesn't help either. Language marketing is
not about posting links on reddit, it is a very hard work of
communicating your vision so that it is clear even to random by-passer.


I think one good thing we can do is approach things in private before 
discussing them publicly.



2) reliable release base

I think this is most important part of open-source infrastructure needed
to attract more contributions and something that also belongs to the
"core team". I understand why Walter was so eager to delegate is but
right now the truth is that once Andrew has to temporarily leave all
release process has immediately stalled. And finding replacement is not
easy - this task is inherently ungrateful as it implies spending time
and resources on stuff you personally don't need at all.


We now have Martin Nowak as the point of contact.


And what if he gets busy too? :)


Maybe you'll volunteer.


3) lack of field testing

Too many new features get added simply because they look theoretically
sound.


What would those be?


Consider something like `inout`. It is a very look feature to address an
issue specific to D and it looked perfectly reasonable when it was
introduces. And right now there are some fishy hacks about it even in
Phobos (like forced inout delegates in traits) that did come from
originally unexpected usage cases. It is quite likely that re-designing
it from scratch based on existing field experience would have yielded
better results.


No doubt its design could be done better. But inout was not motivated 
theoretically. It came from the practical need of not duplicating code 
over qualifiers.



Policy-based design is more than one decade old, and older under other
guises. Reference counting is many decades old. Both have been
humongous success stories for C++.


Probably I have missed the point where new proposal was added but
original one was not using true policy-based design but set of enum
flags instead (no way to use user-defined policy).


Sean proposed that. In fact that's a very good success story of sharing 
stuff for discussion sooner rather than later: he answered a Request For 
Comments with a great comment.



Reference counting
experience I am aware of shows that it is both successful in some cases
and unapplicable for the others. But I don't know of any field
experience that shows that chosing between RC and GC as a policy is a
good/sufficient tool to minimize garbage creation in libraries - real
issue we need to solve that original proposal does not mention at all.


That's totally fine. A good design can always add a few innovation on 
top of known territory. In fact we've done some experimenting at 
Facebook with fully collected PHP (currently it's reference counted). RC 
is well understood as an alternative/complement of tracing. Anyhow, 
discussion is what the Request For Comments is good for. But please 
let's focus on actionable stuff. I can't act on vague doubts.



No need to trust me or anyone, but at some point decisions will be
made. Most decis

Re: What are the worst parts of D?

2014-10-06 Thread eles via Digitalmars-d
On Monday, 6 October 2014 at 13:42:35 UTC, Andrei Alexandrescu 
wrote:

On 10/5/14, 11:23 PM, eles wrote:
On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu 
wrote:

On 10/5/14, 3:08 PM, eles wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


It doesn't because they need to be allocated dynamically. 
That's why there's a need for the likes of unique_ptr and 
shared_ptr in C++.


Yes, or that delete. And AFAIS not only C++ needs unique_ptr and 
shared_ptr, this ARC thing is the same in D.




The intermediate type between struct and class is struct.


D with classes, anyone?


Re: What are the worst parts of D?

2014-10-06 Thread ketmar via Digitalmars-d
On Mon, 06 Oct 2014 08:39:54 -0700
Andrei Alexandrescu via Digitalmars-d 
wrote:

> I appeal to you and others to keep language and attitude in check.
i'm doing my best, rewriting my posts at least three times before
sending. i bet noone wants to read the first variants. ;-)

but this thread is a good place to show some emotions. i believe that
we need such "emotional ranting" threads, so people can scream here and
then calm down. sure it's very flammable; we must keep fire
extinguishers at hand. ;-)


signature.asc
Description: PGP signature


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 8:08 AM, Joakim wrote:

You and Walter do a good job of answering questions on Reddit and
there's certainly a lot of discussion on the forum where the two of you
chip in, but what's missing is a high-level overview of the co-BDFLs'
priorities for where the language is going, including a list of features
you'd like to see added, ie that are pre-approved (that doesn't mean
_any_ implementation would be approved, only that feature in principle).


Aye, something like that might be helpful. I'll keep it in mind.


Most users or wannabe contributors aren't going to go deep-diving
through the forums for such direction.


I'm not so sure that's a problem. It takes some connection to the 
language milieu before making a major contribution of the kind to be on 
a "vision" list. And once that connection is present, it's rather clear 
what the issues are. That's the case for any language.



Manu and others recently wrote
that the traffic on the forum has gone up, making it tougher for them to
keep up.


Yah, there's been some growing pains. Traffic is on the rise and 
unfortunately the signal to noise ratio isn't.


Converting the existing passion and sentiment into workable items is a 
present challenge I'm thinking of ways to approach.



It would help if the two co-BFDLs did a better job
articulating and communicating their vision in a public place, like a
page on the wiki or dlang.org website, rather than buried in the
haystack of the forums or reddit.


That's sensible.


Andrei



Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 8:35 AM, ketmar via Digitalmars-d wrote:

On Mon, 06 Oct 2014 15:22:17 +
Joakim via Digitalmars-d  wrote:


People in this thread are emotional because they care

yes. i don't think that anybody (including me ;-) wants to
directly insult someone here.


I appeal to you and others to keep language and attitude in check. We 
all are well intended here, all we need to do is convert heat into work, 
which should be possible per the first and second principle of 
thermodynamics. All we need is some cooling :o).


Andrei



Re: What are the worst parts of D?

2014-10-06 Thread ketmar via Digitalmars-d
On Mon, 06 Oct 2014 15:22:17 +
Joakim via Digitalmars-d  wrote:

> People in this thread are emotional because they care
yes. i don't think that anybody (including me ;-) wants to
directly insult someone here. D is good, that's why "not-so-good"
features are so annoying that we are writing such emotional postings.


signature.asc
Description: PGP signature


Re: What are the worst parts of D?

2014-10-06 Thread Joakim via Digitalmars-d

On Monday, 6 October 2014 at 15:13:59 UTC, Nicolas F. wrote:
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja 
wrote:



What do you think are the worst parts of D?


The fact that its community, when faced with the question "What 
do you think are the worst parts of D?", will readily have a 35 
page verbal fistfight over what the worst parts of D are.


Don't get me wrong, I'm happy that discussion is happening 
about such things, but I think it may be better to have it in a 
more structured manner in the future, and with a little less 
emotional investment.


Heh, I think such self-criticism by the community is great, for 
example, I loved that I recently stumbled across this page on the 
wiki:


http://wiki.dlang.org/Language_issues

How many other languages can boast such a page of problems on 
their own wiki? :) Thanks to Vlad and Mike for writing it.


People in this thread are emotional because they care: I don't 
think it's gone overboard given the real concerns they're 
stating.  When the D community starts hiding its problems and 
stops critiquing its own efforts, sometimes passionately if 
that's what you truly feel, is when it starts going downhill.


Re: What are the worst parts of D?

2014-10-06 Thread Nicolas F. via Digitalmars-d

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:


What do you think are the worst parts of D?


The fact that its community, when faced with the question "What 
do you think are the worst parts of D?", will readily have a 35 
page verbal fistfight over what the worst parts of D are.


Don't get me wrong, I'm happy that discussion is happening about 
such things, but I think it may be better to have it in a more 
structured manner in the future, and with a little less emotional 
investment.


That being said, the second worst part of D for me is the current 
state of documentation, which is something that is often 
mentioned. I'd be happy to take part in a "docs initiative" where 
some of us sit together and talk about how we can improve the 
documentation of the language, collect input from outside, and 
then implement the changes that are found to be necessary. This 
would make it easier for people who don't wish to set up the 
entire build environment for the documentation on their side to 
participate in documentation adjustments by giving feedback, 
while a somewhat dedicated group of people then focus on making 
decisions reality.


Re: What are the worst parts of D?

2014-10-06 Thread Joakim via Digitalmars-d
On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 5:42 AM, Wyatt wrote:

On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:


No need to explain it here. When I speak about vision I mean 
something
that anyone coming to dlang.org page or GitHub repo sees. 
Something
that is explained in a bit more details, possibly with code 
examples.
I know I am asking much but seeing quick reference for 
"imagine this
stuff is implemented, this is how your program code will be 
affected

and this is why it is a good thing" could have been huge deal.



Right now your rationales get lost in forum discussion threads


Jerry Christmas, this right here!  Andrei, I know you keep 
chanting "C++
and GC", and that's cool and all, but its also kind of 
meaningless

because we can't read minds.


I understand. What would be a good venue for discussing such 
topics? I thought the D language forum would be most 
appropriate. -- Andrei


Answer:

On Friday, 26 September 2014 at 10:22:50 UTC, Joakim wrote:
It needs to be a page on the wiki or the main site, which you 
or any user can link to anytime people want to know the plan.


some sort of public plan of where you want the language to go.  
All I'm asking for is a public list of preapproved and maybe 
rejected features that the two of you maintain.  Dfix might be 
on the preapproved list, ARC might be on the rejected. ;) You 
could also outline broad priorities like C++ support or GC 
improvement on such a webpage.


You and Walter do a good job of answering questions on Reddit and 
there's certainly a lot of discussion on the forum where the two 
of you chip in, but what's missing is a high-level overview of 
the co-BDFLs' priorities for where the language is going, 
including a list of features you'd like to see added, ie that are 
pre-approved (that doesn't mean _any_ implementation would be 
approved, only that feature in principle).


Most users or wannabe contributors aren't going to go deep-diving 
through the forums for such direction.  Manu and others recently 
wrote that the traffic on the forum has gone up, making it 
tougher for them to keep up.  It would help if the two co-BFDLs 
did a better job articulating and communicating their vision in a 
public place, like a page on the wiki or dlang.org website, 
rather than buried in the haystack of the forums or reddit.


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 7:36 AM, Wyatt wrote:

To be succinct: how about an article?


An article would be great once we have done something we can show.


We're not asking for a discussion in this case so much as some frank
sharing.


Is there anything dishonest about sharing intent about the D programming 
language in the public forum of the D programming language?



D is going to have C++ support.  That's cool and compelling as
a bare statement, but in what manner?


We don't know yet, we're designing it - to wit, we're looking for help 
regarding exception interoperability.



What kinds of things will this
allow that were impossible before?


The exact list is in the air. We're looking e.g. for the best policy on 
exceptions. Possible vs. impossible is btw a matter of scale, for 
example wrapping everything you need from C++ in C functions is possible 
in the small but impossible at scale.



How, specifically, do you envision
that to look?


What is "that"?


Can you give example code that you would expect to work
when it's "done"?


This was discussed already: we should be able to pass an 
std::vector by reference/pointer from C++ into D and use it within 
D directly, with no intervening marshaling.



What are the drawbacks you believe forward engineers
will have to watch out for?


What's a forward engineer?


It's okay to not have all the answers and
explain that there are parts that may not make it because of various
reasons.

I somewhat feel that you're approaching this situation as if it that
were all quite obvious.  Maybe it is to you?  I don't know. But I do
know I'm not alone in the dark here.  Please bring a lamp.


It seems this is a simple misunderstanding. You're looking for a 
virtually finished product (article documenting how it works; analysis; 
design; projected impact) whereas we're very much at the beginning of 
all that. What's clear to me is we need better interop with C++, so I've 
put that up for discussion as soon as reasonable. You're asking for 
things that are months into the future.



Andrei



Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 7:05 AM, Paolo Invernizzi wrote:

On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu wrote:

On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


TDPL was an absolutely awesome book because it expained "why?" as
opposed to "how?". Such insight into language authors rationale is
incredibly helpful for long-term contribution. Unfortunately, it
didn't cover all parts of the language and many new things has been
added since it was out.



I would also add that it's scaring not having seen a single comment of
Andrej here:
https://github.com/D-Programming-Language/dmd/pull/3998


I did comment in this group. -- Andrei


I'm missing something? If you are _only_ meaning that one [1] I keep
being scared ;-)
No pun intended, really.

http://forum.dlang.org/thread/mxpfzghydhirdtltm...@forum.dlang.org?page=3#post-lvhoic:2421o4:241:40digitalmars.com


I understand the necessity for further scrutiny of that work. Even 
before that I owe Sönke Ludwig a review for std.data.json. There's a 
large list of things I need to do at work, mostly D-related, not all of 
which I am not at liberty to make public. On top of that I have of 
course other obligations to tend to.


To interpret my lack of time politically is really amusing. You guys 
have too much time on your hands :o).



Andrei



Re: What are the worst parts of D?

2014-10-06 Thread Wyatt via Digitalmars-d
On Monday, 6 October 2014 at 13:54:05 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 5:42 AM, Wyatt wrote:

On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:


No need to explain it here. When I speak about vision I mean 
something
that anyone coming to dlang.org page or GitHub repo sees. 
Something
that is explained in a bit more details, possibly with code 
examples.
I know I am asking much but seeing quick reference for 
"imagine this
stuff is implemented, this is how your program code will be 
affected

and this is why it is a good thing" could have been huge deal.



Right now your rationales get lost in forum discussion threads


Jerry Christmas, this right here!  Andrei, I know you keep 
chanting "C++
and GC", and that's cool and all, but its also kind of 
meaningless

because we can't read minds.


I understand. What would be a good venue for discussing such 
topics? I thought the D language forum would be most 
appropriate. -- Andrei


Sure, the newsgroup is a great place to discuss the minutiae of 
specific features and figure out how they might be implemented 
and what design tradeoffs need to be made.  I think we've shown 
we can disagree about the colour of any bikeshed of any shape and 
construction at this point!


But in what venue do you feel comfortable holding the 
easily-accessible public record of your intent for C++ support so 
anyone wondering about this new mantra can get the summary of 
what it means for them _as an end user_ without scouring the NG 
and partially-piecing-it-together-but-not-really from a dozen 
disparate posts?


To be succinct: how about an article?

We're not asking for a discussion in this case so much as some 
frank sharing.  D is going to have C++ support.  That's cool and 
compelling as a bare statement, but in what manner?  What kinds 
of things will this allow that were impossible before?  How, 
specifically, do you envision that to look?  Can you give example 
code that you would expect to work when it's "done"?  What are 
the drawbacks you believe forward engineers will have to watch 
out for?  It's okay to not have all the answers and explain that 
there are parts that may not make it because of various reasons.


I somewhat feel that you're approaching this situation as if it 
that were all quite obvious.  Maybe it is to you?  I don't know.  
But I do know I'm not alone in the dark here.  Please bring a 
lamp.


-Wyatt


Re: What are the worst parts of D?

2014-10-06 Thread Paolo Invernizzi via Digitalmars-d
On Monday, 6 October 2014 at 13:49:15 UTC, Andrei Alexandrescu 
wrote:

On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


TDPL was an absolutely awesome book because it expained 
"why?" as
opposed to "how?". Such insight into language authors 
rationale is
incredibly helpful for long-term contribution. Unfortunately, 
it
didn't cover all parts of the language and many new things 
has been

added since it was out.



I would also add that it's scaring not having seen a single 
comment of

Andrej here:
https://github.com/D-Programming-Language/dmd/pull/3998


I did comment in this group. -- Andrei


I'm missing something? If you are _only_ meaning that one [1] I 
keep being scared ;-)

No pun intended, really.

http://forum.dlang.org/thread/mxpfzghydhirdtltm...@forum.dlang.org?page=3#post-lvhoic:2421o4:241:40digitalmars.com

---
/Paolo




Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 12:44 AM, Paolo Invernizzi wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


TDPL was an absolutely awesome book because it expained "why?" as
opposed to "how?". Such insight into language authors rationale is
incredibly helpful for long-term contribution. Unfortunately, it
didn't cover all parts of the language and many new things has been
added since it was out.



I would also add that it's scaring not having seen a single comment of
Andrej here:
https://github.com/D-Programming-Language/dmd/pull/3998


I did comment in this group. -- Andrei



Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 6:18 AM, ketmar via Digitalmars-d wrote:

and now for multiple "alias this"... as you can see this will not help
c++ interop, and it will not help gc, so it can lay rotting on github.
not a word, not even "will not accept this" or "it's interesting, please
keep it up-to-date while you can, we are little busy right now, but
will look at it later". second-class citizens will not run away.


We will accept multiple "alias this". -- Andrei


Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/6/14, 5:42 AM, Wyatt wrote:

On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:


No need to explain it here. When I speak about vision I mean something
that anyone coming to dlang.org page or GitHub repo sees. Something
that is explained in a bit more details, possibly with code examples.
I know I am asking much but seeing quick reference for "imagine this
stuff is implemented, this is how your program code will be affected
and this is why it is a good thing" could have been huge deal.



Right now your rationales get lost in forum discussion threads


Jerry Christmas, this right here!  Andrei, I know you keep chanting "C++
and GC", and that's cool and all, but its also kind of meaningless
because we can't read minds.


I understand. What would be a good venue for discussing such topics? I 
thought the D language forum would be most appropriate. -- Andrei




Re: What are the worst parts of D?

2014-10-06 Thread Andrei Alexandrescu via Digitalmars-d

On 10/5/14, 11:23 PM, eles wrote:

On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu wrote:

On 10/5/14, 3:08 PM, eles wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:



The main distinction between structs and classes in D is the former
are monomorphic value types and the later are polymorphic reference
types. -- Andrei


Why hack them with scoped? The need exists, since you provide a hack for
it.

Reference classes in C++ are polymorphic & reference, but their
destructor/disposer gets called.


It doesn't because they need to be allocated dynamically. That's why 
there's a need for the likes of unique_ptr and shared_ptr in C++.



There is a delete that triggers that or a smart pointer. I don't care if
the delete or the destructor really frees the memory, but I would like
it to get called, to release other resources that the object might have
locked and to mark the object as "invalid". Later access to it shall
triger an exception: "invalidObject".

Call it dispose if you like, because delete is too much like freeing
memory.

Is there an intermediate type between structs and classes?


The intermediate type between struct and class is struct.


Andrei



Re: What are the worst parts of D?

2014-10-06 Thread ketmar via Digitalmars-d
On Mon, 06 Oct 2014 12:48:28 +
Meta via Digitalmars-d  wrote:

> On Monday, 6 October 2014 at 07:51:41 UTC, ketmar via 
> Digitalmars-d wrote:
> > On Mon, 06 Oct 2014 07:44:56 +
> > Paolo Invernizzi via Digitalmars-d 
> >  wrote:
> >
> >> I would also add that it's scaring not having seen a single 
> >> comment of Andrej here:
> >> https://github.com/D-Programming-Language/dmd/pull/3998
> > it's not about c++ interop or gc, so it can wait. existing D 
> > users will
> > not run away, they are used to be second-class citizens.
> 
> That's a bit unfair of you.

that's what i see. even when people praying for breaking their code to
fix some quirks in language, the answer is "NO". why no? 'cause
some hermit living in far outlands may wrote some code years ago and
that code will break and hermit will be unhappy. unhappiness of active
users doesn't matter.

and about writing autofixing tool... silence is the answer. "so will
you accept that changes if we'll write dfix tool to automatically
fixing source code?" silence. "play your little games, we don't care,
as we don't plan to change that anyway, regardless of the tool
availability".

Walter once said that he is against "dfix", and nothing was changed
since. "ah, maybe, we aren't interested..." there is little motivation
of doing work on "dfix" if it's not endorsed by leading
language developers.

and now for multiple "alias this"... as you can see this will not help
c++ interop, and it will not help gc, so it can lay rotting on github.
not a word, not even "will not accept this" or "it's interesting, please
keep it up-to-date while you can, we are little busy right now, but
will look at it later". second-class citizens will not run away.


signature.asc
Description: PGP signature


Re: What are the worst parts of D?

2014-10-06 Thread Meta via Digitalmars-d
On Monday, 6 October 2014 at 07:51:41 UTC, ketmar via 
Digitalmars-d wrote:

On Mon, 06 Oct 2014 07:44:56 +
Paolo Invernizzi via Digitalmars-d 
 wrote:


I would also add that it's scaring not having seen a single 
comment of Andrej here:

https://github.com/D-Programming-Language/dmd/pull/3998
it's not about c++ interop or gc, so it can wait. existing D 
users will

not run away, they are used to be second-class citizens.


That's a bit unfair of you.


Re: What are the worst parts of D?

2014-10-06 Thread Wyatt via Digitalmars-d

On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:


No need to explain it here. When I speak about vision I mean 
something that anyone coming to dlang.org page or GitHub repo 
sees. Something that is explained in a bit more details, 
possibly with code examples. I know I am asking much but seeing 
quick reference for "imagine this stuff is implemented, this is 
how your program code will be affected and this is why it is a 
good thing" could have been huge deal.



Right now your rationales get lost in forum discussion threads


Jerry Christmas, this right here!  Andrei, I know you keep 
chanting "C++ and GC", and that's cool and all, but its also kind 
of meaningless because we can't read minds.  Judging by the 
recent thread where someone (Ola?) asked what "C++ support" 
actually means and received precisely zero useful guidance, no 
one else does either. (This isn't to say I don't think it's 
important, but the scope of what you're doing right now and how 
it materially helps end users isn't really clear.)



There was a go at properties


SALT.

-Wyatt


Re: What are the worst parts of D?

2014-10-06 Thread Martin Drašar via Digitalmars-d
Dne 6.10.2014 v 12:15 ketmar via Digitalmars-d napsal(a):
> On Mon, 06 Oct 2014 10:22:01 +0200
> Martin Drašar via Digitalmars-d  wrote:
> 
> as i said this is the very first version of cmdcon, not the one i'm
> using now. i'm not able to publish the current version yet.
> 
>> That is, how do you use this console interactively?
>> In your previous mail you wrote that you use a telnet.
>> Do you have another mixin that at some specific point inserts a code
>> that pauses the execution of surrounding code and starts listening
>> for telnet commands?
> it depends of event loop, actually. i have my own event loop code, and
> there is hook for telnet channel. that hook collects line to execute,
> calls cmdcon executor and outputs cmdcon output. maybe i'll publish
> some std.socket-based sample later.
> 
>> Also, how do you make your console work in multithreaded programs?
> you should register only shared and global vars (and i'm really missing
> __trait(isGShared) here!), there is no sense to register thread locals
> in multithreaded program.
> 
> but you can register free functions and execute 'em. that free
> functions should take care of threading.
> 
> really, i have to revisit that code and write some samples. i'll try to
> do that soon. and maybe i'll update public versino of cmdcon a little
> too. ;-)
> 

Ok, thanks for your answers. If you get your code to publishable state,
I am sure a lot of people will be interested.

Cheers,
Martin



smime.p7s
Description: Elektronicky podpis S/MIME


Re: What are the worst parts of D?

2014-10-06 Thread ixid via Digitalmars-d
On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright 
wrote:

On 9/24/2014 7:56 AM, Don wrote:
For example: We agreed *years* ago to remove the NCEG 
operators. Why haven't

they been removed yet?


They do generate a warning if compiled with -w.



What change in particular?
I've got a nasty feeling that you misread what he wrote. Every 
time we say,
"breaking changes are good", you seem to hear "breaking 
changes are bad"!


It would be helpful having a list of what breaking changes you 
had in mind.


Perhaps it would be a good idea to have a themed update? 
Currently you and Andrei are busy with the C++ changes, when that 
is settling down maybe the community could focus on a cleaning 
house update. With clear update themes (which does not preclude 
the usual mixture of things also going on) people can air issues 
and get it ye or nay'd clearly. Combining the previously 
discussed auto-update code tool with a set of breaking changes 
would make sense.


Re: What are the worst parts of D?

2014-10-06 Thread ketmar via Digitalmars-d
On Mon, 06 Oct 2014 10:22:01 +0200
Martin Drašar via Digitalmars-d  wrote:

as i said this is the very first version of cmdcon, not the one i'm
using now. i'm not able to publish the current version yet.

> That is, how do you use this console interactively?
> In your previous mail you wrote that you use a telnet.
> Do you have another mixin that at some specific point inserts a code
> that pauses the execution of surrounding code and starts listening
> for telnet commands?
it depends of event loop, actually. i have my own event loop code, and
there is hook for telnet channel. that hook collects line to execute,
calls cmdcon executor and outputs cmdcon output. maybe i'll publish
some std.socket-based sample later.

> Also, how do you make your console work in multithreaded programs?
you should register only shared and global vars (and i'm really missing
__trait(isGShared) here!), there is no sense to register thread locals
in multithreaded program.

but you can register free functions and execute 'em. that free
functions should take care of threading.

really, i have to revisit that code and write some samples. i'll try to
do that soon. and maybe i'll update public versino of cmdcon a little
too. ;-)


signature.asc
Description: PGP signature


Re: What are the worst parts of D?

2014-10-06 Thread via Digitalmars-d

On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote:
I like the safety that a GC guarantees, but is a too big price 
to

be paid for that...


What if you only had precise GC on class objects and nothing 
else? That believe could be done in a performant manner.




Re: What are the worst parts of D?

2014-10-06 Thread Martin Drašar via Digitalmars-d
Dne 3.10.2014 v 16:42 ketmar via Digitalmars-d napsal(a):
> alas, only very old and rudimentary module is available. basically,
> it's the core of the full-featured console, but... only the core, and
> not very well written. i'm planning to opensource fully working thingy
> with bells and whistles eventually, but can't do it right now. :-(
> 
> anyway, here it is:
> http://repo.or.cz/w/iv.d.git/blob_plain/HEAD:/cmdcon.d
> 
> please note that this is not very well tested. i'm keeping it just for
> nostalgic reasons.
> 
> ah, and you can ignore the license. consider that code as public
> domain/WTFPL.
> 
> there is no struct/class support there, only variables and free
> functions. yet free functions supports various types of arguments and
> understands default agrument values.

Thanks a lot. I just briefly gone through the code and I have a question
about the console use:

That code is able to register functions and variables with some
annotations and execute them by string commands. How do you generally
use it for debugging purposes? That is, how do you use this console
interactively? In your previous mail you wrote that you use a telnet. Do
you have another mixin that at some specific point inserts a code that
pauses the execution of surrounding code and starts listening for telnet
commands?

Also, how do you make your console work in multithreaded programs?

Thanks,
Martin




smime.p7s
Description: Elektronicky podpis S/MIME


Re: What are the worst parts of D?

2014-10-06 Thread eles via Digitalmars-d

On Monday, 6 October 2014 at 06:28:58 UTC, eles wrote:

On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote:

On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
On Monday, 6 October 2014 at 03:48:49 UTC, Andrei 
Alexandrescu wrote:

On 10/5/14, 3:08 PM, eles wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


I like the safety that a GC guarantees, but is a too big price 
to

be paid for that...


Just look at this abomination from here:

http://agilology.blogspot.com/2009/01/why-dispose-is-necessary-and-other.html

sqlConnection.Close();
sqlConnection.Dispose();
sqlConnection = null;

Is this your idea about releasing a resource? Why is this better 
than writing delete/dispose sqlConnection?


If you ask to use structs for RAII, I am afraid that you will 
receive a DFront proposal.


Re: What are the worst parts of D?

2014-10-06 Thread ketmar via Digitalmars-d
On Mon, 06 Oct 2014 07:44:56 +
Paolo Invernizzi via Digitalmars-d  wrote:

> I would also add that it's scaring not having seen a single 
> comment of Andrej here:
> https://github.com/D-Programming-Language/dmd/pull/3998
it's not about c++ interop or gc, so it can wait. existing D users will
not run away, they are used to be second-class citizens.


signature.asc
Description: PGP signature


Re: What are the worst parts of D?

2014-10-06 Thread Paolo Invernizzi via Digitalmars-d

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


TDPL was an absolutely awesome book because it expained "why?" 
as opposed to "how?". Such insight into language authors 
rationale is incredibly helpful for long-term contribution. 
Unfortunately, it didn't cover all parts of the language and 
many new things has been added since it was out.




I would also add that it's scaring not having seen a single 
comment of Andrej here:

https://github.com/D-Programming-Language/dmd/pull/3998

Right now I have no idea where the development is headed and 
what to expect from next few releases. I am not speaking about 
wiki.dlang.org/Agenda but about bigger picture. Unexpected 
focus on C++ support, thread about killing auto-decoding, 
recent ref counting proposal - all this stuff comes from 
language authors but does not feel like a strategic additions. 
It feels like yet another random contribution, no different 
from contribution/idea of any other D user.


+1 on all.


I am disturbed when Andrei comes with proposal that possibly 
affects whole damn Phobos (memeory management flags) and asks 
to trust his experience and authority on topic while rejecting 
patterns that are confirmed to be working well in real 
production projects. Don't get me wrong, I don't doubt Andrei 
authority on memory management topic (it is miles ahead of mine 
at the very least) but I simply don't believe any living person 
in this world can design such big change from scratch without 
some extended feedback from real deployed projects.


+1000

---
/Paolo


Re: What are the worst parts of D?

2014-10-05 Thread eles via Digitalmars-d

On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu 
wrote:

On 10/5/14, 3:08 PM, eles wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


The main distinction between structs and classes in D is the 
former are monomorphic value types and the later are 
polymorphic reference types. -- Andrei


Why hack them with scoped? The need exists, since you provide a 
hack for it.


Reference classes in C++ are polymorphic & reference, but their 
destructor/disposer gets called.


There is a delete that triggers that or a smart pointer. I 
don't care if the delete or the destructor really frees the 
memory, but I would like it to get called, to release other 
resources that the object might have locked and to mark the 
object as "invalid". Later access to it shall triger an 
exception: "invalidObject".


Call it dispose if you like, because delete is too much like 
freeing memory.


Is there an intermediate type between structs and classes?


Form that page again:

"I have found (dislcaimer:  this is my experience, your mileage 
will vary) that because 90% of the time you don't need to worry 
about releasing a resource in C#, it is easy to forget to do a 
"using" the remaining 10%.  In C++ you always need to worry about 
it, which makes it real easy to remember that when obtaining a 
resource make sure you have taken care of its release as well. 
(In essence, make sure it is stored in something whose destructor 
will free it).  I have found this pattern a lot harder to follow 
in C# than in C++.


Having said all that, there is a lot to like about .NET and C# as 
well.  I just personally find that the whole "garbage collector 
saves you" aspect that is pitched in every intro to the language 
I have encountered more of a trap than a salvation."


Re: What are the worst parts of D?

2014-10-05 Thread eles via Digitalmars-d

On Monday, 6 October 2014 at 06:28:02 UTC, eles wrote:

On Monday, 6 October 2014 at 06:23:42 UTC, eles wrote:
On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu 
wrote:

On 10/5/14, 3:08 PM, eles wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


I like the safety that a GC guarantees, but is a too big price to
be paid for that...


Re: What are the worst parts of D?

2014-10-05 Thread eles via Digitalmars-d
On Monday, 6 October 2014 at 03:48:49 UTC, Andrei Alexandrescu 
wrote:

On 10/5/14, 3:08 PM, eles wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


The main distinction between structs and classes in D is the 
former are monomorphic value types and the later are 
polymorphic reference types. -- Andrei


Why hack them with scoped? The need exists, since you provide a 
hack for it.


Reference classes in C++ are polymorphic & reference, but their 
destructor/disposer gets called.


There is a delete that triggers that or a smart pointer. I don't 
care if the delete or the destructor really frees the memory, but 
I would like it to get called, to release other resources that 
the object might have locked and to mark the object as "invalid". 
Later access to it shall triger an exception: "invalidObject".


Call it dispose if you like, because delete is too much like 
freeing memory.


Is there an intermediate type between structs and classes?


Re: What are the worst parts of D?

2014-10-05 Thread Andrei Alexandrescu via Digitalmars-d

On 10/5/14, 3:08 PM, eles wrote:

On Sunday, 5 October 2014 at 14:55:38 UTC, Dicebot wrote:


Right now I have no idea where the development is headed and what to
expect from next few releases. I am not speaking about
wiki.dlang.org/Agenda but about bigger picture. Unexpected focus on
C++ support, thread about killing auto-decoding, recent ref counting
proposal


Just to add more salt:

http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx

Raymond Chen: " When you ask somebody what garbage collection is, the
answer you get is probably going to be something along the lines of
"Garbage collection is when the operating environment automatically
reclaims memory that is no longer being used by the program. It does
this by tracing memory starting from roots to identify which objects are
accessible."

This description confuses the mechanism with the goal. It's like saying
the job of a firefighter is "driving a red truck and spraying water."
That's a description of what a firefighter does, but it misses the point
of the job (namely, putting out fires and, more generally, fire safety).

Garbage collection is simulating a computer with an infinite amount of
memory. The rest is mechanism. And naturally, the mechanism is
"reclaiming memory that the program wouldn't notice went missing." It's
one giant application of the as-if rule."

Interesting, in the comments, the distinction that is made between
finalizers and destructors, even if they happen to have the same syntax,
for example in C# and C++.

For example here:
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx#10047776


I feel difficult to swallow the fact that D classes do not lend
themselves to RAII. While I could accept the memory management could be
left outside RAII, running destructors (or disposers) deterministically
is a must.

I particularily find bad that D recommends using structs to free
resources because the destructor of those is run automatically. Just
look at this example:

http://dlang.org/cpptod.html#raii

struct File
{
 Handle h;

 ~this()
 {
 h.release();
 }
}

void test()
{
 if (...)
 {
 auto f = File();
 ...
 } // f.~this() gets run at closing brace, even if
   // scope was exited via a thrown exception
}

Even if C++ structs are almost the same as classes, the logical solit
between the two is: structs are DATA, classes are BEHAVIOR. I will not
get my head around the fact that I will *recommend* putting methods in a
struct.


The main distinction between structs and classes in D is the former are 
monomorphic value types and the later are polymorphic reference types. 
-- Andrei




Re: What are the worst parts of D?

2014-10-05 Thread eles via Digitalmars-d
On Sunday, 5 October 2014 at 21:59:21 UTC, Ola Fosheim Grøstad 
wrote:

On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
No need to explain it here. When I speak about vision I mean 
something that anyone coming to dlang.org page or GitHub repo 
sees. Something that is explained in a bit more details, 
possibly with code examples. I know I am asking much but 
seeing quick reference for "imagine this stuff is implemented, 
this is how your program code will be affected and this is why 
it is a good thing" could have been huge deal.


Something like this would be nice:

http://golang.org/s/go14gc


(sorry, replying to this answer because is shorter)

Would a strategy where pointers are by default unique, and only 
become shared, weak and naked if explicitely declared as such?


Re: What are the worst parts of D?

2014-10-05 Thread eles via Digitalmars-d

On Sunday, 5 October 2014 at 22:11:38 UTC, eles wrote:
On Sunday, 5 October 2014 at 21:59:21 UTC, Ola Fosheim Grøstad 
wrote:

On Sunday, 5 October 2014 at 16:14:18 UTC, Dicebot wrote:
No need to explain it here. When I speak about vision I mean 
something that anyone coming to dlang.org page or GitHub repo 
sees. Something that is explained in a bit more details, 
possibly with code examples. I know I am asking much but 
seeing quick reference for "imagine this stuff is 
implemented, this is how your program code will be affected 
and this is why it is a good thing" could have been huge deal.


Something like this would be nice:

http://golang.org/s/go14gc


(sorry, replying to this answer because is shorter)

Would a strategy where pointers are by default unique, and only 
become shared, weak and naked if explicitely declared as such?


of course, would it be viable?


  1   2   3   4   5   >