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

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.

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.

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.

There’s a difference between doing something that’s “easier” and what’s right.

The way I see it, there are two competing strategies for improving the experience for braille screen users: making tabs more widely used and improving braille oriented editors. Without knowing for sure, my guess is that improving editors is a better strategy and this is in part because it is easier.

As a matter of principle it might be “more right” for people without visual disabilities to adjust themselves to people with visual disabilities than vice versa, but I also think that it’s important to care about what is actually likely to improve braille screen users experience and not default to the more principled goal without any consideration for how realistic it is.

(Of course, I might be overestimating how easy it is to get better braille oriented editors, but since you referred to this as the “easy” solution it doesn’t sound like you’re disputing this specifically.)

Arguing that it’s invincible to convince people at large to adopt tabs over spaces with good arguments is a ridiculous statement

I do actually think that it is very hard to convince basically every programmer of something, no matter how good arguments you have.

Also, without knowing much about the issue, it sounds a bit like the tooling for people using braille displays isn’t very good and fixing that is maybe also worth advocating for, perhaps it’s even a strategy for advocacy that is more effective?

My spontaneous reaction is that making some sort of braille oriented setting for some or hopefully most editors used by people with braille displays (I have no idea if using a “normal” editor even makes sense if you’re using a braille display) is the most pragmatic solution to their screens being taking up by spaces.

First of all, convincing everyone to use tabs is a monumental task. Convincing people with braille displays to use more convenient tools on the other hand seems pretty easy, why wouldn’t you want to use more convenient tools?

Secondly, there is a large amount of code written with spaces today, so even if people switch with tabs in the future you might still want to be able to read legacy code.

Thirdly, I don’t think that the choice of tabs vs. spaces is completely arbitrary because of alignment. Using tabs for indentation and space for alignment leads to a lot more micro management of whitespace compared to just using spaces. I would guess that alignment isn’t very braille friendly anyway, but it does make the code more readable for other people. Having a good braille editor affordance might be closer to letting us have our cake and eat it too.

Of course, I don’t know what this would look like exactly, and maybe there’s some sort of obstacle that I’m overlooking, I do want to be clear that this is just of the top of my head as someone who has never used a braille display.

Another accessibility reason for tabs: when using a braille display, each space takes up one character cell, so indenting with four spaces eats up four cells. Indenting three times with four spaces each eats up 12 characters already. Tabs only take one character cell each, so three indents = three character cells used.

The fact that there (I assume?) isn’t a braille oriented text editor that can handle space-based indentation in a smarter way is a bit depressing. Maybe the solution should be better tools based around accessibility rather than convincing everyone to switch to tabs, which is a project that will just never succeed.