digitalmars.D - Found on Medium: Why we chose the D Language and vibe.d
- Joakim (8/8) Dec 18 2018 Written in February, but only saw it now:
- Steven Schveighoffer (10/25) Dec 19 2018 That's the first time I've ever read the argument that D is good for
- H. S. Teoh (21/24) Dec 19 2018 [...]
- jmh530 (4/18) Dec 19 2018 What you really need is a tool that will show you the generated
- drug (2/6) Dec 19 2018 https://dlang.org/changelog/2.084.0.html#debugmixins
- jmh530 (2/8) Dec 19 2018 News to me. Thanks!
- H. S. Teoh (12/24) Dec 19 2018 That would certainly be a useful feature... but OTOH having actual
- bauss (7/31) Dec 19 2018 Pretty much solved in Diamond.
- Steven Schveighoffer (9/45) Dec 20 2018 What are the compile-time penalties for diamond templates? I have to try...
- bauss (12/63) Dec 20 2018 Not a lot I'd say. On my laptop (Nothing fancy, just 4gb ram.) it
- Pjotr Prins (5/27) Dec 19 2018 Interesting company. They should also be on the Dlang.org front
- Seb (3/24) Dec 19 2018 They already are listed on the Orgs using D page:
- AlCaponeJr (17/19) Dec 19 2018 Exactly!
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.
Dec 18 2018
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
Dec 19 2018
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
Dec 19 2018
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.) TWhat 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...
Dec 19 2018
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
Dec 19 2018
jmh530 <john.michael.hall gmail.com> On Wednesday, 19 December 2018 at 21:11:06 UTC, drug wrote:On 20.12.2018 0:01, jmh530 wrote:News to me. Thanks!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
Dec 19 2018
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.
Dec 19 2018
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: [...]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.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
Dec 19 2018
On 12/19/18 5:52 PM, bauss wrote:On Wednesday, 19 December 2018 at 17:42:00 UTC, H. S. Teoh wrote:What are the compile-time penalties for diamond templates? I have to try it one of these days. I think diet templates are great, but the compile-time penalty is so bad. I really think they would be more palatable if they were processed pre-compilation. Parsing and cross-compiling a DSL right in the compiler is a neat trick, but there are certainly better ways to do it than with mixins and CTFE. -SteveOn Wed, Dec 19, 2018 at 10:28:59AM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]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.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
Dec 20 2018
On Thursday, 20 December 2018 at 14:39:32 UTC, Steven Schveighoffer wrote:On 12/19/18 5:52 PM, bauss wrote:Not a lot I'd say. On my laptop (Nothing fancy, just 4gb ram.) it takes under 10 seconds to build the whole Diamond website. First build is always slow though, but after that it's pretty smooth. On my projects I usually don't really wait a lot because while it builds I usually change css etc. so by the time it has built the project I can test it. I'm having some ideas on how to speed it up though by only compiling views that have changed, but it's a little more tricky than it sounds, so right now it's just an idea.On Wednesday, 19 December 2018 at 17:42:00 UTC, H. S. Teoh wrote:What are the compile-time penalties for diamond templates? I have to try it one of these days. I think diet templates are great, but the compile-time penalty is so bad. I really think they would be more palatable if they were processed pre-compilation. Parsing and cross-compiling a DSL right in the compiler is a neat trick, but there are certainly better ways to do it than with mixins and CTFE. -SteveOn Wed, Dec 19, 2018 at 10:28:59AM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]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.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
Dec 20 2018
On Wednesday, 19 December 2018 at 15:28:59 UTC, Steven Schveighoffer wrote:On 12/19/18 2:19 AM, Joakim wrote:Interesting company. They should also be on the Dlang.org front page with a logo.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.Agree.
Dec 19 2018
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:They already are listed on the Orgs using D page: https://dlang.org/orgs-using-d.htmlOn 12/19/18 2:19 AM, Joakim wrote:Interesting company. They should also be on the Dlang.org front page with a logo.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.
Dec 19 2018
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. to program with it, but unfortunately that's not the case, and 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.
Dec 19 2018