p0nce

Having maintained both C++ and D for different compilers, it's way easier to do it in D since the front-end features are the same (modulo builtins) and the stdlib is 99% the same.

VisualD if you're accustomed to Visual Studio classic it's pretty much the same.

If you read about diffusion of innovation, there is the classical example that cure for scurvy was known way before being adopted: thttps://web.archive.org/web/20151022041843/http://www.idlewo...

I write D fulltime for my small company, published a framework that 4 other small companies use (or have used). D is really nice for the small ISV, but is also prepared to handle massive codebases (deprecated, packages, gradual typechecks, clear deprecation policies).

Lack of interest maybe? I don't use grep, I use an UI that lets me click and jump to a file. Or the builtin search in my IDE.

I'll join the choir and say to not ever try to become an OpenGL expert. It's deep and kind of useless. First of all, if your application use OpenGL, either:

- you've unlimited resources for testing and vetting drivers, and you're working for huge CAO software that can tell users what to use.

- you don't have huge resources and then your only hope if to use an abstracted API like Skia, GDI, bgfx, IGL, WebGPU, anything other than using OpenGL directly.

It will just never work everywhere if you use OpenGL directly, and you won't be able to debug the driver or find all OS x drivers x GPU combination you need to debug it.

Your OpenGL-specific skills (avoiding driver bugs) will have very little value, but 3D-specific skills could. It's a waste of time that is only rivalled by learning C++. I would concentrate on abstracted API that avoid those driver bugs, or even learning a game engine to stay topdown.

I agree that the balance is way too often shifted in the way of overengineering, probably because of our field being skewed by "higher status" thinking.

While I agree mostly, you can overdo the "grug". For example it is possible to underengineer (underabstract?) a software for years until realizing that simple things are still complicated, and you forget to built good abstractions once the patterns have emerged. If you build abstractions, you need a way to correct them anyway, making breaking changes to their contract.

OK, this was better than expected.

I tried Rust briefly and it had that "Ocaml" feel of solving a puzzle.

Users very rarely vocalize their need for speed and even less their need for simplicity. App size being low might as well be associated with "low-content" so not valuable, a lot of effort to seem less valuable in the end.

It's more that IM and AP are more beginner-level Goa trance and MFG/Bypass Unit/Oforia/Juno/many others are the real OG ;)

Modern remasters are usually unconvincing, but this one was. Also: UX (Ultimate Experience) one of the best in the genre.

Same but 36 and it never really got worse for more than six month (say, if you do exposure to loud sounds). Real minor concern for me.

My neighbour got it from the very first shroom use.

Apps shouldn't be able to "notify" you (by default), in the same way your home appliance are not interrupting you.

D accompanies you from prototype to production (with graduate enforceble constraints) so I find it very flexible and practical, and the highlights of my programming career tend to be in D. If you want native with a joyful creative process, D is a good match.

Same with VAT really. Yet some business just stay there.

Honestly maybe easier to just do it in aseprite, at first it will be daunting but in the end enjoyable.

Twitter doesn't show me the people I follow, and instead show people I "might like", in no particular time order. When I do interact, almost noone of my followers can see my post because I'm not an advertiser / paid user. Same from Facebook. So it's not worth "building an audience" if you can't communicate with it, and your audience can be taken from you at will.

Now I imagine a list of similar personnalities for codebases: 1. The Sand Tower. 2. The Sacred Pile of Poo 3. The closed Clue Shop. 4. For the Family 5. The Spreadsheet 6. The Silent Trainwreck. 7. The Warden 8. Gilga-mesh

What's the downsides? Anyone have used Zig and could report on the good and bad?

Some other languages implemented in D:

- Vox: https://github.com/MrSmith33/vox

- Neat: https://neat-lang.github.io/

- Volt: http://www.volt-lang.org/

> Localizable or customizable keywords/operators.

See lamdu IDE.

> Deep support for an alternative to exceptions using a Failable<TResult, TError> type

See Zig's solution.

Because I'm a sour individual :) did reuse demoscene teachings in homemade post-processing (CPU! thanks to all the in-talk about raytracers being fast on CPU, and well drivers).

Er, we once win a "scene award" with a demo. You are right there was plenty of talented programmers there (and the level has only gone up), but this is also an _art_ scene and to be able to work so long for free on something that won't make any money (and that you can only present at a single event) in the end you need to either have a job developing 3D software, and/or be independently affluent. I was happy to leave the scene quickly as I feel it wasn't very respectful, when you release something you can see your "competitors" send harsh comments and tell you your thing sucks, unlike any other scene (?). This doesn't make sense, when people are in music they don't go around telling other people their music suck. Also, demoscene is pure greenfield, you can learn more working in maintenance programming.

1. Ask people how much they will buy it (with their money), not if it's a good idea. 2. When they don't want to buy, ask why.

> To which I simply don't have an answer.

D does it with gradual deprecation, and not too much at once, it is the best for deprecating stuff (you don't need to fix your code immediately) but there is always a residual complaining from people that assume there will be no work to maintain software. In reality someone maintain your compiler/runtime, and their needs are part of your stack.

So: D is bad because it needs more breakage! But at the same time D is bad because it needs less breakage. Right.

> Fluid layouts and scaffolding.

Short of doing a whole CSS rule engine (best) you can also implement a Flutter-like layout system. It is described well by Flutter documentation and is quite flexible.