On 26 May 2015 00:30, "ketmar via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Mon, 25 May 2015 18:34:24 +0200, Iain Buclaw via Digitalmars-d wrote:
>
> > Yes, they do.  The key difference is that GCC doesn't require you to
> > delve into it's backend, as a language implementer, you only need to
> > think of how the code should be represented in it's tree language (ie:
> > http://icps.u-strasbg.fr/~pop/gcc-ast.html) - Because of this, I never
> > need to look at assembly dumps to understand what is going on, only tree
> > dumps,
> > which are handily outputted in a C-style format with
> > -fdump-tree-original=stdout.
>
> yet there are no well-documented samples for GCC, like "let's create a frontend for simple C-like language, step by step" (at least not in the distribution).

There used to be treelang, but nobody maintained it, and it quickly became obsolete.  This is the best small frontend I've come across.

https://github.com/giuseppe/gccbrainfuck

Depending on when you tried your attempt, the response is always going to be , the entry barrier is getting lower every year.

LLVM and GCC are very similar, but where LLVM built it's AST on class hierarchy from the start, due to legacy, GCC achieves the same OO style using unions and accessor macros.  The best documentation for these can be found in the source code (see tree.def and tree.h for all definitions and accessors).

I suspect the most common beginner bugs occurs when using right accessor on the wrong tree causes an ICE at runtime in 'some obscure location'.

Incase you intend to dabble again in the future as more parts move over to C++, so far, RTL, GIMPLE, callgraphs, and almost all synthetic value types have been switched over. When trees finally get shunted across, you'll finally benefit from compile-time verified AST.

> there are none for DMD too, but DMD code can be read and understood enough to work with it. and reading GCC code is out of question, it's way too huge.
>

No one (sane) starts with studying the whole of gcc.  There are only three or four key files that you only need to reference to get off the ground.

> sure, that is not your fault, i'm simply trying to explain why there are almost no people working on GDC. it's just too hard. or it seems to be hard, but without good GCC documentation it's almost the same.

It normally starts with a clean frontend. Currently there are bits and pieces split across the place for GDC.  But at least for the most part, all codegen is done via handy routines that call the correct backend builder for you.  But I'd like to go one better and have these part of the new visitors we are switching to.  Once all code generation for e.g expressions is all encapsulated into a single file, then it's just a case of documentation.

Iain

weaselcat:
"I feel like I could write a book on why I use D, so I'm going to
stop now : )"

Actually, kidding aside, I do believe that it would make sense to collect some personal warts-and-all accounts of the experience of individuals working in academe, the corporate sector, and elsewhere in switching to D.  One can think of it as a Studs Terkel type exercise, or something more like a Stanford case study.  But either way, a narrative is very powerful in making the prospect of switching vivid, because in those little details and with the benefit of the natural coherence to which humans are used to thinking there is power that may supplement a drier, more factual presentation of the benefits of D.  I personally found Don's account at a dconf a year or two back rather powerful.  (Who he was representing helped, but less than one might think).  I would also mention the very good talk by the German games developer whose name I have unfortunately forgotten this second - and in a rush.

There is an empty page here if anyone cares to get the ball rolling.  I'll add something myself when I have time in a few days, but if anyone cares to add their own experience, perhaps that might be of considerable benefit over time:

http://wiki.dlang.org/?title=User_narratives_on_switching_to_D&action=edit&redlink=1


bachmeier:
> I'm not weaselcat, but I'm an academic and I also tried out Rust before using D. I came to the conclusion that there was no way I could ever expect any collaborator to use Rust. The syntax was crazy. The requirement to study memory management issues (something completely irrelevant) before even reading the code was a non-starter. It's just a complicated language that is not suited for the average programmer.

I very much appreciate your taking the time to share your perspective (and I always enjoy reading your posts).  I looked at Rust, but it doesn't address the problems I have, and I find the complexity off-putting.

> D is different. As long as I avoid templates, it's easy to read the code I've written, without any experience with the language.

My own curve has been flattish, up until the point I got to templates, which are a bit more of a challenge.  Until recently the most advanced part of language design I was familiar with was ANSI C prototypes, so it's worse for me than for most others, I suppose!

weaselcat again:

"I truly believe that D is easier to port C code to than C++ because you
can write D in a "cleaned up" C for the most part, and slowly turn it into D whereas C++ is essentially a completely different style".

Yes - exactly what I have found (I don't know C++, although as I learn D it becomes easier to read C++ code).


Thanks for sharing the thoughts.  In a hurry, but I wanted to say something quickly now.

On Sunday, 24 May 2015 at 22:24:40 UTC, Iain Buclaw wrote:
>> The compiler
>> situation feels odd, LDC and GDC have very few contributors despite being
>> better than dmd at optimizing and providing a lot of extra perks

> I find the situation being like at university looking for grants or funding, and constantly being told. 'Oh yes, it is important what you are doing, and you must keep doing it as it is pivotal for future success.  But no, we won't help you.'

I wish I could do something to help, but unfortunately I can't think of much for now.  (C++ coding and learning compiler internals exceeds what's possible as things stand).  If things should take off on the business front, I'll try to help where I can, but that's a matter of a few years in the best case.

Anyway, I very much appreciate the work of you and your colleagues on GDC.

On Tue, 26 May 2015 04:07:40 +0000, weaselcat wrote:

> while I agree with your ideological standpoint on GPL, gcc is virtually inaccessible to anyone who isn't already familiar with the codebase in comparison to llvm. At least it seems gcc is interested in changing this.

funny, that movement in GCC is in major part stimulated by LLVM. and that's why i'm not saying "LLVM must die!" ;-)

On Tue, 26 May 2015 07:43:59 +0200, Iain Buclaw via Digitalmars-d wrote:

> On 26 May 2015 00:30, "ketmar via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:

thank you for the info. ah, if only i have a "time freezing device" to make my days longer... ;-)

On Tue, 26 May 2015 07:43:59 +0200, Iain Buclaw via Digitalmars-d wrote:

p.s.

> I suspect the most common beginner bugs occurs when using right accessor on the wrong tree causes an ICE at runtime in 'some obscure location'.
> 
> Incase you intend to dabble again in the future as more parts move over to C++, so far, RTL, GIMPLE, callgraphs, and almost all synthetic value types have been switched over. When trees finally get shunted across, you'll finally benefit from compile-time verified AST.

that's why i have mixed feelings about C++ code in GCC. although i really like it being "C only", compile-time checking is very valuable.

On Tuesday, 26 May 2015 at 08:35:46 UTC, ketmar wrote:
> On Tue, 26 May 2015 07:43:59 +0200, Iain Buclaw via Digitalmars-d wrote:
>
> p.s.
>
>> I suspect the most common beginner bugs occurs when using right accessor
>> on the wrong tree causes an ICE at runtime in 'some obscure location'.
>> 
>> Incase you intend to dabble again in the future as more parts move over
>> to C++, so far, RTL, GIMPLE, callgraphs, and almost all synthetic value
>> types have been switched over. When trees finally get shunted across,
>> you'll finally benefit from compile-time verified AST.
>
> that's why i have mixed feelings about C++ code in GCC. although i really
> like it being "C only", compile-time checking is very valuable.

just convince the gcc dev team to port it to D ;)

On Sunday, 24 May 2015 at 21:35:13 UTC, bachmeier wrote:
> On Sunday, 24 May 2015 at 20:36:47 UTC, Laeeth Isharc wrote:
>> Without wishing to dwell on the negatives of alternatives, might I ask what made you decide to settle on D?  Do you have collaborators who write code and, if so, how did the discussions with them go about this?  For your use case, what have been the main gains you have seen and how long did it take before these started to come through?
>
> I'm not weaselcat, but I'm an academic and I also tried out Rust before using D. I came to the conclusion that there was no way I could ever expect any collaborator to use Rust. The syntax was crazy. The requirement to study memory management issues (something completely irrelevant) before even reading the code was a non-starter. It's just a complicated language that is not suited for the average programmer.
>
> D is different. As long as I avoid templates, it's easy to read the code I've written, without any experience with the language. I tried C++ (Dirk Eddelbuettel devoted a section of his Rcpp book to an example I contributed), Rust, and Go. The other realistic alternative was Go, but I chose D as a matter of personal preference.

This is an often underestimated aspect. Code that looks clean and pretty makes programming much more enjoyable and thus boosts productivity. If a language is not nice to look at, it puts people off. Not only because it makes code less readable, it is also aesthetically off-putting, which is purely psychological, but real nonetheless. D is quite clean for the most part and you can easily discern the "shape" of a program (even people who've never used D, can make sense of it by looking at it). If a language like Rust introduces convoluted syntax for even the simplest tasks, then it will put people off, both in an aesthetic sense and as far as understanding the code is concerned (not to mention all the typing!). I think this is one of the reasons Python took off. It's nice to look at.

With Go I have the sinking feeling that it won't be able to contend with C++ - or D for that matter. It took off due to Google and a fool-proof, easy-to-use infrastructure. But it is way too limited and limiting to be useful for more sophisticated tasks. Go's core devs even say that they wanted it to be an easy-to-use, middle-of-the-road language for those who work in their code mines, focusing on a high output, and it doesn't matter, if you have to write the same function or for-loop with slight modifications over and over and over again.

Nim looks interesting, though. It combines nice features with Python's cleanliness. It is just this type of language people at universities and "coders-by-accident" love. Ha ha ha.

On Tue, 26 May 2015 10:07:08 +0000, Chris wrote:

> With Go I have the sinking feeling that it won't be able to contend with C++ - or D for that matter. It took off due to Google and a fool-proof, easy-to-use infrastructure. But it is way too limited and limiting to be useful for more sophisticated tasks. Go's core devs even say that they wanted it to be an easy-to-use, middle-of-the-road language for those who work in their code mines, focusing on a high output, and it doesn't matter, if you have to write the same function or for-loop with slight modifications over and over and over again.

and it really doesn't matter... for Rob Pike. he also don't like shared libraries and other bells and whistles. sometimes he is right, but sometimes he is too radical.

Go is a "java from google", aimed to raise a bunch of easily replaceable programmers. so, like java, Go can't be complicated. both Gosling and Pike are highly talented people, and that talent helps them to design dumb languages (which is not as easy as it seems ;-).

On Tue, 26 May 2015 08:45:01 +0000, weaselcat wrote:

>> that's why i have mixed feelings about C++ code in GCC. although i really like it being "C only", compile-time checking is very valuable.
> 
> just convince the gcc dev team to port it to D ;)

ah, that would be *ideal*... but ok, let my Secret Plan work: first they will port GCC to simplified C++, and then... tadam! MagicPort Adjusted, D everywhere, C++-lovers are crying!