zygo_histo_morpheus @ zygo_histo_morpheus @programming.dev

Posts

1

Comments

261

Joined

3 yr. ago

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.

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.

runtime, the point is so that you can see if the types align and then come back and fill in the function bodies later

Scala has one, which throws a NotImplemented error

You're propably better of not worrying too much about the awesome-neovim list until you're more familiar with nvim itself

I thought LSP support was built into nvim. Why are there so many LSP plugins?

Most of the plugins seem to be adding bells and whistles to the core LSP functionality and can be safely ignored. The main one that I recomment is nvim-lspconfig which makes it easier to get servers up and running. Neovim itself knows the lsp protocol but isn't aware of any particular lsp servers. lspconfig comes with premade configurations for different servers so that you don't have to e.g. tell neovim where to look for the executable or which servers handle which filetypes and so on. It is doable to use LSP without this plugin as well, it just means more boilerplate in your config file.

And what the hell is treesitter and why do I need it?

Treesitter is a different way of parsing files for e.g. syntax highlighting. Vanilla (neo)vim uses a pile of regular expressions to perform syntax highlighting essentially, while treesitter actually parses the source files in a way that is aware of the way the target language works. Treesitter might know the difference between a macro and a function for example, and can highlight them differently. You can also querry the syntax tree that tressitter has parsed for use in custom scripts or plugins. Also completely optional unless you want to use a plugin that depends on it.

As for plugin manegement, I use vim-plugged (which is a vim plugin but is also compatible with neovim). You basically just list the github/gitlab repos you want in your .vimrc file and run a command to download/update them.

My lsp code in my init.vim file is as follows (taking advantage of nvim-lspconfig): https://pastebin.com/0Wy1ASwk. Adding a new lsp means making sure that the server itself is intalled (e.g. through my package manager) and then adding another line in the langs object, like when i added erlangls i just added erlangls = {}, on line 19.

(EDIT: For some reason the nmap('gd', vim.lsp.buf.definition) line is repeated a bunch of times in the paste bin. That's not on purpose)

Debugging is imo a weak point for both vim and neovim, there's nvim-dap and vimspector which takes advantage of LSPs sister protocol DAP (debug adapter protocol). Setting it up is principaly similar to LSPs. Vim and neovim also have the builtin termdebug plugin which you can load using packadd termdebug in you .vimrc file and allows you to debug using GDB.

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.

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.

It's hard to do this consistently (especially in a team) because people might (and statistically in a large enough project, will) use the tab key for alignment since it's faster than pressing space, or just be confused about what whitespace is tabs and what is space. Just using space everywhere is idiot proof and requires no work to micromanage. The only way to use tabs is to not align at all.

If you pipe bat to another command it will act like cat so you can use it as a drop-in replacement and have it print things nicely when you want to view text and otherwise work as a normal commandline tool.