zygo_histo_morpheus @ zygo_histo_morpheus @programming.dev

Posts

1

Comments

176

Joined

2 yr. ago

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 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 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.

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

Many "AI generated" images are actually very close to individual images from their training data so it's debatable how much difference there is between looking at a generated image and just looking at an image from its training data in some cases at least.

It's not that much of a strain since it only handles DNS traffic.

When you go to e.g. programming.dev, you computer needs to know the actual IP and not just domain name so it asks a DNS server and recieves an answer like 172.67.137.159 for example. The pihole will just route the traffic to a real DNS server if it's a normal website or give a unkown ip kind of answer if it's a blacklisted domain. Actually transmitting the website which is the bulk of trafic is handled without the piholes involvement.

I can see how PS might be better for writing actual programs in but the wordiness really gets in the way when youre just trying to write something on the command line so it feels poorly optimized for cli usage. Bash is very poorly optimized for writing programs otoh.

What's esoteric about Rusts syntax? I can't relate at all, but maybe I had just the right background of languages commin into Rust.

Do you think that you can't take a critical view of "technological advancement" without understanding it? I understand if you think the title is too clickbaity or something but it sounds a bit like you're dismissing criticism about AI out of hand.

One downside with the code on the right is that it's not obvious where the different functions might be called from. In the example on the left, we know that we're not, say, adding toppings to a pizza that we've already baked. If we notice a bug in the topping adding function on the right, we might get tempted to reason about adding toppings as a general process that needs to handle all kinds of situations when in practice is doesn't.

When you have single use functions like this it's good to limit the scope of the function using whatever language features are available so that you can more easily reason about where it's being called from

I'm not in charge of many open source projects but the last one I actually put up on gitlab instead. We use gitlab at internally at work and it's completely fine. I mostly use my github account to interact with repos that other people host on github.

Every human work isn't mechanically derivative. The entire point of the article is that the way LLMs learn and create derivative text isn't equivalent to the way humans do the same thing.

I think that there might be a fundamental missunderstanding here: I'm not saying that we shouldn't use tabs to accomodate people with disabilities, I'm saying that better editor features seems like a better "solution" to the problem.

In the abscence of editor improvements I agree that it makes sense to use tabs to accomodate disabilities, I just don't think that it will catch on that mutch. I don't think that spaces (imo) being slightly better is a good reason to not accomodate dissabilities by using tabs right now, but I do hope there is a more editor oriented solution some day because I think it would propably be better both for people with visual disabilities and without.

Being in a slightly argumentative mood might have led me down towards validating this false dicotomy between editors and tabs, and I apologize for wasting both our time because of this.

You do have a point that I personally might have more influence over if a given project has spaces or tabs than if better editor features are made, but I think that there can be a point to having the poor support for programming that is apparently offered by screen readers to take some place in the discussion as well since that is a potentially more important piece of the puzzle.

I can't imagine that there is much of a point to keep replying after this so I think I'll leave it here.

Thank you for the insight, didn't expect it to be that dire. Tabs and spaces nonwithstanding, hope that the screen reader/braille display tooling situation improves in the future, sounds like it is sorely needed.

Do you think it matters if getting a large number of people to switch to tabs is an achievable project at all? Maybe I am a bit cynical but this seems to me like something that is actually very difficult to do.

When faced with a problem like this I think it makes more sense to approach it from a perspective of what would be a practical way to actually address it and refusing to do that does I think in its own way betray a different kind of cynicism.

For the record what I'm saying isn't that I wouldn't switch to tabs for the sake of people with various disabilities, I'm saying that spaces are slightly better than tabs if you don't have any relevant disabilities so if there is a way to have the cake and eat it to that would be a nice bonus, but that's honestly besides the point.