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

Any from reputable manufacturers?

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

Yeah it's definitely a vast improvement on previous attempts (Poetry et al).

I dunno if it can be called solved until it's officially sanctioned and installed by default though, and I don't see that happening for a very long time.

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

I would probably recommend not trying to understand the whole field of programming initially. It's huge, you won't understand what the terms mean (e.g. OOP, functional programming, etc.) and it's not very motivational.

Instead I would pick one or two popular languages to learn and actually make something in. The no-brainers are Python and Typescript. They're hugely popular, not difficult, and let you get a lot done.

I think I would consider learning both at the same time. If not, at least don't stick with Python too long. It is immensely popular but also has a lot of brain dead design decisions. Especially a) it's reaaaally slow, you easily get a 50x speed up just by switching language, and b) the "infrastructure" around it - installing Python, adding libraries etc. is completely awful. There are attempts to fix that but they're nascent.

Above all I think a good thing to have is a realistic goal of something to make. For Typescript the obvious thing is a web site. I really like this way of making web sites - you can get started with literally 2 command - but it may be a little too much for a beginner.

For Python I would look into some kind of automation or maybe web scraping thing. It's decent at that.

Or if you have more specific project ideas you could use the most appropriate language for those, e.g. a microcontroller project you probably want to start with Arduino (C++). C++ was my first language (apart from QBasic which doesn't count). Probably not for everyone though. I was very young and had free time.

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

The only Git GUIs that I've ever liked:

  • GitX, and its many forks. Mac only though.
  • Git Extensions. Terrible name, but this is actually a standalone Git GUI and is surprisingly decent. I think it started Windows only but maybe there's a Linux port now.
  • VSCode's "Git Graph" extension. It's not quite as fully featured but it integrates well into VSCode and is pretty nicely designed.

I've tried almost all the others (SmartGit, Sublime Merge, GitKraken, etc.), and didn't really like how they worked.

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

Ooo I've not seen this before. Looks interesting.

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

Gemini has a 1 million token limit. Also instead of just giving it the entire source you can give it a list of files and the ability to query them (e.g. to read an entire file, or search for usages/definitions of terms etc.).

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

I’m pretty senior, having been in the industry for some time, so I tend not to be asking the questions that will have a million examples out there

Me too, but this was C++ where there isn't a strong culture of making high quality libraries available for everything (because it doesn't have a proper package manager, at least until very recently), so you do end up having to reinvent the wheel a fair bit.

And sometimes you just need things a bit different to what other people have done. So even though there are a gazillion expression parsers out there (so the LLM understood it pretty well) there are hardly any that support 64-bit integers. But that's a small enough difference that it can deal with it.

[-] FizzyOrange@programming.dev 3 points 3 months ago

The only good free option for that is SolveSpace. Don't bother with FreeCAD. It still isn't usable. SolveSpace is remarkably good for an open source CAD program.

It does have some notable missing features though, e.g. no bevels, fillets, drafts, etc. and last time I used it it had accuracy issues with small holes. But for your use case it's probably fine.

[-] FizzyOrange@programming.dev 3 points 3 months ago

I’m an old 31yo man. These fora are getting to complex. Back in my day we had bulletin board systems.

Lol bullshit. BBSs were completely obsolete by like 1997 when you were 4.

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

Isn't it actually because they moved most of their driver code onto the card itself or something?

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

Ugh yeah that's infuriating on Github search too. Obviously if I'm searching for some identifier I don't want 10 pages of results in /tests.

How hard can it be? Just weight anything with test in the file path lower than everything else. Job done.

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

Very neat! Is it embeddable? There are plenty of statically typed languages but there are hardly any statically typed embeddable languages.

Quite a lot to like here. I only skimmed it but some things that seem like slightly odd choices:

  • > instead of -> for return types. The latter is pretty clearly nicer IMO and less confusing.
  • Old C-style type name instead of name: type. The latter is less confusing and plays better with type inference and inlay hints. Easier to parse too.
  • For a small language I think arbitrary sized integers make way more sense than fixed size. This is one of the few things Python got completely right IMO. If you care about performance you can add a range type, like range(0..256) and unsigned like range(0..) and then use flow typing to convert between them.
view more: ‹ prev next ›

FizzyOrange

joined 1 year ago