Goodbye, Jake. Thank you for your generosity in sharing your struggles, even now as it comes to its end. As a 20-something young man with hopefully many years ahead of me, your posts have encouraged me to live better, love more, and have more appreciation. Take it as some consolation that I and many others will read and reread your writings long after you're gone.
Bess and Athena and all your loved ones are in the intentions of my heart.
I've done this where I use python's ctypes library to write tests for a c codebase. This feels very similar in that it can be tricky to get the type interop correct the first time around. What other strategies/solutions do people like to use for testing their c projects?
Has the way Python handles this changed a lot in the last decades? I have never did it because I feared having to chase changes in Python and an ever changing build environment. Mostly a focus thing I knew I alone would not be the one to fix it across all build envs. At the time I was the lone Pythonista now everyone we hire is comfortable with Python so I made the wrong choice.
I think (but I'm not sure) that in Zig you can just @cInclude("header.h") or something like that? So your C types are automatically imported/converted to Zig types.
In the defense of the SciPy response, while there may be some programming language zealotry behind the position, it seems to be from a lack of expertise in SciPy to maintain its Fortran code that's pushing SciPy to avoid new Fortran additions. Hopefully OP gets PRIMA through! Been admiring this effort, Dr. Zhang.
F2py, which is already a standard part of numpy, does the heaving lifting and generates idiomatic python wrappers for Fortan code.
It's just zealotry of them going "eeew fortran that's like really really old". Fortran got multidimensional dense numeric arrays right. Modern Fortran allows you to do elemental/vectorized operations on them. C does not even come close, and requires tons of preprocessor macros if you try. Every other 'modern' language introduces a bunch of tooling and dependencies just to get where Fortran is, because they just don't have a focus on scientific computing.
> It's just zealotry of them going "eeew fortran that's like really really old".
The developers of SciPy are maintaining a codebase that is 18% fortran, according to [1]. The only language that makes up a larger part of the codebase is python.
Don't you think it's possible their opinion on fortran is actually informed by quite a bit of experience?
I guess one of the major issues is the compilation and packaging of the Fortran code. It is also my experience when developing PDFO ( https://www.pdfo.net/ ), the predecessor of PRIMA.
> The central issue is that their experience with the old Fortran doesn't translate to modern Fortran; they are two different beasts.
This is so true! I hope anyone could spend a few minutes checking what modern Fortran is before blaming it. A good reference is https://fortran-lang.org/en/
As long as PRIMA is maintained (which seems likely independently), it's only the bindings that need to be maintained. And it's trivial to write a Fortran interface in C or C++ (perhaps that can be included in PRIMA anyway) and then SciPy can pretend like it's not Fortran...
What is the reason to not have a central package index? I find that having one speeds up my development significantly. Is there more reason than decentralization?
I'm really not a fan of what has happened in the Rust community with crates.
The fact that there is a single blessed Rust crate source and the fact that the Rust community doesn't take responsibility for vetting crates means that maintainership changes, name squatting gold rush, and a whole host of pathological behaviors show up.
If you're not going to take responsibility, then the only option is to leave everything decentralized.
The biggest issue I can see with this approach is what happens if I’ve made a typo which changes the phonetics of the search input so that it gets excluded by the soundex prefilter, eg typing “Harrinbton” instead of “Harrington”
It doesn't look like it (from what I gather about `use-immer`). What's being suggested is updating React state via a mutable API on the data value itself. `use-immer` wraps the useState/useReducer functional updaters with a call to immer, whereas `use-structure` suggests mutating the data, which is what every React-beginner instinctively tries to do when they first get started with React. Same idea of using Proxies as immer though.
This could be too high level, but I stumbled onto the founder's (crawshaw) website and found one of his blog posts very helpful for understanding basic fundamentals of the product (i.e. Zero Trust networks and microsegmentation)
As long as you stay away from the bridge and the packs of tourists, sure. But I quickly found myself wanting to over the bridge to get different/more challenging routes.
See previous thread: https://news.ycombinator.com/item?id=41058318