philm @ philm @programming.dev

Posts

0

Comments

179

Joined

2 yr. ago

All good, well maybe not exactly the issue: https://github.com/LemmyNet/lemmy/issues/3580 (maybe you find something else there, otherwise, just open an issue there)

Also just discovered via this, that there's already a "Show Read Posts" setting in the settings

Pretty sure, that there's already a github issue on lemmy itself (too lazy currently to search it though)

I don't think this will be a very big issue for the majority of the cases though. As long as it's configurable and not a (very) controversial change. Especially, since I don't think that feature requests on a programming focused community will be that much controversial...

What I have observed so far: I think the maintainers are relatively open to changes (compared to a few other open source repos).

Hmm yeah it probably helps to be able to program functionally (it's basically lambda calculus with lazy sets and a little bit of syntax sugar). NixOS has a little bit of a steeper learning curve. When understanding Nix itself and having a little bit dived into the the nixpkgs repo you'll quickly get a grip for it (and understand some of the IMHO quirky design decisions).

But then I feel it's only going to get better, as the system can be perfectly configured to your liking and it stays like that across different machines etc. I think the initial investment has paid off for me so far. It's really hackable and you can quickly try ideas without having to fear to break your system. Also something like nix flakes for good reproducible dependency management across different OS is really nice (at least if not much if any GUI is involved, then the different worlds (impure vs pure) sometimes clash together).

You might want to checkout NixOS (or home-manager if you don't want a cold deep dive into a rabbit-hole).

Depends on what you mean exactly with "file format".

If declarative functional programming falls under that, I think something like Nickel, the already mentioned Dhall or Nix. Though Nix more so for packaging and some kind of system management (NixOS?), it's not easily embeddable into a runtime (your app?). Nickel or Dhall is better for that, as they are built from ground up with that in mind, Nickel is maybe the successor of Nix as it is inspired by Dhall and Nix (one goal is to use Nickel as frontend).

The reason why I recommend a simple declarative language, is that they are IMHO much better composable as it lets the user hide boilerplate via functions. I almost always feel limited by static configuration formats like yaml, json etc..

Is this a hard error? Like it doesn't compile at all?

Isn't there something like #[allow(unused)] in Rust you can put over the declaration?

Is it good technically though? Or is it just really popular because it's so well maintained and extensible?

I think the main reason vscode is so popular is, because there aren't really good native alternatives (e.g. I wouldn't compare e.g. vim because it's kind of a different target audience).

So maybe something like zed or so will take the reign of this class of editors, but we'll see, I just hope it's not yet another electron or DOM based editor, DOM is bad enough in the web already...

So cancer + a different form of cancer = ...?

I really don't get why you want an editor to be based on DOM, it feels just like sluggish ... cancer...

Or in other words, you can already try it, it's open source: https://github.com/pop-os/cosmic-epoch

When it's ready...

Hmm pretty sure, it's not vim, as that would be u and C-r

(Nor anything else...)

Yes agree, I need unsafe super rarely, and often it's just for small optimizations (like std::mem::transmute::(kind) where SyntaxKind is an enum with #[repr(u16)]).

But I guess it depends on what you're doing exactly though (the higher-level, the less unsafe you need).

Also checkout https://doc.rust-lang.org/rust-by-example/. It often goes a little bit more into actual detailed code examples and often contains stuff that isn't in the book. Basics are well explained in the book though (like lifetimes)

implement object oriented programming in C is kind of absurd

Well IMHO OOP or specifically inheritance in general is absurd (hard take I know, I have had my traumatic experiences with inheritance hierarchies and refactoring/maintaining them - hell...).

I have done that (vtable OOP emulation in C) in my early years as CS student (like hmm I think 10 years ago?). It was fun experimenting with it, but ultimately I think C should be done imperative/procedural and modular composition of functions, and as such expose an API that is based on that.

I do for my GUI Toolkit written in C

Funny, I'm currently contributing to something similar in Rust :). Recently it also came up how to achieve cross-language bindings, Raph did prototyping for python a year ago in https://github.com/linebender/druid/tree/idiopath_py

I don't think I would go an inheritance based route for a GUI toolkit/framework. Inheritance was IMHO generally a mistake in programming paradigms (at least this strong integration/promotion in most modern languages), too strong interconnected dependencies where they don't make sense and constantly shoot you in the feet.

I think in times where React, Flutter, Jetpack Compose and SwiftUI etc. dominate (IMHO for a good reason), I would go into the direction of composable and declarative reactive UI. Make widgets strongly configurable on a fine-grained basis, and offer high-level bindings, but don't offer more. In case that is an issue, I'd extend the core or maybe offer a way to natively extend the toolkit (e.g. because of performance, better integration/architecture/maintainability etc.)).

Sure, but I think it's rather shows the shortcomings of C IMO, I could write C like Rust (no_mangle everywhere), and achieve the same, but than I would miss out a lot of the nice features of Rust that are missing in C (among one is better automatic compiler optimizations (e.g. vectorization, better byte-packing of structs etc. not even starting with all the functional features). I don't think it's really an issue, you can get fancy within the Rust crate, and build a C compatible interface on top, that are just wrapper functions, and you likely think more about the API/interface to other languages which is probably not a bad thing, while having an idiomatic API for other Rust crates.

But I agree, that it works better to just stay in the ecosystem of Rust (you can provide a nicer API/interface for your crate with generics/traits etc.).

Anyway I don't completely get what you mean with "extensible from any languages"?

Yeah but you can achieve this with Rust as well with extern "C" and #[no_mangle] (I couldn't really go back to something like C anymore IMHO, all the high-level language niceties and a really good static type system, while maintaining the power of C...)

For example, if I’m writing a compiler for a new toy language

Ok, thinking about it (since I wrote a toy language not so long ago), this is probably a perfect example where unit tests make sense almost everywhere (even for prototyping, say parser).

I think it definitely depends what you're doing, writing unit tests for prototype graphics (engine) code is no fun (and I see no real benefit).

Code readability counts, but I don’t think it’s enough.

I think it depends, For general architecture, E2E or integration tests definitely make sense, for finer-grained code, I think documentation (Rust doc) of the functions in question should be enough to understand what they do (including some examples how to use them, could be tests, often examples (similar as in std rust) in the rust doc are enough IMHO, and otherwise the code itself is the documentation (being able to read code fast is a valuable skill I guess). That obviously doesn't apply for everything (think about highly theoretical computer science or math code), but yeah it depends...

I find writing tests helps me understand my own code better, so I still do it when doing research tasks

Hmm interesting, I try to optimize readability of the actual code itself, so that when I read it again after some time, that I quickly get what this is about, if there's a edge-case or something I thought about while coding, I'll just add a TODO comment or something like that. I feel like reading tests is a "waste of time" for me most of the time (hard take I know ^^).

But all this obviously only applies for researching and fluid code (code that likely will be refactored/rewritten soon), when it's solid code targeting production etc. I'll add unit tests if friction/hassle is low, and integration/E2E tests for the overall thing. But as I said, I'm mostly in fluid/fast moving codebases that are more difficult to test (e.g. because it does gpu rendering or something like that).