May 06, 2022

On Friday, 6 May 2022 at 22:38:06 UTC, user1234 wrote:

>

On Wednesday, 4 May 2022 at 21:24:40 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 4 May 2022 at 20:48:12 UTC, user1234 wrote:

>

seriously ?

I am interested in the ideas, not really the products. :-) For hobby music I actually am most happy if I get to create all the sounds from scratch using basic math + flangers + reverb, but it is time consuming…

https://www.youtube.com/watch?v=Vkfpi2H8tOE
https://www.youtube.com/watch?v=7liQx92aoKk

https://www.youtube.com/watch?v=BXf1j8Hz2bU
https://www.youtube.com/watch?v=l3QxT-w3WMo

life is so ;)

May 06, 2022
On 5/5/2022 11:18 PM, Patrick Schluter wrote:
> That's the point. It reduces build complexity in a disruptive way.

As someone who used to write C code to generate C code to be compiled into a program, this was all replaced very nicely with CTFE. CTFE is worth it just for that. I sure enjoyed deleting all that stuff. Good riddance.

(The multi-level build process broke many "better make" replacements.)
May 06, 2022
On 5/5/2022 11:57 PM, Siarhei Siamashka wrote:
> My point is that CTFE actually increases the complexity and moves it somewhere else in a somewhat obscure way. It's one of the zillions of extra features that make the language spec bloated and difficult to learn.

Actually, it doesn't add any new syntax. And it removes that peculiar limitation that functions cannot be used to determine enum values. It's more the removal of a compiler limitation than adding a feature.

CTFE in C++ was a new feature, as it (pointlessly) added new syntax with new rules.
May 06, 2022
On 5/6/2022 10:30 AM, Adam D Ruppe wrote:
> http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_02.html


You wrote about new D bug-detecting features not finding bugs in existing code.

This is completely unsurprising. For example, I ran one of those new C++ bug finding scanners over DMD (back when it was still in C++). How many bugs did it find? Zero.

The thing is, the DMD source code was very well tested. The routine coding bugs that caused problems were already fixed.

The bug finding features are for *new* code, so you can find the bugs at compile time when it is much more efficient to fix them.
May 06, 2022
On 5/6/2022 12:26 AM, Araq wrote:
> It was in the Nim(rod) compiler which is a Modula 3 derivate quite early in the project's lifetime, maybe as early as 2004, maybe later, I don't remember. And maybe D had it earlier. However:
> 
> 1. I'm quite sure I didn't copy it from D. Because:
> 2. Nim actually **needs** it because otherwise its AST macro system simply cannot work.
> 

You wrote the Nimrod compiler? I'm impressed!
May 07, 2022

On Saturday, 7 May 2022 at 03:24:37 UTC, Walter Bright wrote:

>

On 5/6/2022 12:26 AM, Araq wrote:

>

It was in the Nim(rod) compiler which is a Modula 3 derivate quite early in the project's lifetime, maybe as early as 2004, maybe later, I don't remember. And maybe D had it earlier. However:

  1. I'm quite sure I didn't copy it from D. Because:
  2. Nim actually needs it because otherwise its AST macro system simply cannot work.

You wrote the Nimrod compiler? I'm impressed!

His project is still alive, but renamed to Nim

It's also competing with D as a do-it-all language, ie, is suitable for high level as well as low level programming

May 07, 2022

On Friday, 6 May 2022 at 23:29:38 UTC, user1234 wrote:

> >

https://www.youtube.com/watch?v=Vkfpi2H8tOE
https://www.youtube.com/watch?v=7liQx92aoKk

https://www.youtube.com/watch?v=BXf1j8Hz2bU
https://www.youtube.com/watch?v=l3QxT-w3WMo

life is so ;)

Thank you for the music! (Abba?)

I once created this simple techno thing in Audacity with all sounds done with math in the builtin language:

https://m.soundcloud.com/bambinella/electro-storm-2013

The editing got tedious, kinda difficult to change your mind, so you better not regret what you started with. The process is fun though.

May 07, 2022
On 5/6/2022 11:59 AM, tastyminerals wrote:
> And I would love D to just `import awesomeClib;`.

That's very much what ImportC is all about.
May 07, 2022
On Fri, May 06, 2022 at 08:10:16PM -0700, Walter Bright via Digitalmars-d wrote: [...]
> (The multi-level build process broke many "better make" replacements.)

IMNSHO, "better make" replacements that cannot handle multi-level builds are not worthy to be considered as "better make", but "worse make". (Including, unfortunately, dub. I've been thinking about how to break dub out of its walled garden, partly to remove this limitation.)


T

-- 
Political correctness: socially-sanctioned hypocrisy.
May 07, 2022

On Friday, 6 May 2022 at 15:27:58 UTC, Ola Fosheim Grøstad wrote:

> >

That doesn't mean if you have a webservice to write, that Go is the "best tool for the job". D could be very well be the "best tool for the job".

D does not have cloud service support as I am aware of. Eco system matters.

It is definitely true that comparing our ecosystem side-by-side with Go or Rust, we lose. Even in general, let alone if considering only the area where Go is presumably the strongest at, web servers.

But I argue that this does not always matter much. When you need a library to do something, it does not matter whether you have 5 or 50 good options. As Guillaume's DIID series shows, D's ecosystem is easily big enough for most purposes. Of course, most purposes != all purposes, but still. If you're compare the languages in something where both D and Go/Rust provide good libraries for, it's the language itself and it's standard library that make most of the difference. Not the ecosystem.

>

Running an on-demand Go service will be much cheaper and responsive (I am talking CPU time).

How you use the networking library or framework is still going to matter more than what it is. Probably a Go web server is faster than a Vibe.D server if both have seen similar optimisation effort. Still, you can always drop to lower level networking APIs if you need more performance than the canonical use of Vibe.D provides. If there is any big language-level advantage in one over the other, it probably weighs more than that performance difference.

OTOH if a feature-rich networking framework is needed instead of just the basic functionality, I can then see the richer ecosystem of Go trumping other considerations.