January 12 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to a11e99z | On Thursday, 11 January 2024 at 17:54:24 UTC, a11e99z wrote: >
If you give up on | |||
January 12 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to zjh | On Friday, 12 January 2024 at 03:06:55 UTC, zjh wrote: >Now with Let | |||
January 12 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to zjh | On Friday, 12 January 2024 at 03:08:25 UTC, zjh wrote: >Let You can even use both | |||
January 12 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to ryuukk_ | On Thursday, 11 January 2024 at 21:52:58 UTC, ryuukk_ wrote: >On Thursday, 11 January 2024 at 17:40:50 UTC, a11e99z wrote: >[...] mistake DMD is D's best asset, provides very fast code compilation, i have tried plenty of language, and it is the main reason why i stick with D, no other language can compete, they all depend on LLVM and go read that if you want to wake up from your disillusion: https://kristoff.it/blog/zig-new-relationship-llvm/ https://github.com/ziglang/zig/issues/16270 TLDR: zig will do like D, and will maintain their own backend, in order to provide faster compilation for their debug builds (and very far in the future, release as well), just like DMD how woken up do you feel now? D is leading in that area, one shall not give it up People are forgetting D has extreme small community, it is very unlikely community can maintain two different compilers (without having compiler bugs). Maybe something in future, but not now. | |||
January 11 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Timon Gehr | On 1/11/2024 1:17 PM, Timon Gehr wrote:
> Walter implementing the previously rejected DIP1027 instead of engaging with Adam's new proposal that addressed DIP1027's shortcomings I think was not a great move, but I understand it is more fun to implement your own idea than to try to understand someone else's.
I wrote a review of Adam's proposal some months back.
| |||
January 11 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 1/11/2024 11:02 PM, Walter Bright wrote:
> On 1/11/2024 1:17 PM, Timon Gehr wrote:
>> Walter implementing the previously rejected DIP1027 instead of engaging with Adam's new proposal that addressed DIP1027's shortcomings I think was not a great move, but I understand it is more fun to implement your own idea than to try to understand someone else's.
>
> I wrote a review of Adam's proposal some months back.
Earlier proposals were also extensively discussed in the n.g., which I participated in.
| |||
January 12 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Hors | On Friday, 12 January 2024 at 06:51:43 UTC, Hors wrote: >On Thursday, 11 January 2024 at 21:52:58 UTC, ryuukk_ wrote: >On Thursday, 11 January 2024 at 17:40:50 UTC, a11e99z wrote: >[...] mistake DMD is D's best asset, provides very fast code compilation, i have tried plenty of language, and it is the main reason why i stick with D, no other language can compete, they all depend on LLVM and go read that if you want to wake up from your disillusion: https://kristoff.it/blog/zig-new-relationship-llvm/ https://github.com/ziglang/zig/issues/16270 TLDR: zig will do like D, and will maintain their own backend, in order to provide faster compilation for their debug builds (and very far in the future, release as well), just like DMD how woken up do you feel now? D is leading in that area, one shall not give it up People are forgetting D has extreme small community, it is very unlikely community can maintain two different compilers (without having compiler bugs). Maybe something in future, but not now. Walter created and maintained DMD by himself at the beginning ... a solo project can archive incredible results sometime, so I won't bet against the success of the fork. There's also the plus that D is really a productive language, hey, I remember the discussion about the opportunity to convert D codebase from C++ to D: "that will turn the compiler into something extremely manageable, that will be D unfair advance over other languages!" | |||
January 12 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Profunctor | On Tuesday, 2 January 2024 at 20:13:59 UTC, Profunctor wrote: >On Tuesday, 2 January 2024 at 17:55:56 UTC, GrimMaple wrote: >
This alone is worth it. I pray for your success in these endeavors. I think the same. This eternal discussion only serves to make many .Net/Java/... programmers feel insecure. If D opted for GC, he should embrace that path from the beginning. If "many" C or C++ programmers were interested in D but did not want to use GC, they are the ones who should have created their own Fork and not the other way around. D had (and has) great qualities to be an efficient "high level" language and that is how I perceived it 20 years ago (comparing it with c#)... I have tried to use it 2 or 3 times professionally and it ended up disappointing me. Each time I return to D I have to "remember" or "learn" again and there is not a toolchain that helps me to "remember" naturally as other languages do (i.e. intellisense system comparable to Java/C#/Scala/... Templates/mixins/compile-time code supposes a real wall hard to cross) And, of course, I always find something annoying (i.e.: https://issues.dlang.org/show_bug.cgi?id=3543 ) that consumes my time until I find it is a bug or an unexpected behavior (like the limitations with UFCS) My conclusion was that D is managed, mainly, by C/C++ developers that really doesn't need to move from C++ to D. Too much C/C++/Rust and not enough Scala/Java/C#/Typescript/... But it's my opinion | |||
January 12 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Max Samukha | On 1/10/2024 5:38 AM, Max Samukha wrote:
> On Tuesday, 9 January 2024 at 21:11:39 UTC, Walter Bright wrote:
>
>> The modern consensus is that iostreams was a misuse of operator overloading.
>
> I don't know where you got the idea that there is a concensus.
I know a number of leaders in the C++ community who have decades of experience with C++.
Everyone thought iostreams was great in the 1980s. The luster of it wore off year by year.
| |||
January 12 Re: We are forking D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Max Samukha | On 1/10/2024 5:38 AM, Max Samukha wrote: > The appeal to aesthetics doesn't work, either. Aesthetics is highly subjective and depends on the environment. Aesthetics based on fashion are highly subjective, sure. There are enduring things of beauty, too. For example, there are ugly airplanes are beautiful ones. The beautiful ones tend to fly better. The lines on a modern airliner are beautiful, and none of it is the result of artists. Speaking as an engineer, there's a consistent correlation between things that are beautiful and things that work well. It's visible everywhere - bridges, ships, turbines, rockets, even clothing. Back when I designed electronic circuits, I laid things out so they'd form neatly arranged patterns. A break in the pattern suggested a mistake. Students who created a circuit that looked like a rat's nest of wires and parts rarely got them to work. So why not programming languages? > In reality, some of your decisions that limit the language in order to impose your aesthetic preferences on the programmer often result in the most unaesthetic hacks I've ever seen. That's correct. The idea is to nudge the programmer to find a better way. For example, version algebra in C is a rich, endless source of bugs and errors, on top of being ugly. There are much better ways to do it in C, but it's just too easy to create the ugly buggy version. | |||
Permalink
Reply
