www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thanks from a python programmer

reply Chris Piker <chris hoopjump.com> writes:
Hi All

Just wanted to say thanks to the D community for the tools I've 
been using this week to write new utility apps around my old C 
libraries.  For years I've used python as the front end for a 
stream processor I maintain for work (the das2C library on 
github).  I haven't written much D code over the last two years, 
but python's performance was again growing tiresome, so I've come 
back to D for new application level code.  Others on these forums 
have mentioned that a good place to expand D's user base is the 
current crop of python programmers.  At least for folks like me 
who also maintain C libraries for performance, that sounds like a 
great focus area.

The only downsides I've experienced with my current round of D 
programming is that:

A) One of my programs compiles/runs fine under dmd, but the exact 
same code exhibits stack corruption under GDC-10.  (that was an 
interesting debugging session)  I haven't tried it under LDC yet.

B) Current github,master dstep output has an amusing bug where it 
writes some of the header definitions right into the middle of 
the "extern (C)" line at the top.

C) Also dexed has a confusing interface so I've started kicking a 
token monthly donation to it's development.  Maybe others will 
join in as well.

These were all minor issues, dstep especially saved me a TON of 
time.

Take care and I hope you keep up the good work, especially in the 
area of Linux IDE development.
Mar 04
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
 The only downsides I've experienced with my current round of D 
 programming is that:

 A) One of my programs compiles/runs fine under dmd, but the 
 exact same code exhibits stack corruption under GDC-10.  (that 
 was an interesting debugging session)  I haven't tried it under 
 LDC yet.
Hi Chris, Thanks for sharing your experience. Would it be possible to raise a bug report with either a reduced test or steps to reproduce? https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc&component=d&version=10.0 Regards, Iain.
Mar 04
next sibling parent reply Chris Piker <chris hoopjump.com> writes:
On Thursday, 4 March 2021 at 10:20:15 UTC, Iain Buclaw wrote:
 On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
 The only downsides I've experienced with my current round of D 
 programming is that:

 A) One of my programs compiles/runs fine under dmd, but the 
 exact same code exhibits stack corruption under GDC-10.  (that 
 was an interesting debugging session)  I haven't tried it 
 under LDC yet.
Would it be possible to raise a bug report with either a reduced test or steps to reproduce? https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc&component=d&version=10.0
Sure. I can't get to it till this weekend but I'll see if I can create a cut-down test case. The overall program + library set is a bit extensive. Maybe I'm just doing something I'm not supposed to and just getting luck with dmd memory layout. I'm pretty inexperience with D so anything's possible, it might not be a bug in GDC at all. Cheers,
Mar 04
parent reply deadalnix <deadalnix gmail.com> writes:
On Thursday, 4 March 2021 at 10:31:12 UTC, Chris Piker wrote:
 Sure.  I can't get to it till this weekend but I'll see if I 
 can create a cut-down test case.  The overall program + library 
 set is a bit extensive.

 Maybe I'm just doing something I'm not supposed to and just 
 getting luck with dmd memory layout.  I'm pretty inexperience 
 with D so anything's possible, it might not be a bug in GDC at 
 all.

 Cheers,
Dustmite can help you reduce to a simple test case.
Mar 04
parent reply Chris Piker <chris hoopjump.com> writes:
On Thursday, 4 March 2021 at 10:54:24 UTC, deadalnix wrote:
 On Thursday, 4 March 2021 at 10:31:12 UTC, Chris Piker wrote:

 Dustmite can help you reduce to a simple test case.
So this link popped-up in a Google search for "dlang dustmite"... https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/ Whoa, now *that* looks handy. Thanks a lot! I'll take a crack at using dustmite later in the week.
Mar 04
parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 4 March 2021 at 23:38:48 UTC, Chris Piker wrote:
 On Thursday, 4 March 2021 at 10:54:24 UTC, deadalnix wrote:
 On Thursday, 4 March 2021 at 10:31:12 UTC, Chris Piker wrote:

 Dustmite can help you reduce to a simple test case.
So this link popped-up in a Google search for "dlang dustmite"... https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-reduction-tool/ Whoa, now *that* looks handy. Thanks a lot! I'll take a crack at using dustmite later in the week.
It is! Very useful to find simple code sample that reproduce a bug from a large project. You usually end up having to do some manual cleaning after the fact, but it can do 98% of the job. Feel free to ask question if you run into problems using it, many here can help.
Mar 05
prev sibling parent Chris Piker <chris hoopjump.com> writes:
On Thursday, 4 March 2021 at 10:20:15 UTC, Iain Buclaw wrote:
 On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
 The only downsides I've experienced with my current round of D 
 programming is that:

 A) One of my programs compiles/runs fine under dmd, but the 
 exact same code exhibits stack corruption under GDC-10.  (that 
 was an interesting debugging session)  I haven't tried it 
 under LDC yet.
Hi Chris, Thanks for sharing your experience. Would it be possible to raise a bug report with either a reduced test or steps to reproduce? https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc&component=d&version=10.0 Regards, Iain.
Hi Iain To get back to you on the stack corruption issue, I noticed some bugs in a dependency library I wrote in C. I was using my old C library in new ways now that I have D bindings and ended up flushing some bugs out of the woodwork. When I fixed the bugs, the stack corruption issue under GDC disappeared. Not sure why they didn't appear in the DMD binaries, but who knows, vagaries of stack layout I guess. Thanks for the quick reply to my initial message, sorry about the false alarm. Also, appreciate your work on GDC! I wish GDC was included in the package list for CentOS 8 (our production servers) but that's true of many packages that I end up building from source on CentOS. Take Care,
Mar 11
prev sibling next sibling parent reply Curious George <curiousgeorge 12curiousgeorge12.email> writes:
On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
 Hi All

 Just wanted to say thanks to the D community for the tools I've 
 been using this week to write new utility apps around my old C 
 libraries.  For years I've used python as the front end for a 
 stream processor I maintain for work (the das2C library on 
 github).  I haven't written much D code over the last two 
 years, but python's performance was again growing tiresome, so 
 I've come back to D for new application level code.  Others on 
 these forums have mentioned that a good place to expand D's 
 user base is the current crop of python programmers.  At least 
 for folks like me who also maintain C libraries for 
 performance, that sounds like a great focus area.

 [...]
I know this might be construed as rude to say this on D's NG, but have you checked out nim? It has python-like syntax, can compile directly to C, and thus utilize such libraries and code easier than D can. It's also a growing language.
Mar 04
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
 On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
 Hi All

 Just wanted to say thanks to the D community for the tools 
 I've been using this week to write new utility apps around my 
 old C libraries.  For years I've used python as the front end 
 for a stream processor I maintain for work (the das2C library 
 on github).  I haven't written much D code over the last two 
 years, but python's performance was again growing tiresome, so 
 I've come back to D for new application level code.  Others on 
 these forums have mentioned that a good place to expand D's 
 user base is the current crop of python programmers.  At least 
 for folks like me who also maintain C libraries for 
 performance, that sounds like a great focus area.

 [...]
I know this might be construed as rude to say this on D's NG, but have you checked out nim? It has python-like syntax, can compile directly to C, and thus utilize such libraries and code easier than D can. It's also a growing language.
As someone who has been writing Nim for a while, I wouldn't really say that statement is entirely true. The syntax is more familiar and that's probably a big plus, but the experience isn't really better than D imo.
Mar 04
prev sibling next sibling parent Chris Piker <chris hoopjump.com> writes:
On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
 On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:
 
 I know this might be construed as rude to say this on D's NG, 
 but have you checked out nim? It has python-like syntax, can 
 compile directly to C, and thus utilize such libraries and code 
 easier than D can. It's also a growing language.
Thanks for the suggestion, I may check out nim someday. I've already invested time in understanding D to some degree and now have a few production programs written in D, so I think I'll just stick with it unless I hit a show stopper. I'm currently maintaining software written in java, C, D, matlab, IDL, python (probably some more I'm forgetting) and still have to take up julia at some point in the near future. So right now I'm just not up for tackling another language, but good luck to nim. Anything that stops wasting vast amounts of hardware, electricity, and my user's time, gets my vote :) Cheers,
Mar 04
prev sibling next sibling parent reply James Lu <jamtlu gmail.com> writes:
On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
 I know this might be construed as rude to say this on D's NG, 
 but have you checked out nim? It has python-like syntax, can 
 compile directly to C, and thus utilize such libraries and code 
 easier than D can. It's also a growing language.
Python has first-class C integration, and D has first-class extern(C) support.
Mar 04
parent reply mipri <mipri minimaltype.com> writes:
On Friday, 5 March 2021 at 02:13:44 UTC, James Lu wrote:
 On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
 I know this might be construed as rude to say this on D's NG, 
 but have you checked out nim? It has python-like syntax, can 
 compile directly to C, and thus utilize such libraries and 
 code easier than D can. It's also a growing language.
Python has first-class C integration, and D has first-class extern(C) support.
Here's a complete Nim program that prints the max amount of file descriptors that a select() set can have: let FD_SETSIZE {.importc: "FD_SETSIZE", header: "<sys/select.h>".}: cint echo FD_SETSIZE Here's a version that exports a function that returns that value: let FD_SETSIZE* {.importc: "FD_SETSIZE", header: "<sys/select.h>".}: cint proc setsize*: cint {.exportc.} = FD_SETSIZE With this assembly: setsize: endbr64 mov eax,0x400 ret nop WORD PTR [rax+rax*1+0x0] So FD_SETSIZE is 1024 on godbolt.org. There's no 1024 in the Nim, and Nim is not parsing the C headers or anything; it's just deferring the value to C. This is a nice thing you get from a transpiler... which nobody using Nim really exploits, preferring to put a bunch of Nim const definitions with what the C headers have. Anyway, here's some more very uncommon Nim: proc `*`(a: float, b: int64): float = {.emit: [result, " = ", a, " * ", b, ";"].} That's a * operator that literally just returns whatever a*b does with those types in C. That's first class C integration. Here's business class from Zig: const c = cImport({ cDefine("_NO_CRT_STDIO_INLINE", "1"); cInclude("stdio.h"); }); pub fn main() void { _ = c.printf("hello\n"); } This sets a C #define and then includes everything from stdio.h as a struct with #defines as variables, C functions as Zig functions, C #define *macros* also as Zig functions, etc. This time the magic is not from C codegen and deferring the work to a C compiler, but from Zig's compiler properly digesting C's header files. What D has is very fine, but it's general seating. Any language with an FFI at all should be about as capable as D's FFI. The last time I did C FFI with Python it was such a chore that http://swig.org/ happened to pull the Python programmers off the wings and actually into the airplane. I guess it's gotten much better.
Mar 04
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 5 March 2021 at 06:11:33 UTC, mipri wrote:
 On Friday, 5 March 2021 at 02:13:44 UTC, James Lu wrote:
 [...]
Here's a complete Nim program that prints the max amount of file descriptors that a select() set can have: [...]
Have you checked out dpp? https://code.dlang.org/packages/dpp https://wiki.dlang.org/Bindings#Binding_generators
Mar 05
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 5 March 2021 at 06:11:33 UTC, mipri wrote:

 This sets a C #define and then includes everything from stdio.h
 as a struct with #defines as variables, C functions as Zig
 functions, C #define *macros* also as Zig functions, etc. This
 time the magic is not from C codegen and deferring the work to
 a C compiler, but from Zig's compiler properly digesting C's
 header files.
*shrug* I work with C libraries all the time, and while dstep and dpp might not handle everything, the parts they don't are minor.
 What D has is very fine, but it's general seating. Any language
 with an FFI at all should be about as capable as D's FFI.
As far as calling C functions? Of course, but those languages are also as capable as Zig if all you want to do is call functions. If you're talking about C interoperability more generally, you have a strange definition of capable. You can create a D shared library that can be called as if it's a shared C library. You can go further and restrict yourself to betterC mode and then you're basically writing modernized C code that without further modification can be dumped in the middle of an existing C project. I don't think, say, Ruby can do that even though it has an FFI. Then there's the big issue of passing data back and forth. That's a language design issue and D makes it easy.
Mar 05
parent reply mipri <mipri minimaltype.com> writes:
On Friday, 5 March 2021 at 12:21:19 UTC, bachmeier wrote:
 On Friday, 5 March 2021 at 06:11:33 UTC, mipri wrote:

 This sets a C #define and then includes everything from stdio.h
 as a struct with #defines as variables, C functions as Zig
 functions, C #define *macros* also as Zig functions, etc. This
 time the magic is not from C codegen and deferring the work to
 a C compiler, but from Zig's compiler properly digesting C's
 header files.
*shrug* I work with C libraries all the time, and while dstep and dpp might not handle everything, the parts they don't are minor.
 What D has is very fine, but it's general seating. Any language
 with an FFI at all should be about as capable as D's FFI.
As far as calling C functions? Of course, but those languages are also as capable as Zig if all you want to do is call functions. If you're talking about C interoperability more generally, you have a strange definition of capable. You can create a D shared library that can be called as if it's a shared C library. You can go further and restrict yourself to betterC mode and then you're basically writing modernized C code that without further modification can be dumped in the middle of an existing C project. I don't think, say, Ruby can do that even though it has an FFI.
You can absolutely do that with Ruby. You write a library that loads Ruby as a library, then have it run your Ruby code, then export C ABI functions that call into Ruby. It involves writing (or generating) a bunch of C, which is the same on-the-wing experience I referenced above with getting Python to call C libraries. Start with https://stackoverflow.com/questions/2801346/embedding-ruby-calling-a-function-from-c You can do it. The existence of someone who can say "*shrug* I work with C libraries all the time, and while rstep and rpp might not handle everything, the parts they don't are minor." is therefore not impossible. Would that mean that Ruby's a first-class language for writing shared objects? If someone claimed "Ruby has first-class C integration" would you not be able to imagine any more-luxurious seats that a language might have a ticket for?
 Then there's the big issue of passing data back and forth. 
 That's a language design issue and D makes it easy.
Why, what big issue? You *can* pass data back and forth. You *can* even only write in a dialect of Ruby that would have a great deal of sympathy with C and not require as much data conversion, cheaply converting between char*s and UncheckedByteArrays like the 'Native' JVM dialects. You can do it, so it's first class, so it can hardly be improved, and I certainly can't think of any languages that do it better. It's really tiresome to make a point this simple and then still have to explain it. Of course I have a "strange definition of capable" for you when I'm describing features you don't miss because you're satisfied with less features. Airlines generally make passengers walk past first-class to get to their cheaper seating, so you at least don't hear conversations like A: I wish general seating had more comfortable seats. B (defensively): what do you mean? I fly all the time and the seat padding is as good as it gets. They'll even bring little packets of peanuts to you mid-flight! You can't get *that* kind of service elsewhere.
Mar 05
parent reply bachmeier <no spam.net> writes:
On Friday, 5 March 2021 at 16:15:12 UTC, mipri wrote:

 You can absolutely do that with Ruby. You write a library that
 loads Ruby as a library, then have it run your Ruby code, then
 export C ABI functions that call into Ruby. It involves writing
 (or generating) a bunch of C, which is the same on-the-wing
 experience I referenced above with getting Python to call C
 libraries. Start with
 https://stackoverflow.com/questions/2801346/embedding-ruby-calling-a-function-from-c
You're not interested in having a serious conversation (or maybe you don't use D and don't understand how any of this works).
Mar 05
parent reply mipri <mipri minimaltype.com> writes:
On Friday, 5 March 2021 at 17:44:13 UTC, bachmeier wrote:
 You're not interested in having a serious conversation (or 
 maybe you don't use D and don't understand how any of this 
 works).
This is the conversation: Curious George: [Nim] can compile directly to C, and thus utilize such libraries and code easier than D can. James Lu: Python has first-class C integration, and D has first-class extern(C) support. mipri: [These examples from Nim] are first class C integration. What D has is very fine, but it's general seating. [Python] was such a chore that http://swig.org/ happened to pull the Python programmers off the wing bachmeier: [defensive shrugging] mipri: It's really tiresome to make a point this simple and then still have to explain it. bachmeier: [angry mind-reading] There's a communication failure: Curious George likes Nim's C integration, and James Lu doesn't see how it's any better than D's. That's fine: Curious George didn't say much to begin with. It may even be the case that precisely where Curious George actually likes Nim, D *really* is as good, and he's just relaying a general understanding of transpiling benefits. But because there's a communication failure, I stepped in to help: here are some specific things that transpiling lets Nim do, that might make someone prefer it for C integration. My goal wasn't "make everyone use Nim" or "establish that D has terrible FFI"; it was "allow people like James Lu to read statements like Curious George's and understand what might be meant by them, instead of thinking them as merely in error." Now, thanks to you, there is another communication failure. As usual I wasted some time trying to overcome it by strengthening and modulating the signal. But there's nothing I can say that can make you read, or make you think about what you're reading. If someone shuts off their radio, it doesn't matter how clear the radio comms are.
Mar 05
parent James Lu <jamtlu gmail.com> writes:
On Friday, 5 March 2021 at 18:22:31 UTC, mipri wrote:
   James Lu: Python has first-class C integration, and D has
     first-class extern(C) support.

   mipri: [These examples from Nim] are first class C
    integration. What D has is very fine, but it's general 
 seating.
    [Python] was such a chore that http://swig.org/ happened to
    pull the Python programmers off the wing
from ctypes import * sox = cdll.LoadLibrary("libc.so.6") sox.sox_init() No headers required.
Mar 07
prev sibling parent reply Preetpal <preetpal.sohal gmail.com> writes:
On Friday, 5 March 2021 at 06:11:33 UTC, mipri wrote:
 On Friday, 5 March 2021 at 02:13:44 UTC, James Lu wrote:
 On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George 
 wrote:
 I know this might be construed as rude to say this on D's NG, 
 but have you checked out nim? It has python-like syntax, can 
 compile directly to C, and thus utilize such libraries and 
 code easier than D can. It's also a growing language.
Python has first-class C integration, and D has first-class extern(C) support.
Here's a complete Nim program that prints the max amount of file descriptors that a select() set can have: let FD_SETSIZE {.importc: "FD_SETSIZE", header: "<sys/select.h>".}: cint echo FD_SETSIZE Here's a version that exports a function that returns that value: let FD_SETSIZE* {.importc: "FD_SETSIZE", header: "<sys/select.h>".}: cint proc setsize*: cint {.exportc.} = FD_SETSIZE With this assembly: setsize: endbr64 mov eax,0x400 ret nop WORD PTR [rax+rax*1+0x0] So FD_SETSIZE is 1024 on godbolt.org. There's no 1024 in the Nim, and Nim is not parsing the C headers or anything; it's just deferring the value to C. This is a nice thing you get from a transpiler... which nobody using Nim really exploits, preferring to put a bunch of Nim const definitions with what the C headers have. Anyway, here's some more very uncommon Nim: proc `*`(a: float, b: int64): float = {.emit: [result, " = ", a, " * ", b, ";"].} That's a * operator that literally just returns whatever a*b does with those types in C.
I am very skeptical about the usefulness of transpiling in the manner you describe. Can you show some examples of this being used? How is it any different than just generating a header file in an intermediate build step (like how CMAKE can configure a version header file or you could even write a C program to write a header definition file)? Isn't this worse than just re-defining the constant, since now you lose compile time knowledge of what the constant should be?
Mar 06
parent mipri <mipri minimaltype.com> writes:
On Sunday, 7 March 2021 at 04:15:12 UTC, Preetpal wrote:
 Isn't this worse than just re-defining the constant, since now 
 you lose compile time knowledge of what the constant should be?
There are two compilers, and the C one still has knowledge of it, but yes it can't be a const in this case as Nim doesn't know it's a constant, and that's arguably a downside of doing things that way. Another downside is you need to care about another compiler's availability, version, toolchain, etc. Being skeptical is fine; the Nim community also does not really embrace transpilation as a feature, and on older systems I've had an easier time getting D set up than Nim.
 How is it any different than just generating a header file in
 an intermediate build step
Not having to do that is a difference.
Mar 06
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
 I know this might be construed as rude to say this on D's NG, 
 but have you checked out nim? It has python-like syntax, can 
 compile directly to C, and thus utilize such libraries and code 
 easier than D can. It's also a growing language.
I'm going to be honest, I haven't checked Nim in like 4 years or so, so things may have changed quite a bit since then, but last I checked the claim made by it supporters were gross exaggeration, if not outright lies in some cases. I don't think the aggressive over promotion of anything, anywhere, was ever helpful to anyone except people running pump and dump schemes, so I've always wondered what the Nimzoïds are trying to achieve here. This is very annoying and give a very impression of the language and its community, especially when one tries it and see that the picture that is being sold is miles away from the reality of the field.
Mar 05
prev sibling parent Curious George <curiousgeorge 12curiousgeorge12.email> writes:
On Thursday, 4 March 2021 at 20:14:32 UTC, Curious George wrote:
 [...]
I'd like to apologize for my initial post as it wasn't sufficiently substantiated and thus resulted in an argument. Further, I am quite thankful to mipri for not only elaborating on my point, but expressing impressive meditative acumen. In the future, I hope to avoid this and actually defend my positions myself. P.S. I'm mainly a D programming, but I've been looking into nim as of late, and I got a tad excited as one can see. As such, please think poorly of me for that post, but not nim's community.
Mar 06
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On Thursday, 4 March 2021 at 09:57:01 UTC, Chris Piker wrote:

 B) Current github,master dstep output has an amusing bug where 
 it writes some of the header definitions right into the middle 
 of the "extern (C)" line at the top.
Please file an issue on GitHub [1], otherwise it will be difficult for to fix if I don't know about it. Try to include a reduced test case.
 These were all minor issues, dstep especially saved me a TON of 
 time.
That's great to hear. [1] https://github.com/jacob-carlborg/dstep/issues -- /Jacob Carlborg
Mar 05
prev sibling parent reply James Blachly <james.blachly gmail.com> writes:
On 3/4/21 4:57 AM, Chris Piker wrote:
...
 code.  Others on these forums have mentioned that a good place to expand 
 D's user base is the current crop of python programmers.  At least for 
 folks like me who also maintain C libraries for performance, that sounds 
 like a great focus area.
...
 Take care and I hope you keep up the good work, especially in the area 
 of Linux IDE development.
 
Chris, thanks for the note. We found the same: Our computational biology group are all python alumni, and the three of us on the software side have all switched to D. The transition from python was pretty seamless, cognitively, and I would say our overall productivity has gone UP. Still have to use pandas for some dataframe type work, but otherwise, all code is written in D.
Mar 09
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 10 March 2021 at 03:06:40 UTC, James Blachly wrote:
 On 3/4/21 4:57 AM, Chris Piker wrote:
 ...
 code.  Others on these forums have mentioned that a good place 
 to expand D's user base is the current crop of python 
 programmers.  At least for folks like me who also maintain C 
 libraries for performance, that sounds like a great focus area.
...
 Take care and I hope you keep up the good work, especially in 
 the area of Linux IDE development.
 
Chris, thanks for the note. We found the same: Our computational biology group are all python alumni, and the three of us on the software side have all switched to D. The transition from python was pretty seamless, cognitively, and I would say our overall productivity has gone UP. Still have to use pandas for some dataframe type work, but otherwise, all code is written in D.
Yeah, if more people just knew about D. Me and another user converted some python code and got execution time down from hours (stopped the execution after x hours) to under 1 minute (I think it was about 20 seconds on my system iirc). It was a very pleasing experience.
Mar 10
next sibling parent reply Chris Piker <chris hoopjump.com> writes:
On Wednesday, 10 March 2021 at 12:03:05 UTC, Imperatorn wrote:
 On Wednesday, 10 March 2021 at 03:06:40 UTC, James Blachly

 Yeah, if more people just knew about D.
Without a big corporate backer adoption is slow, but I hope the D community just keeps plugging along anyway.
 Me and another user converted some python code and got 
 execution time down from hours (stopped the execution after x 
 hours) to under 1 minute (I think it was about 20 seconds on my 
 system iirc).

 It was a very pleasing experience.
Similar story here. I provide a streaming service for a few space particles and fields research groups. Some of the radio spectrum generators were taking more than 35 minutes to provide a day's worth of data, thus causing client programs to time out. It was frustrating because the FFTs ran in fortran code after all, so python wasn't even doing most of the work. After converting the streamer programs to D, CPU utilization is less than 30% of a single core (even on debug builds on DMD) while maxing out the RAID-5 array. Response time is now less than 18 seconds, which is still long but it's now a hardware limitation, not a software problem. To me D feels like an upgrade, but not a radical break. Both D and python have modules. Associative arrays swap in for dictionaries. Range operations feel like list comprehensions, and I'm sure there are more similarities I've yet to encounter. The learning curve is a bit steep at times, though Ali's book has been very helpful in that regard and the gdc+gdb+ddd stack has provided a reasonable debugging experience so far. Happy Programming,
Mar 11
parent welkam <wwwelkam gmail.com> writes:
On Friday, 12 March 2021 at 07:50:52 UTC, Chris Piker wrote:
 On Wednesday, 10 March 2021 at 12:03:05 UTC, Imperatorn wrote:
 it's now a hardware limitation, not a software problem
I havent seen the data but most measurement data is in narrow range so delta compression could save a lot of space. Just an idea.
Mar 12
prev sibling parent Siemargl <inqnone gmail.com> writes:
On Wednesday, 10 March 2021 at 12:03:05 UTC, Imperatorn wrote:

 Yeah, if more people just knew about D.

 Me and another user converted some python code and got 
 execution time down from hours (stopped the execution after x 
 hours) to under 1 minute (I think it was about 20 seconds on my 
 system iirc).

 It was a very pleasing experience.
It would be great to write a short article on the transition from Python to D, or even a details manual
Mar 12