Written in February, but only saw it now:

https://medium.com/tripaneer-techblog/why-we-chose-the-d-language-and-vibe-d-3684131a71cd

Another D post from that blog:

https://medium.com/tripaneer-techblog/reducing-compilation-times-ca524484beeb

They have several D libraries on github and dub:

https://github.com/ebookingservices

I just sent an email out to Mário about doing an interview for the D blog.

On 12/19/18 2:19 AM, Joakim wrote:
> Written in February, but only saw it now:
> 
> https://medium.com/tripaneer-techblog/why-we-chose-the-d-language-and-vibe-d-3684131a71cd 
> 
> 
> Another D post from that blog:
> 
> https://medium.com/tripaneer-techblog/reducing-compilation-times-ca524484beeb 
> 
> 
> They have several D libraries on github and dub:
> 
> https://github.com/ebookingservices
> 
> I just sent an email out to Mário about doing an interview for the D blog.

That's the first time I've ever read the argument that D is good for hiring people because it's relatively unknown :) It's a good point too, because the exact people who like to learn new things and have new experiences are the types of people I would want to hire.

I'm curious if the author has any words to say on vibe.d compile times. If they value fast compile times over performance, I can't imagine they are using diet templates.

Nice read!

-Steve

On Wed, Dec 19, 2018 at 10:28:59AM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
> I'm curious if the author has any words to say on vibe.d compile times. If they value fast compile times over performance, I can't imagine they are using diet templates.
[...]

Yeah, in my own vibe.d project I eventually separated out diet templates into their own modules that are separated from "business logic". Which I should be doing anyway, I suppose, in the spirit of good software design, but the primary motivation at the time was to keep compilation times under control.

I'm quite tempted to cook up my own HTML generation framework that does codegen as a separate step, using D tools to generate D code, that then gets compiled into the actual executable.  Despite all the power of CTFE and other compile-time features, past a certain level of complexity I really want to physically see the generated code rather than wade through inscrutable templates and mixins and try to imagine in my head what the generated code looks like. (You wouldn't believe it, debugging is SO MUCH easier when you don't have to instantiate templates in your head just to understand what the code is trying to do, but can just look at the actual generated code being fed to the compiler as a file.)


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth

On Wednesday, 19 December 2018 at 15:28:59 UTC, Steven Schveighoffer wrote:
> On 12/19/18 2:19 AM, Joakim wrote:
>> Written in February, but only saw it now:
>> 
>> https://medium.com/tripaneer-techblog/why-we-chose-the-d-language-and-vibe-d-3684131a71cd
>> 
>> 
>> Another D post from that blog:
>> 
>> https://medium.com/tripaneer-techblog/reducing-compilation-times-ca524484beeb
>> 
>> 
>> They have several D libraries on github and dub:
>> 
>> https://github.com/ebookingservices
>> 
>> I just sent an email out to Mário about doing an interview for the D blog.

Interesting company. They should also be on the Dlang.org front page with a logo.

> That's the first time I've ever read the argument that D is good for hiring people because it's relatively unknown :) It's a good point too, because the exact people who like to learn new things and have new experiences are the types of people I would want to hire.

Agree.

On Wednesday, 19 December 2018 at 17:59:41 UTC, Pjotr Prins wrote:
> On Wednesday, 19 December 2018 at 15:28:59 UTC, Steven Schveighoffer wrote:
>> On 12/19/18 2:19 AM, Joakim wrote:
>>> Written in February, but only saw it now:
>>> 
>>> https://medium.com/tripaneer-techblog/why-we-chose-the-d-language-and-vibe-d-3684131a71cd
>>> 
>>> 
>>> Another D post from that blog:
>>> 
>>> https://medium.com/tripaneer-techblog/reducing-compilation-times-ca524484beeb
>>> 
>>> 
>>> They have several D libraries on github and dub:
>>> 
>>> https://github.com/ebookingservices
>>> 
>>> I just sent an email out to Mário about doing an interview for the D blog.
>
> Interesting company. They should also be on the Dlang.org front page with a logo.
>

They already are listed on the Orgs using D page: https://dlang.org/orgs-using-d.html

On Wednesday, 19 December 2018 at 15:28:59 UTC, Steven Schveighoffer wrote:
> because the exact people who like to learn new things and have new experiences are the types of people I would want to hire.

Exactly!

I'm not saying this is true for everyone, but for me in most cases people choose, stay and will die with top known languages because employment and many don't think about expanding  knowledge.

Where I live C# is the hot spot, and suddenly everyone knew how to program with it, but unfortunately that's not the case, and right now I'm seeing/fixing a big C# code base that smells like s***.

I remember a quote from Paul Graham where he said that in 90's while he was developing one of the first web shops (Via Web) in Lisp, he would lose sleep only  when competitors were developing the same thing using Python (Unknown at the time) or any new language.

Al.

On Wednesday, 19 December 2018 at 17:42:00 UTC, H. S. Teoh wrote:
> [snip]
>
> I'm quite tempted to cook up my own HTML generation framework that does codegen as a separate step, using D tools to generate D code, that then gets compiled into the actual executable.  Despite all the power of CTFE and other compile-time features, past a certain level of complexity I really want to physically see the generated code rather than wade through inscrutable templates and mixins and try to imagine in my head what the generated code looks like. (You wouldn't believe it, debugging is SO MUCH easier when you don't have to instantiate templates in your head just to understand what the code is trying to do, but can just look at the actual generated code being fed to the compiler as a file.)
>
>
> T

What you really need is a tool that will show you the generated code from mixins/templates/ctfe for testing purposes. I don't think you're the only one...

On 20.12.2018 0:01, jmh530 wrote:
> 
> What you really need is a tool that will show you the generated code from mixins/templates/ctfe for testing purposes. I don't think you're the only one...

https://dlang.org/changelog/2.084.0.html#debugmixins

On Wed, Dec 19, 2018 at 09:01:36PM +0000, jmh530 via Digitalmars-d wrote:
> On Wednesday, 19 December 2018 at 17:42:00 UTC, H. S. Teoh wrote:
> > [snip]
> > I'm quite tempted to cook up my own HTML generation framework that
> > does codegen as a separate step, using D tools to generate D code,
> > that then gets compiled into the actual executable.  Despite all the
> > power of CTFE and other compile-time features, past a certain level
> > of complexity I really want to physically see the generated code
> > rather than wade through inscrutable templates and mixins and try to
> > imagine in my head what the generated code looks like.
[...]
> What you really need is a tool that will show you the generated code from mixins/templates/ctfe for testing purposes. I don't think you're the only one...

That would certainly be a useful feature... but OTOH having actual codegen outside the compiler gives more flexibility, such as reading (an arbitrary number of) arbitrary data files, performing arbitrarily expensive operations on said data, and emitting code based on said data -- *and* only doing this when the data actually changes, rather than once every compilation, which would quickly become unfeasibly slow, esp. with today's CTFE performance.


T

-- 
The richest man is not he who has the most, but he who needs the least.

On Wednesday, 19 December 2018 at 17:42:00 UTC, H. S. Teoh wrote:
> On Wed, Dec 19, 2018 at 10:28:59AM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
>> I'm curious if the author has any words to say on vibe.d compile times. If they value fast compile times over performance, I can't imagine they are using diet templates.
> [...]
>
> Yeah, in my own vibe.d project I eventually separated out diet templates into their own modules that are separated from "business logic". Which I should be doing anyway, I suppose, in the spirit of good software design, but the primary motivation at the time was to keep compilation times under control.
>
> I'm quite tempted to cook up my own HTML generation framework that does codegen as a separate step, using D tools to generate D code, that then gets compiled into the actual executable.  Despite all the power of CTFE and other compile-time features, past a certain level of complexity I really want to physically see the generated code rather than wade through inscrutable templates and mixins and try to imagine in my head what the generated code looks like. (You wouldn't believe it, debugging is SO MUCH easier when you don't have to instantiate templates in your head just to understand what the code is trying to do, but can just look at the actual generated code being fed to the compiler as a file.)
>
>
> T

Pretty much solved in Diamond.

https://diamondmvc.org/

Basically: https://github.com/DiamondMVC/Diamond/blob/master/app/web.d#L192

viewResult.source is the exact generated source for a specific view.