zygo_histo_morpheus @ zygo_histo_morpheus @programming.dev

Posts

1

Comments

261

Joined

3 yr. ago

Algebraic datatypes is a huge part of typed functional programming for me, you should read up on that!

qBittorrent can do this for example

Personally, the language that's taught me the most to learn has been Haskell. It has a lot of very interesting ideas and a learning curve that plateaus after most other languages. There are several ideas that have trickled down from Haskell to other parts of the programming world and learning about them in the context Haskell is in my opinion better because you'll learn about them in a context where they fit in with the rest of the language very well instead of being late additions that offer an alternate way of doing things.

Coming from Java and JS, Haskell has a very different approach to a lot of things so you'll have to re-learn a lot before you get productive in it. This can be frustrating for some but you'll learn more if you get over that hump on the other hand.

Haskell doesn't see very much industry use and arguably isn't very well suited for industrial application (I haven't used it professionally so I don't know personally) so it might not directly help you land any new jobs but it is in my opinion it's a very good way to develop as a programmer.

Honestly I do think java is kinda bad, but that doesn't really matter that much if you're not developing in it. Haven't looked through the thread but it sounds like people are just being armchair elitists. I would prefer not to code in java but when I'm just using software there are a lot of things that are more important than what language is written in.

You should check out git reflog if you don't know about it already. It allows you to view the history of commit changes which is very handy if you want to undo an --amend or rebase for example

The article mentions AI. 16gigs feels far too little to run a LLM of respectable size so I wonder what exactly this means? Feels like no one is gonna be happy about a 16gig LLM (high RAM usage and bad AI features)

I agree, but you don't need nixos if that's all you want since you can get nix-shell on most linux distros

You probably don't have to worry about the compatability of #pragma once so just use that. The only reasons to not use it is if it's important to only use standard compliant c for whatever reason or if you need to support some arcane compiler that doesn't support #pragma once. Realistically, neither of these are situations that you'll ever be put in and if you are you probably have much larger things that you need to worry about.

The first thing I already have problem with [...]

For the record: headers suck. There's a good reason why most programming languages don't use them. They're like a realy primitive version of setting things to public/private in modules, where public things go in the header and private things don't. Modules are a very useful abstraction over this where you don't have to do as much mucking around.

My laptop has a fn lock that you can toggle, it can be very convenient to switch to f-key mode when working with some applications but most of the time I'm using volume or brightness keys.

Rust can use all basic C data types, but it can't use C++ classes, in any straightforward way at least.

I don't really think it's much of a problem that h isn't on a touch typing key because you don't need to press h very often. I probably use : way more than h. (: requiring shift isn't ideal though, although that's another can of worms)

I might be suffering from stockholms syndrome here, but my prefered ways of working with git are the cli and the fugitive vim plugin which is a fairly thin wrapper around the cli. It does take a middle ground approach on hiding the magic and forcing you to learn the magic which I suppose can be confusing for beginners when you work collaboratory and something happens that forces you to go beyond pull/add/commit/push

I was curious about why people would run git push --force on a shared branch. Some reasons people gave were:

• they’re working on a collaborative feature branch, and the feature branch needs to be rebased onto main. The idea here is that you’re just really careful about coordinating the rebase so nothing gets lost.

A safer solution would be to make a new branch and do the rebase on it instead, that way the shared branch won't be impacted. You might still lose changes if they're pushed after merging to main but that's not really rebases fault. You can always cherry pick or something then from the original un-rebased branch (hopefully without any merge issues...)

I think you know what I mean when I contrast Rust with GC'd languages, we can call it opt-in garbage collection if we're being pedantic.

If you just Rc everything (which I'd count as "abusing Rc") Rust is significantly worse than a language with a good GC. The good thing about Rust is that it forces you to aknowledge and consider the lifetimes of objects. By default things are allocated on the stack, but if you make something global or dynamically handled (e.g. through Rc) you have to do so explicitly. In Rust the compiler has greater compile time information about when things can be freed which means that you need less runtime overhead to check things and if you want to minimize the amount of potentially long-lived objects you can more easily see how long objects might live by reading the code as well as get help by the compiler to determine if a lifetime-based refactoring is sound or not.

Haskell. I think that more people being familliar with Haskell concepts would be good for programing culture and it would increase the odds of me being able to write Haskell professionally, which is something I enjoy a lot when writing hobby code at least. Having more access to tooling and a bigger eco system would be nice as well.

I'm not a 100% sure about my answer though. For one, I might grow to resent Haskell if I had to use it at work, and there's also a risk that it would be harder to do cool innovative stuff with the language when more big companies depend on it.

You are absolutely correct that rusts safety features don't extend to memory leaks, but it's still better than most garbage collected languages unless you abuse Rc or something, and it does give you quite fine-grained controll over lifetimes, copying and allocations on the heap which in practice means that rust is fairly good about memory leakages compared to most languages.

Haven't used ink with godot specifically but it's a really nice language for writing branching dialogue in imo. It feels lightweight and has many nice features easily available. For someone familiar with programing, it has some questionable choices when it comes to the scripting language but that's more there for writers who want a bit of scripting, if you know the programming side of things as well you can just put that logic in a real programming language.

I don't think boolean logic is a necessary prerequisite for coding, if you don't know it yet it makes more sense to learn about it when you come across a programing problem where you'll want to use it imo