I personally won't consider using a language for a meaningful project unless it has a decent debugger, and reasonable refactoring; ie. at least find references & rename.
Beef is building on an IDE, which is a refreshing take, but it's still too early.
D in emacs works very well, but you'll have to put some work into it. Spacemacs (https://www.spacemacs.org/) makes the work a little easier, here's my .spacemacs file if anyone is interested https://gitlab.com/snippets/1942930
Using that .spacemacs file you should be able to launch a fully prepped for D! The only other dependencies are a D compiler and DCD (https://github.com/dlang-community/DCD) built and in your PATH. I'd be happy to answer any questions if something doesn't work.
Other IDEs with a languageserver implementation can make use of DLS https://github.com/d-language-server/dls. VSCode and sublime are two I've had good success with.. but I always end up back with emacs ;)
As for a debugger, you can debug any D program with GDB/LLDB (depending on if you compile with dmd/lcd). Then you can use any graphical debugger that uses gdb. Nemiver is my favorite, then there's a few web based ones that are nice: https://www.gdbgui.com/
https://wiki.dlang.org/Editors
Also had really good luck doing D with Spacemacs, but Spacemacs is a hit or miss to setup for me. Other times I just use Sublime Text for the syntax highlighting.
1. gdc or ldc on Debian. The experience /may/ be different with the dmd repositories, but being external they're of less interest to me.
dman dman
You can also get soft copies (i.e. mobi, pdf) and the docs as part of the d-apt repository for debian.
Depending on the nature of distribution it is probably just in a different package (or the package maintainer needs yelling at).
There's some limited debugging support at the generated C code, but this is not sufficient for me.
There is also a D specific IDE which I can't remember the name of which is probably best if you just want something that works (it's pretty lightweight)
WinRT is a better model. Basically a higher-level ABI.
First there’s PSL ctypes,[1] which is supposedly inferior to cffi to some extent, but hey it comes with your CPython installation, no third-party dep required.
Or you can write a C/C++ extension module.[2] A bit more heavy-handed and there’s a learning curve, but once you’ve done it once or twice it’s really not hard, and it affords you great flexibility.
If ctypes can handle the Windows APIs, then I'm convinced it can handle just about anything.
In the article, I do this:
``` #include "nanomsg/nn.h" #include "nanomsg/pipeline.h" ```
That's it. I don't think the approaches can be compared.
(The other half of the puzzle being a tool called autowrap that wraps the resulting D for consumption by Python.)
I'm not sure whether I personally would ever use this, but it's a very interesting exploration of the subject.
Yep!
> (The other half of the puzzle being a tool called autowrap that wraps the resulting D for consumption by Python.)
Correct.
> I'm not sure whether I personally would ever use this, but it's a very interesting exploration of the subject.
Python was an example. Want to call it from C# instead? Same code. Excel? Same code.
The "code-free" approach here seems to forbid such a fuzzy boundary. Am I wrong?
Does this work for all revisions of C? iirc cffi works for all of c89 and most of c99
Though most of the C code I write can compile as C++ also. Why write in C then? It's still the lingua franca in microcontroller land... Just want to reuse the code on PC and Embedded Linux, and Python makes high-level testing much nicer.
(disclaimer: pybind11 contributor)
Wouldn't Nim and Zig also fit the bill?
I don't know how Zig does it, I'd have to look.
I expand on why dpp is the way it is in my DConf 2019 talk: https://www.youtube.com/watch?v=79COPHF3TnE&t=8s
Also there are very easy ways to create Python modules in Nim:
https://robert-mcdermott.gitlab.io/posts/speeding-up-python-...
Example on wrapping a simple benchmark macro:
- https://github.com/mratsim/weave/blob/052ae40a/experiments/e...
- https://github.com/mratsim/weave/blob/052ae40a/experiments/e...
Kitchen sink languages are my least favorite. Give me something with a tight focus on a problem space.
And there is no one size fits all.
That didn't quite happen.
> How many languages do we need again? Till you eliminate all tradeoffs in a single language, there would be new ones.
I'm curious to see how this D approach compares, both in workload required to expose and use an API, and the flexibility of the end result. There are a lot of quirks and special syntaxes in Cython to allow for not just interop between C and Python, but also writing C in Python-like syntax mixed with actual Python. This is an area I assume this approach would be lacking.
Regardless, as someone who loves mixing C and Python, this is an encouraging reason to look more at D.
I can confirm that Atila is a very lazy man. He's always figuring out ways to have his computer do the work for him. He's so successful at avoiding work, people keep giving him more work to do, making him a very hard working lazy man.
One of my earliest programming mentors mused that the reason I might well become a decent programmer was because I was both extremely stubborn and horrifically lazy. He'd observed that I would re-write code until it was the most efficient possible to automate a needed task that could save me time/effort in the future.
I've always done this using the bundled Python/C integration path, or when there was too much stuff, use swig.
does this without needing a compiler, by parsing the header files and generating the ctypes wrappers