On Wednesday, 23 November 2022 at 21:17:42 UTC, ryuukk_ wrote:
>Once my game will be at a visually pleasant state, i'll write a proper blog post, i'll prove these people wrong
I’d definitely give that a read. Looking forward to it 👍.
November 23, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to ryuukk_ | On Wednesday, 23 November 2022 at 21:17:42 UTC, ryuukk_ wrote: >Once my game will be at a visually pleasant state, i'll write a proper blog post, i'll prove these people wrong I’d definitely give that a read. Looking forward to it 👍. |
November 23, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to Guillaume Piolat | On Wednesday, 23 November 2022 at 22:07:01 UTC, Guillaume Piolat wrote: >On Wednesday, 23 November 2022 at 17:20:54 UTC, Kyle Ingraham wrote: >I’m super-positive on D but also interested in whether there are others with the same issues as the article’s author. I'm using VisualD and yeah it has become a bit strange over time, with debugging values being shown wrong, it also depends what's your compiler and whether youa re using Mago or isual studio debugger, breakpoints sometimes not triggering unless you rebuild... I'm pretty sure it used to be a bit better. ... but the last thing I would do is rewrite a whole codebase just for such a reason. It's not even clear Jai has a Visual Studio extension at all. When you say ‘shown wrong’ do you mean they’re hard to read (wrong format, mangled names) or that the values are wrong? Do you know if there are bugs reported for that problem? |
November 24, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyle Ingraham | I'm developing my engine literally on Windows since the start, and I'm even doing Xbox development for it, so, I think my experience with D should prove useful. >90% of times, the this pointer is missing or wrong
variables on function stacks are often partially or completely missing or wrong
values of variables are sometimes reported wrong without any other visible issues
static foreach expansions are not handled well and confuse the debugger
mixins (D’s macro equivalent) generate debug info in a way that causes the debugger to not find the correct file (so you step through disassembly)
moving the instruction pointer back to the previous line in visual studio often crashes the program on the next instruction
different compiler phases interact in weird ways that lead to surprises in metaprogramming, while generating misleading errors234
ldc2 is awfully slow to compile5, but sometimes the only choice because dmd has bugs6
D offers a betterC mode that among other things disables garbage collection. However, when using this mode, the standard library does not compile and meta programming7 is significantly hampered.
the documentation is lacking
like order independent declaration in global scopes sometimes breaking with mixins ↩︎
or like namespaced names not resolving in mixins unless you use a special kind of string literal ↩︎
or like static foreach not being able to insert multiple else ifs after an if ↩︎
Summary: Unfortunately, it is sad to see that D is quite in that state on its unique features, like being advertising with CTFE and not being able to actually use CTFE because it can slow the build quite a lot (there was a CTFE cache PR somewhere, saying that it was able to make it build much faster, unfortunately, it didn't go onwards dunno why). Although I would not switch D for another language, I don't completely disagree with what is said in that blog. And that is what I and some other people says: adding new features to D should not be priority n° 1, cuz there is a lot of other broken things over there that just ruins the developer experience. Having a clear and better compilation flow with version/static if/mixin template/mixin, generating better debug information on metaprogramming side (which could also help tooling such as code-d and visual D), and after that, making CTFE faster (or cached) could make D better in what D offers. If you code D like C or Java, you won't have much pain with it, but if you start using mixin template/alias and other features such as that, you'll start to be bitten. |
November 24, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to Hipreme | On Thursday, 24 November 2022 at 11:37:57 UTC, Hipreme wrote: >
This is not a case of "if doesn't work with this normal feature", it's a case of "case is extremely, extremely strange." Case statements work much more like goto labels than statements. For instance, this is valid code:
|
November 24, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to FeepingCreature | On Thursday, 24 November 2022 at 12:04:27 UTC, FeepingCreature wrote: >For instance, this is valid code:
Ie. to explain what's happening here: The syntax tree structure of The syntax tree structure of Instead, it's (All parse rules made up from memory, not taken from the spec.) |
November 24, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyle Ingraham | On Wednesday, 23 November 2022 at 17:20:54 UTC, Kyle Ingraham wrote: >I’m interested in reading your thoughts on the ‘Why not D’ section. Anyone have experiences that match the specific points there? I haven’t experienced them but I also don’t debug on Windows. I also find D’s documentation to be excellent. Does this make sense to anyone without elaboration: >90% of times, the Can't say I've ever noticed anything like that suddenly springing up, certainly not 90% of the time. |
November 24, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyle Ingraham | On Wednesday, 23 November 2022 at 23:44:48 UTC, Kyle Ingraham wrote: >When you say ‘shown wrong’ do you mean they’re hard to read (wrong format, mangled names) or that the values are wrong? Wrong. Do you know if there are bugs reported for that problem? I don't know. When this happen, I change the debugging engine or rebuild, and it makes it work. I also have disabled semantic analysis and completion because it crashed often or took too much memory. |
November 24, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan | On Wednesday, 23 November 2022 at 19:42:22 UTC, Johan wrote: >About the compilation speed, I think the author does not yet realize that you have to think about performance of compile-time execution, similarly as with runtime execution. The algorithm used matters a lot, also at compile time. Spending 60sec on that small of a codebase is not my experience (*), so I think it's just a piece of compile-time code that is consuming most of the time (note that his optimized build only takes 2x longer). I'm very interested in seeing how using Jai turns out for this guy, but I was wondering about this too... Just what kind of code has he been writing to cause D to take a whole minute to compile?? Is he compiling each D file separately? I can understand the rest of his criticisms but I think this problem may be solely his own, even if our CTFE engine and template instantiation isn't the fastest. |
November 25, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyle Ingraham | On Wednesday, 23 November 2022 at 17:20:54 UTC, Kyle Ingraham wrote: > Hi all. I came across this article on Hacker News: https://www.yet-another-blog.com/porting_the_game_to_jai_part0/ > > I’m interested in reading your thoughts on the ‘Why not D’ section. Anyone have experiences that match the specific points there? I haven’t experienced them but I also don’t debug on Windows. I also find D’s documentation to be excellent. That article has an interesting take. It's gripes with D aren't the usual ones, maybe debugging experience excluded. D's documentation is good but not top-notch IMO. It's easy to browse and usually has examples, but still sometimes lacks detail with regards to corner cases. It's still better than most, so I find complaining about that surprising. Compare Phobos docs to [Nix standard API docs](https://nixos.org/manual/nixpkgs/stable/#preface) for instance. At least for me it's far easier to find what I want from Phobos docs, yet even NixPkgs documentation should probably be considered acceptable - at least it is correct and usually covers what you need when you look hard enough. I agree with others here that he must have some problem with the compile time he could solve without switching the language. D usually compiles far faster than C++. It may be because of his memory usage, perhaps that leads to excessive disk swapping. Should be solvable too. |
November 25, 2022 Re: Discussion: Porting 58000 lines of D and C++ to jai, Part 0: Why and How | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dukc | On Friday, 25 November 2022 at 07:31:59 UTC, Dukc wrote:
> I agree with others here that he must have some problem with the compile time he could solve without switching the language. D usually compiles far faster than C++. It may be because of his memory usage, perhaps that leads to excessive disk swapping. Should be solvable too.
D has a tendency to give you lots of features, invite you to commit to them, then punish you somewhere way down the line when you can't back out. For instance, format!`` is very clever, but it's probably not beneficial for compile speed to have thousands of recursive instantiations of the formatting code in the compilation set.
|