January 14, 2019
On Mon, 14 Jan 2019 21:12:48 +0000, Paul Backus wrote:
> On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote:
>> Is it possible to declare a function whose name is a CTFE computed string?
> 
> Yes, if you do it with a string mixin.

And more simply, you can declare a function with a hard-coded name, then use an alias to expose it under a different name.
January 15, 2019
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote:
> https://youtube.com/watch?v=tcyb1lpEHm0
>
> If nothing else please watch the opening story, it's true and quite funny :o).
>
> Now as to the talk, as you could imagine, it touches on another language as well...
>
>
> Andrei

Awesome talk! As usual.

Regarding this quote: "The ruby guy next to you is writing just as crappy code..."  I don't think that's really correct. The reference is code complete, which is published in 93 (i.e. no java, no ruby, before the stl even?) and i believe (just googled this so may be wrong) the reference in that book is from a 1977 paper on programmer quality and productivity and the 2004 edition of code complete changes the number form 15 to 50 / 1000 to 1 .. 25 / 1000, but references the same paper afaik.

Here's a more recent study: http://rayb.info/uploads/cacm2017-lang.pdf

Here's an article that summarizes it -> https://www.i-programmer.info/news/98-languages/11184-which-languages-are-bug-prone.html

Quote from article:

"The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python.  On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits."

Also this is more anecdotal, but for example going from objective-c to swift, the number of non-application-specific bugs per line (regardless of whether or not that's even a good measure 🤷‍♂️), i feel, has gone down by an exaggerated order of magnitude.

Cheers,
- Ali

January 15, 2019
On Tuesday, 15 January 2019 at 05:18:45 UTC, aliak wrote:
> Quote from article:
>
> "The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python.  On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits."

Does this take into account the experience of the programmers writing in each language? Given their relative popularity, I imagine PHP and Python have many more beginning programmers writing code in them than Haskell and Clojure.
January 15, 2019
On Tuesday, 15 January 2019 at 06:57:28 UTC, Paul Backus wrote:
> On Tuesday, 15 January 2019 at 05:18:45 UTC, aliak wrote:
>> Quote from article:
>>
>> "The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python.  On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits."
>
> Does this take into account the experience of the programmers writing in each language? Given their relative popularity, I imagine PHP and Python have many more beginning programmers writing code in them than Haskell and Clojure.

Not that I saw in the paper no. But that is a good point.
January 15, 2019
On 2019-01-14 23:52, Walter Bright wrote:
> On 1/14/2019 10:49 AM, Jacob Carlborg wrote:
>> But Ddoc has macros ;)
> 
> Indeed it does. But the macros cannot be used to create syntax, and there is no token concatenation. Macros cannot define other macros.
> 

The AST macros I've been talking about have never been able to create new syntax.

-- 
/Jacob Carlborg
January 15, 2019
On Monday, 14 January 2019 at 18:52:02 UTC, Jacob Carlborg wrote:
> On 2019-01-14 15:42, Steven Schveighoffer wrote:
>
>> That's a bad example :) The clear answer is mysql-native, which is what vibe.d recommends.
>
> Exactly, and I don't need five minutes for that. Five seconds is enough :)
Ok, bad example,  but let's say you want ORM mapping, too and to have the ability to switch to Postgres later? So what would you recommend?




January 15, 2019
On 1/15/2019 1:10 AM, Jacob Carlborg wrote:
> The AST macros I've been talking about have never been able to create new syntax.

Template expressions can't, either, but what they do is hijack the syntax for completely different purposes. The poor reader will be looking at code, and it will behave nothing like the syntax suggests.

January 15, 2019
On Monday, 14 January 2019 at 14:59:03 UTC, 12345swordy wrote:
> On Monday, 14 January 2019 at 10:06:48 UTC, Mike Franklin wrote:
>> On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote:
>>
>>> [...]
>>
>> I think D's structs are a sufficient object system for such a focal point.  With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary.  Rust and Zig are pretty good examples of this.
>>
>> D's implementation could even be improved to keep its runtime, yet still allow D to be used as I'm suggesting, without introducing any breakage for anyone.  I made some significant progress in that direction when I was working on the compiler in the 2017~2018 timeframe, but my abilities ultimately fell short, and I couldn't see a way forward without support.
>>
>> Mike
>
> Killing classes will kill my interest and investment in D.
> Alex.

He's not saying "kill classes in D", he's saying an OOP system in D could be implemented from primitives and classes don't need to be a language feature, similar to CLOS in Common Lisp.
January 15, 2019
On Tue, 15 Jan 2019 11:59:58 +0000, Atila Neves wrote:
> He's not saying "kill classes in D", he's saying an OOP system in D could be implemented from primitives and classes don't need to be a language feature, similar to CLOS in Common Lisp.

As long as the syntax and behavior don't change, the error messages are good, and the compile-time overhead is similar, I won't complain.
January 15, 2019
On Tuesday, 15 January 2019 at 11:59:58 UTC, Atila Neves wrote:
> He's not saying "kill classes in D", he's saying an OOP system in D could be implemented from primitives and classes don't need to be a language feature, similar to CLOS in Common Lisp.

For some people writing OOP means writing keyword class.