philm
@philm@programming.dev
- Comment on Me after I got fired 9 months ago:
Easy, it’s just… continue programming in python. (large codebases are a mess in python…)
More seriously: Don’t do that, it’ll only create headaches for your fellow colleagues and will not really hit those (hard) that likely deserve this.
- Comment on Microsoft is seeking a software architect to port Microsoft 365 to Rust 9 months ago:
It’s less the job post, more the implication, that they consider Rust to be better than (their internally developed) C# for one of their major products. And that I think is worth news (as it could further drive towards adoption of Rust in general).
- Comment on We're not the same! (period) 11 months ago:
Almost… To be precise it’s a Merkle DAG
- Comment on Bill is a pro grammer 11 months ago:
One day you will inherit a code base so bad that you’ll end up commenting old code
Will not be the case, I won’t take a job, where I have this situation (or I’ll quit pretty quickly)…
Yeah my “comment standards” (btw. as others mentioned here, I was unprecise/unlucky with the choice of words, I meant “comment the why” or doc-comments totally fine and should be aimed)
Your so called comment standards and principals are fine if you are building something from the ground up
Yes that was also targeted with my comment. But what you’re referring to is just missing documentation, and I think this should be done on a higher level. The “comment why” rule applies for spaghetti code non-the-less…
- Comment on Bill is a pro grammer 11 months ago:
Nah, it’s not, code is modular (IME should be kinda tree-structured), a book is linear.
So the API should be in your analogy the synopsis. And I haven’t said, that there shouldn’t be any comments. E.g. doc-comments above functions, explaining the use-cases and showing examples are good practice.
- Comment on PipeWire 1.0 Release 11 months ago:
Actually it’s been so stable for me for at least a year (not sure when I switched exactly), that this post kind of surprised me, I thought it was > 1.0 already
- Comment on Bill is a pro grammer 11 months ago:
Don’t get me wrong comments != documentation (e.g. doc-comments above function/method).
I probably was a bit unprecise, as others here summed up well, it’s the why that should be commented.
- Comment on Bill is a pro grammer 11 months ago:
Yeah that’s a good summary
- Comment on Bill is a pro grammer 11 months ago:
Yeah, but unironic…
If your code needs comments, it’s either because it’s unnecessarily complex/convoluted, or because there’s more thought in it (e.g. complex mathematic operations, or edge-cases etc.). Comments just often don’t age well IME, and when people are “forced” to read the (hopefully readable) code, they will more likely understand what is really happening, and the relevant design decisions.
Good video I really recommend: www.youtube.com/watch?v=Bf7vDBBOBUA
- Comment on If you had to choose one programming language that you had to use for the rest of your life, what would it be? 1 year ago:
Zig > Rust because actually writing safe Rust code
Start thinking more functional, I rarely have issues with the borrow-checker, or even have to write
unsafe. But it obviously depends on the context, when the issue at hand really requires a lot of interior mutability orunsafecan be pain.I’m also super fast nowadays with Rust, probably faster than with any other language (thanks to great tooling?).
- Comment on Writing C++ is easy. 1 year ago:
Depends on what trait bound error messages you have had yet, I had 1000 lines long already, where it’s not obvious at all what is meant (and is often a very simple fix). But I’m sure this will get better over time, there’s already a bigger ongoing redesign of the type system solver, so maybe it will be integrated into stable rust soon.
- Comment on Yes 1 year ago:
but effectively it’s bash, I think
/bin/shis a symlink to bash on every system I know of… - Comment on Mozilla will move Firefox development from Mercurial to Microsoft’s GitHub 1 year ago:
People use the most convenient way to collaborate, and that’s for me currently Github. Really hope, some day a better alternative with ForgeFed becomes reality.
- Comment on [deleted] 1 year ago:
Yep this sums up my experience quite well too.
I want to emphasize two things here:
- Learn reading code (by reading code…) of high quality open source projects. It helps getting new concepts and actual creative coding patterns for concrete problems (unlike learning all these “design patterns” in books that IMHO are often just boilerplate generation (hard take I know…)).
- Start coding (open source) projects, especially challenging ones, and keep pushing your limits, by trying to learn new smart things, how to achieve problem X. I stagnated in my workplace for quite some time, got unhappy (around COVID), scaled down working hours significantly (I have quite a spartan life, so I can fortunately afford it), and am coding a lot more open source since then. I think I almost learned more in the last 2-3 years until at least to the years of university (quite some time ago), maybe even more than in university, and have a lot more fun while coding. I think going in depth with a programming language comes automatically, when the project is fancy enough, I learned a lot of limitations of Rust (and thus basically reached the deepest level of (parts of) the language) while designing smart APIs.
- Comment on What are the recommended scripting languages for complex shell scripts beyond bash? 1 year ago:
Yeah the strict type-system of Rust is great at finding issues.
I think when understanding, that bash is basically only programs with parameters (
[is a program that takes all kinds of parameters and as last parameter]) then bash is quite ok for stuff that doesn’t need a lot of algorithms, i.e. passing the in and out from one program to another. But as soon as there’s basic logic, You’ll want to use a fully-fledged programming language.Also the maintainability aspect: You can just start using fancy stuff you never want to use in bash and it can slowly grow into a library or application or something like that.
Btw. I have started a syntax-sugar library/crate that creates typing information for all kinds of programs via the builder-type-state-pattern, so that you don’t always have to look up
manetc. and that it should be more convenient to execute programs (not open sourced yet, and low priority for me as I’m working on various other exciting projects currently) - Comment on What are the recommended scripting languages for complex shell scripts beyond bash? 1 year ago:
Yeah as weird as it sounds to use a “low”-level systems programming language such as Rust. Rust works surprisingly well as “script” language. (And you don’t have to deal with the ugliness of bash, admittedly though, that bash is quite a bit more concise when using a lot of program executions and piping the results etc.)
- Comment on Typing is not a programming bottleneck 1 year ago:
It has Properties (basically syntax sugar…)
- Comment on Typing is not a programming bottleneck 1 year ago:
I’m totally aware of the benefits of encapsulation, but the way java does it seems so unnecessarily boilerplatey (C# is better, functional programming makes encapsulation even simpler, but that’s a different paradigm…)
I like how Rust approaches this via the module system and crates (you have
pubfor the public interface,pub(crate)for crate/lib wide access and no modifier for being only allowed to access in the current module and submodules of that module) - Comment on Typing is not a programming bottleneck 1 year ago:
My condolences, haha (I’m honestly not a big Java lover ^^).
- Comment on Typing is not a programming bottleneck 1 year ago:
Yeah but why do I have to use an IDE to generate getters and setters in the first place? It just adds up to more mental overhead, because my brain has to process this boilerplate somehow, even if my IDE can generate it (I know it’s simple code, but it’s even simpler to not have that boilerplate code at all).
- Comment on Typing is not a programming bottleneck 1 year ago:
The curse of OOP (java style…).
I mean why do you need to write getter and setter methods. I have wondered at the beginning of university 10 years ago, and am still wondering why you would need something like that…
- Comment on Which language you wish would really grow and reach mainstream adoption? 1 year ago:
Not without a super fancy type system that has to be still found. I think the key issue is cyclic data-structures (e.g. doubly-linked list). The language somehow needs to have strong/weak pointers and automatically determining them is a very complex research question…
- Comment on Which language you wish would really grow and reach mainstream adoption? 1 year ago:
At this point, I think it’s almost mainstream, and it’s still growing fast (and it’s getting better, rust-analyzer is really awesome these days, I was there at the beginning, no comparison to today…))
I may be biased, but I think it’ll be the next big main language probably leaving other very popular ones behind it in the coming decade (Entry barrier and ease of use got much better over the last couple years)
- Comment on Your server owner is now banned from participating on lemmy's Github 1 year ago:
misunderstanding was
I think here’s a misunderstanding too :). With quickly I mean closing without getting feedback, or without providing a good reason why the issue is closed (without being obviously resolved), not the dates (which I think are only relevant, when actually awaiting a response). I have seen this over the repo a few times, good writeups often explaining some behavior etc. and then bam closed, either as duplicate (although it’s not (example)), or “not as planned” etc. I think this is not good behavior for an open source project (I’m around the block for a few years contributing and maintaining OSS, for reference…). Especially as this is a real community project and not some random opinionated application (well depending on how you define it, could be true to lemmy, but I don’t think it is…)
I rather let an issue open than close it, “just to have fewer open issues”. I can close it anytime, and if someone searches for that issue sees it closed while it isn’t resolved, it just creates confusion…
- Comment on Your server owner is now banned from participating on lemmy's Github 1 year ago:
Yeah best is probably not the “best” wording and a little bit provocative, but it’s the “best” ecosystem I have found so far (and I squabbled around with like ~10+ programming languages, often at a deeper level). I’m mostly talking out of a development-experience + quality of software standpoint.
I’m very happy to be proven wrong, or be given a different direction (but C# or JS/TS are definitely not the languages/ecosystem I want to be confronted with, or even maintain systems in it…)
- Comment on Your server owner is now banned from participating on lemmy's Github 1 year ago:
Sure you can doubt me as much as you want (and this is probably a healthy attitude). I tend to educate myself, and learn from experience (and that I dare to say, I do have…). As you may have guessed, I really recommend looking into it, there’s so many good design decisions with Rust (and the ecosystem). As a starting point/library: axum would be the web-framework I’d recommend to use (as it uses Rust quite idiomatically). And for e.g. service communication via grpc, tonic is quite nice. As database abstraction layer the last time I have used sqlx which was quite convenient to use. (So far with a “classic” web-stack). And rust-analyzer is probably the best language server I have used (and felt the fast development over the time (with “successful” switch of the maintainer), which speaks for itself as well…).
Btw. it also really depends on what you actually mean with “web backend development”. I.e. “just” writing a web-server that takes connections via HTTP or something deeper the stack…
- Comment on Your server owner is now banned from participating on lemmy's Github 1 year ago:
Well yeah the second comment didn’t really had to be, but hey it’s certainly not really reason enough to ban someone from the repo. The first comment I think is totally ok (as well as marking it off-topic, but optimally with an answer, probably marked as off-topic as well). Just keep an issue (it’s not a PR) open, until the issue is resolved in one way or the other i.e. either solved reasonably via a third-party client (with links to it), asking the community, whether this is resolved, wait for reactions, and close it after some time based on that. Banning someone, or quickly closing or not reopening after a carefully written argument, that the issue is not solved etc. is just childish behaviour, especially for a community focused project (I’m watching a few lemmy issues on GH).
- Comment on Your server owner is now banned from participating on lemmy's Github 1 year ago:
despite what Rust cultists will undoubtedly soon come to tell me
And here I am :)
There’s a lot of reasons to go with Rust (and least of all performance), especially as web-backend. Top-notch libraries/ecosystem (I work extensively with all kinds of programming languages and most others suck in one way or the other). At this point I dare to say that it has the best ecosystem in this regards. Also a static type-system only being exceeded by Haskell (when talking about general purpose languages, that are actually in use), which makes projects maintainable by a lot of people, especially relevant for an open source project. There’s a reason why a lot of high quality projects are either rewriting or starting in Rust or are thinking to switch to… Etc. don’t want to throw more Rust evangalism at you, since there’s a lot to just google and learn…
Anyway, there were a few changes lately that made federated lemmy better (with the last release especially), the initial bugs I accept. But I agree, they aren’t veterans from the valley with multiple years of experience, just a bunch of idealists that had an idea and were persistent enough for years to implement it, I certainly have respect for that. What I don’t like, is that they are moderating a little bit too much, not being mostly community focused (among others, to avoid forks). But bringing a federated link aggregator like lemmy to the place where it currently is, at least takes quite a bit of time… So a fork (if really necessary) sounds like the most likely way forward…
- Comment on There once was a programmer 1 year ago:
That only really works, if the method is self-contained, and written in a language that GPT has seen often (such as python). I stopped using it, because for 1 in 10 successful tries I waste time for the other 9 tries…
- Comment on There once was a programmer 1 year ago:
This.
If I’m writing something slightly more complex, ChatGPT(4) is mostly failing.
If I’m writing complex code, I don’t even get the idea of using ChatGPT, because I’m only getting disappointed, and in the end waste more time trying to “engineer” the prompt, only to get disappointed again.
I currently cannot imagine using ChatGPT for coding, I was excited in the beginning, and it’s sometimes useful, but mostly not really for coding…