November 14, 2017
On Tuesday, 14 November 2017 at 06:11:34 UTC, Fra Mecca wrote:
> On Tuesday, 14 November 2017 at 01:01:16 UTC, codephantom wrote:
>> "C++, Rust, and D have a large number of features and it can be distracting from the actual meaning of the application you are working on. One finds themselves debugging their knowledge of the programming language instead of debugging the application itself."
>
> That is c++. I don't have this problem with D, but Go for sure represent that feeling taken to the extreme

Why Go? The Go semantics are fairly straight forward except their take on "exception handling".

November 14, 2017
On Tuesday, 14 November 2017 at 06:11:34 UTC, Fra Mecca wrote:
> That is c++. I don't have this problem with D, but Go for sure represent that feeling taken to the extreme

I'm not sure i can agree with the comment about go.

if wanted a language I could get my head around, and my only choice was go or d, then I'd go go...without doubt.

don't get me wrong. i love d. it's a refreshing language full off new possibilites.

but at the moment, is seems less like the planet mars, and more like a few galaxies crashing into each other....with the newly formed galaxy still being under construction.

of course, that too would be an exciting thing to observe.

I would expect that the future of D (or future users of D), will need to distill this chaos into something that's a little more managable.

In the mean time, I'll enjoy the chaos...while it lasts :D

c++ however, is like a gigantic black hole...which D too will become, I guess, at some point.

November 14, 2017
On 11/13/2017 8:12 AM, Joakim wrote:
> Probably a good sign that they mention D with C++ and Rust and have looked at D features:
> 
> https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-Already-CPP%2C-D%2C-and-Rust%3F 


Aaannnddd, it's now on reddit:

https://www.reddit.com/r/programming/comments/7cumiy/why_use_zig_when_c_d_and_rust_exist
November 14, 2017
On Tuesday, 14 November 2017 at 01:01:16 UTC, codephantom wrote:
> On Monday, 13 November 2017 at 16:12:42 UTC, Joakim wrote:
>> Probably a good sign that they mention D with C++ and Rust and have looked at D features:
>>
>
> An interesting project.
>
> Some good points made too.
>
> As someone new to D, I think this point stood out the most(for me):
>
> "C++, Rust, and D have a large number of features and it can be distracting from the actual meaning of the application you are working on. One finds themselves debugging their knowledge of the programming language instead of debugging the application itself."

This is pretty much inevitable, since C++, Rust and D all aim at being a general-purpose language. Therefore they must provide solid support for multiple programming paradigms. So there is nothing to prevent a user of any of these languages to use all the features of the language in an incoherent or obfuscated manner.
November 14, 2017
On Monday, 13 November 2017 at 16:30:23 UTC, Jonathan M Davis wrote:
> Glancing over what they say there, it sounds like they're trying to write a better version of C.

More like go with generics.
November 16, 2017
I am surprised C hasn't tried to become a "better C". Add a string datatype (and maybe other datatypes like datetime). Add an array type (static and/or dynamic) that doesn't suffer from "array decay" when passed to a function or returned from a function. Provide an alternative to the ridiculous syntax for declaring a function pointer. And copy the scope() guard from D. They could also add some data structure code to the standard library. Not a lot of changes and suddenly the language is a lot more usable for all those GNU programs (and any like them) that are written in C.
November 16, 2017
On Thursday, 16 November 2017 at 02:48:27 UTC, Tony wrote:
> I am surprised C hasn't tried to become a "better C". Add a string datatype (and maybe other datatypes like datetime). Add an array type (static and/or dynamic) that doesn't suffer from "array decay" when passed to a function or returned from a function. Provide an alternative to the ridiculous syntax for declaring a function pointer. And copy the scope() guard from D. They could also add some data structure code to the standard library. Not a lot of changes and suddenly the language is a lot more usable for all those GNU programs (and any like them) that are written in C.

What I really love about the evolution of C, is that 'it can' resist giving in to those temptations ;-)

I still have 'The C Programming Language' (1988) next to my pc, and I enjoy glancing over it now and then, knowing that everything in it is still valid. ;-)

And anyway, one change..always leads to another..and then another..and then another......

resist! resist!

A better C belongs in a new language.

November 16, 2017
On Thursday, 16 November 2017 at 02:48:27 UTC, Tony wrote:
> I am surprised C hasn't tried to become a "better C".

Most of the people that wanted to work on a spec for a better C has already moved to C++ or other languages. The ones that remain want C to stay simple, but they have added new stuff, even generics:

https://en.wikipedia.org/wiki/C11_(C_standard_revision)

Ola
November 16, 2017
On Tuesday, 14 November 2017 at 01:01:16 UTC, codephantom wrote:
> As someone new to D, I think this point stood out the most(for me):
>
> "C++, Rust, and D have a large number of features and it can be distracting from the actual meaning of the application you are working on. One finds themselves debugging their knowledge of the programming language instead of debugging the application itself."

The best thing about language features, that you don't have to use them. I just very recently started using certain language features (eg. templates, conditional compilation), and for a long time I used it like Java without forcing classes into everything. Often I just don't find a use for them, so I won't make the compiler to do CTFE if it's not needed.
November 17, 2017
On Thursday, 16 November 2017 at 22:58:32 UTC, solidstate1991 wrote:
> Often I just don't find a use for them, so I won't make the compiler to do CTFE if it's not needed.

Why wouldn't you? It gives less overhead at run-time, giving your application better performance.
1 2
Next ›   Last »