[-] FizzyOrange@programming.dev 6 points 4 months ago

I agree. What we need is better PR workflows, not getting rid of review entirely. That's dumb.

[-] FizzyOrange@programming.dev 6 points 8 months ago

You have misunderstood. The is ranting against Clean Code, not clean code.

[-] FizzyOrange@programming.dev 6 points 9 months ago

because someone believed an ANSWER on a different question answered my question

Yeah that is actually their official position. Your question is duplicate if an answer elsewhere might answer it, which is clearly absurd. Essentially they think "what's 1+3?" is a duplicate of "what's 2+2?".

I think fundamentally they gamified moderation too well, and for many people they turned the site into a mod-maxing game, which obviously makes it an abysmal place to be for normal users.

[-] FizzyOrange@programming.dev 5 points 9 months ago

Interesting idea, but your trick is never really going to help (you can store up to 255 bytes instead of 254). Also always using 256 bytes for every string seems wasteful.

I think LLVM's small string optimisation is always going to be a better option: https://joellaity.com/2020/01/31/string.html

[-] FizzyOrange@programming.dev 6 points 1 year ago

That's nitpicking. It is statically typed. Is Dart not statically typed because it has dynamic.

You could call it "gradually typed" if you want to be pedantic.

can be circumvented pretty easily

That means it isn't sound.

[-] FizzyOrange@programming.dev 5 points 2 years ago

Honestly I think the complaints about the job market are overblown. If you are good then there will always be a job for you somewhere.

If you've already tried programming and you enjoy it then it is a really great career. Crazy money (especially in the US) for low effort and low responsibility.

Just be aware that CS is usually a lot more theoretical than most programming. You'll be learning about things like Hoare logic and category theory. Tons of stuff you only really need in the real world if you're doing formal verification or compiler design.

Still, I kind of wish I did have that theoretical background now I am doing formal verification and compiler design! (I did a mechanical engineering degree.)

Also you don't need a CS degree to get a programming job. I did a survey of colleagues once to see what degree they had and while CS was the most common, fewer than half had one. Most had some kind of technical degree (maths, physics, etc.), but some had done humanities and one guy (who was very good!) didn't have a degree at all.

I wouldn't worry about the market. Maybe take a look at the syllabus for places you might apply to, e.g. here's the one for Cambridge. Also I guess an important question is what's the alternative? What would you do otherwise?

[-] FizzyOrange@programming.dev 5 points 2 years ago

No, they're inherently optional in Git. There's no way to "check in" a git hook. You have to put in your README

Clone the repo and then please run pre-commit install! Oh and whatever you do don't git commit --no-verify!

You definitely need to actually check the lints in CI. It's very easy though, just add pre-commit run -a to your CI script.

[-] FizzyOrange@programming.dev 6 points 2 years ago

I would say:

  1. Avoid async if you can. It's way more difficult and error prone than non-async Rust. Unfortunately a lot of web stuff insists on async.
  2. Don't be afraid to .clone() stuff to fix lifetime errors. It's not optimal but consider that in C++ everything is pretty much cloned by default, and nobody ever said C++ was slow.
  3. Use anyhow::Result for error handling. It's the easiest option.
[-] FizzyOrange@programming.dev 6 points 2 years ago

Yeah I mean it's definitely a reference volume of last resort, rather than a tutorial you would read cover to cover. Clearly a genius but he explains things as if you already understand them, and can also read his mind.

That said, for a lot of the content the only alternative is research papers and they are even less accessible. I definitely would only use it if I couldn't find answers anywhere else though.

[-] FizzyOrange@programming.dev 6 points 2 years ago

Git is all about tracking changes over time which is meaningless with binary files.

Utter codswallop. You can see the changes to a PNG over time. Lots of different UIs will even show you diffs for images.

Git can track changes to binary files perfectly well. It might not be great at dealing with conflicts in them but that's another matter.

The only issue is that binary files tend to be large, and often don't compress very well with Git's delta compression. It's large files that are the issue, not binary files. If you have a 20 kB binary file it's going to be absolutely fine in Git. Likewise a 10 GB CSV file is not going to be such a good idea.

[-] FizzyOrange@programming.dev 6 points 2 years ago

You're right of course. I think the issue is that Linux doesn't care about the UI. As far as it is concerned GUI is just another program. That's the same reason you don't have things like ctrl-alt-del on Linux.

[-] FizzyOrange@programming.dev 6 points 2 years ago

I scrolled a lot before I gave up looking for an example. No thanks.

view more: ‹ prev next ›

FizzyOrange

0 post score
0 comment score
joined 3 years ago