[-] FizzyOrange@programming.dev 7 points 2 weeks ago

Isn't Elixer dynamically typed?

[-] FizzyOrange@programming.dev 7 points 2 weeks ago

Yeah but this one is actually good. So hopefully it will displace all the others.

[-] FizzyOrange@programming.dev 7 points 3 weeks ago

Yes because you used static type annotations. This thread was about code that doesn't use static types (or static type annotations/hints).

[-] FizzyOrange@programming.dev 7 points 1 month ago

That appears to not support comments. How they made that mistake after JSON is a mystery.

[-] FizzyOrange@programming.dev 7 points 1 month ago

Sure there aren't many things that are universally loved. I mean I can't really think of anything that doesn't have some flaw.

But that doesn't mean everything is equal! What would you rather program with, Visual Basic or Go? PHP or Typescript? If you polled people there are obvious winners.

[-] FizzyOrange@programming.dev 7 points 1 month ago

Well, in fairness imagine if Guido did become a racist sexist arsehole. I don't think he should be immune.

But clearly this situation is not right.

[-] FizzyOrange@programming.dev 8 points 1 month ago

Make a post on StackOverflow claiming that no such project exists.

Haha, seriously though, ChatGPT is a solid bet. Lots of Googling. Maybe try https://grep.app/ if you have some very domain specific words to try.

[-] FizzyOrange@programming.dev 7 points 2 months ago

uv is a drop-in replacement for pip. There's no extra standard. It's pareto better. Honestly the Python community would do the world a favour if the deprecated pip and adopted uv as the official tool, but you can guess how likely that is...

[-] FizzyOrange@programming.dev 7 points 2 months ago

Would be cool to have more people on Linux finding and fixing these little details.

Unlikely to happen. This is very complicated low level stuff that's often completely undocumented. Often the hardware is buggy but it works with Windows/Mac because that's what it's been tested with, so you're not even implementing a spec, you're implementing Windows' implementation.

Also the few people that have the knowledge to do this a) don't want to spend a ton of money buying every model of monitor or whatever for testing, and b) don't want to spend all their time doing boring difficult debugging.

I actually speak from experience here. I wrote a semi-popular FOSS program for a type of peripheral. Actually it only supports devices from a single company, but... I have one now. It cost about £200. The other models are more expensive and I'm not going to spend like £3k buying all the other models so I can test it properly. The protocol is reverse engineered too so.. yeah I'll probably break it for other people, sorry.

This sort of thing really only works commercially IMO. It's too expensive, boring and time consuming for the scratch-an-itch developers.

[-] FizzyOrange@programming.dev 7 points 2 months ago

we will soon begin building LightBurn on a new framework that will require our development team to write custom libraries for each platform we support.

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

I've been working on some OCaml code recently. It's a quite elegant language but it has two or three big flaws that really make me not want to write it.

  1. OPAM is buggy as hell. There's one piece of OCaml software that we use at work and literally everyone that tried to build it had problems due to OPAM. One was that it couldn't find zip if you are in more than 32 groups!? I don't even want to think about the kind of code that could lead to that bug. And this is on Linux! Have you tried installing OCaml on Windows? Yeesh.

  2. Global type inference means loads of types are inferred as generics, which means you give up a lot of the utility of static typing. Yes you can add explicit types, but the code I'm working on doesn't have them. Rust was 100% right to require explicit types on functions.

  3. The syntax is pretty awful in my opinion. Yeah I guess it looks elegant and I'm sure whoever came up with it was very proud, but honestly maybe 40% of my time fighting OCaml has been spent figuring out where to place the damn brackets and semicolons. It's extremely unforgiving too. E.g. if you put an extra semicolon on a top level let where you weren't meant to it can sometimes be "valid" but it pulls the rest of the file into an inner scope, which means the compiler gives you a valid but wrong fix suggestion. Languages using curly brackets don't have this issue at all.

The lack of brackets for function calls can also make it difficult to work out what's going on because you have another operator precedence to remember. Have trouble remembering which is higher precedence out of & and ==? Well now we've thrown calling functions into the mix for you to forget too!

Finally the functional focus can lead to mega-expressions that are very hard to follow, especially when combined with the lack of brackets it can end up looking like word soup.

OCaml has a ton of really nice ideas but I'm glad it's just inspiration for better languages (e.g. Rust) rather than actually popular. I mean... it's still a million miles better than Python... But that's a low bar.

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

Yeah I think that's what he meant. You don't want CI editing commits.

I use pre-commit for this. It's pretty decent. The major flaws I've found with it:

  • Each linter has to be in its own repo (for most linter types). So it's not really usable for project-specific lints.

  • Doesn't really work with e.g. pyright or pylint unless you use no third party dependencies because you need a venv set up with your dependencies installed and pre-commit (fairly reasonably) doesn't take care of that.

Overall it's good, with some flaws, but there's nothing better available so you should definitely use it.

view more: ‹ prev next ›

FizzyOrange

joined 1 year ago