I use either 2 spaces or tab for indentation for most languages, and I never go beyond 80 (actually, 79). It works well for XTerm, and most utilities that I use.
For git commits, I do not go beyond ~69 characters per line, so it looks neat when I am viewing the commit history.
120 characters may be fine if I only care about coding in VSCodium, for example, so sometimes I might go above the 80 column width when I am programming Go using VSCodium, but I try to not do that, because I still use "less" and whatnot, plus I have an old 17" monitor. I do not like wide monitors, I want to be able to look at the whole screen all at once, with wide monitors I would either have to be too far away, or move my head / neck / eyes too often.
So... my fonts are small, I limit to 80 column width, and I am quite happy with it. :P
To each their own, although I would have issues with Java code that not only requires me to have many files open, I would have to switch back and forth files, and I would have to horizontally scroll a lot.
I hope you realize what I am trying to say, if not, I will elaborate.
Clearly to whom? I think it works fine in C with 8 spaces per indent level. It works fine in python and rust with 4 spaces per indent level. For some languages I think it's worth going down to 3 spaces per indent level. But I've not hit that many languages where it's worth going much past 80 characters.
> The question could possibly be exactly where to draw the limit, and that’s a debate for every project to have.
It is subjective, and does not live in a vacuum because along with purely subjective preference regarding it on its own, it affects, and is affected by, other choices like naming and indentation conventions.
They like 80 in their project. Feel free to choose something else for your project.
> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. If this is because of a difference in counting or us actually having a lower amount of C problems, I cannot tell.
When I counted I got about 55% which is pretty close to the standard 2/3.
`git log --graph` is just a really really bad GUI. Why not use a good GUI instead?
Although in fairness it's quite hard to find a good Git GUI because there are so many bad ones. The only good ones I've found all have some kind of flaw:
* GitX - the clearest design IMO, but it's one of those "gazillion forks" bits of software like TomatoUSB, and Mac only. Plus it has some annoying bugs.
* Git Extensions - I didn't even realise this was a Git GUI until relatively recently because it its terrible name. It's pretty decent, but Windows only.
* VSCode 'Git Graph' extension - my current favourite - it integrates into VSCode too which is much better than a standalone app, especially when using Remote SSH. However it is abandonware and although the source is available, the license doesn't let you republish it so it's not "open source" and nobody can take it over.
Disappointingly even these don't let you do things that a GUI obviously should let you do, like copy & pasting commits, dragging and dropping to rebase.
Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V?
But, they're still miles better than `git log --graph`.
Compare the graphs that people draw to explain git branching. They are usually very beautiful. Then you see the graph even these GUIs make, and they are still pretty bad. I think the visual graphs could be improved quite a lot.
`git log --graph` without `--oneline` is pretty hard to follow — that's not what I use, and it's not what I suggested.
With `--oneline`, it's not perfect but it's good enough to be useful — and by working within the constraints of the CLI, I didn't have to tell people to install software to get my point across.
And I already spoke approvingly of Gitlab's GUI for graph representation! I don't disapprove of GUIs; I use them all the time (particularly Github's). One you grok the data structures that underlie Git, you wind up seeing front ends as interchangeable.
Well, then I simply don’t agree that `git log --oneline --graph` is “really, really bad”.
Clunky? Sure, but it suffices to visualize simple branching patters. And no visualizer suffices for gnarly graphs (like a long-lived topic branch that has repeatedly merged in upstream), because the building a mental model of a complex history is difficult even if you can see it.
I basically never used Git command line unless fixing some problems other people created.
It is just insanity when people claim "only proper way is to use command line" - well yeah it is much faster if you work on your branch and just need to make quick series of commits. But as soon as you have to deal with collaboration with other people and organize project, coordinate features etc. I find GUI invaluable and Git Extensions of course.
No, I mean why can't you select commits in the graph and copy/paste them. I wasn't talking about copy/pasting the lines of text in the `git rebase -i` file.
It may serve a different purpose, but I personally use https://zolk3ri.name/cgit/ggrp/about/ for displaying commits, because it categorizes commits based on prefixes such as "feat:", "fix:" and so forth, and supports scopes too (e.g. "feat(foo)"), and a lot of my projects have commits with such prefixes.
That's fine until you have to ask a question that isn't answered anywhere on the internet. Then you post a perfectly reasonable question and get it downvoted to hell...
It's a common pattern that questions get a lot of downvotes initially from people trawling new questions who see a lot of genuinely bad questions (seriously there are loads), then see a good question that they can't understand in 1 second so they just downvote/close it too. So you quickly get downvotes and then later you get people coming from Google who are actually looking for that thing that upvote it.
I think SO actually did try to improve matters once. I can't find it now but they were going to make it impossible to go below 0 votes and allow one free "reopen", or something like that. But the power mods absolutely hated that idea and SO sort of depends on them so they chickened out. Now they're paying the price.
If you run `anakin <some command>` it will kill any orphan processes that <some command> makes.
However is still isn't the true "orphans of this process must automatically die" option that everyone writing job control software wants - if `anakin` itself somehow crashes then the orphans can live again.
Still it was the best I could come up with that didn't need root.
> Give me wifi, e-ink display, and the ability to write a regular program that writes unicode chracters to STDOUT (and have that rendered to the display) and I'll give you my money right now.
I bought an Inkplate 10 from eBay for like £80, which is an absolute bargain. 10" display, ESP-32. You do have to buy a battery but they're cheap and available and it has the charging circuits built in.
The only real downsides I've found are:
1. No case. I don't want an ugly 3D printed one so I ended up buying a custom sized picture frame online (£17 I think), and mounting it in that.
2. The software is Arduino based. Arduino is trash, but I don't want to have to figure out how to set up something sane like PlatformIO or Rust, so I've opted to put as little software on it as possible. All it does is download an image, display it, and then go to sleep for however long the server says. I even made a simple custom image format so I didn't have to deal with PNG or whatever.
Yes it is. Code quality is abysmal. There's no CLI interface to their build system so you have to use their gimped editor. It doesn't even support incremental compilation, which means a one-line change takes like 5 minutes to deploy while it rebuilds SSL libraries etc. every single time.
Having said that I probably would have just bought this if it was available at the time. Only 7 inches, which is tiny, but a lot less effort!
Not e-ink though so the display isn't always-on and you need a power supply. This can hang on the wall and you just have to recharge it every few months.
Interesting. I've been working on a pre-commit replacement too, written in Rust but using WASI for all plugins (no exceptions!). I haven't got very far but I think this will have huge advantages over pre-commit, mostly in reliability.
Me and my colleagues have had numerous issues setting up pre-commit because it inherits Python's atrocious infrastructure.
I'm curious how this is going to deal with actually running plugins? Will it take the same approach as pre-commit and add dedicated not-very-good support for a load of different languages?
Not gonna say Python isn't a mess but I'm surprised a self-contained application is so
bad. All the pieces are there to have it work— give it its own venv, use wrappers or the shebang so transparently uses it, and plug-ins get installed into that venv. All should be happy.
Pre-commit has like the worst DX to me, so I'm really looking forward to a replacement.
My biggest gripes are:
1. Pre-commit hooks are designed to modify files in-place, which turns `git commit` into something that can alter your work tree. IMO those tools should never ever modify files (unless explicitly asked by the user) and only output a diff and exit code that signifies if the check failed.
2. It manages the tools with its own environment but never exposes it. I always have to dig around its cache directory to find out which executable it is running if I have to reproduce the problem after something goes wrong.
I also looked into WASI as well as lua until I ultimately decided that I think I can get rid of the concept of plugins altogether in favor of pkl. We'll see how well that works out but right now I don't have any use-cases that would require plugins and if I can stick to that it will definitely help performance.
So you have to already have all the linters installed? Ok I am planning to solve that problem too, but we'll have to see whether it's actually possible to compile e.g. rustfmt to WASI. In my experience so far WASI is pretty alpha quality.
mise is my solution to that problem. I don't think it should be the job of a hook manager to install things developers should have installed for other reasons anyways.
I agree to both. It just sounded to me like it is an unbearable experience, which I wanted to correct. Certainly, on a clean slate, I prefer a static binary
Maybe they're not implying this kind of limited dependent type system but surely it is still dependently typed? It's just not the "full fat" dependent typing.
Another example of a language with limited dependent typing is Sail. It has "lightweight" dependent types for integers and array lengths (pretty similar to Ada from what it sounds like).
It's very good in my experience - it lets you do a lot of powerful stuff without having to have a PhD in formal verification (again, sounds similar to Ada).
> An example of something you can do in a dependently typed language is write a sorting function in such a way that the type checker proves that the output will always be in sorted order.
Yeah you can't do that but you can have the type checker say things like "n^m is positive if n is positive or even" or "foo(x) -> (bits(n), bits(m)) with m+n=x" (not the actual syntax). I'm pretty sure you can't do that stuff in a type system without dependent types right?
Well, "dependently typed" is widely used to mean something like "derived from Martin-Löf type theory, including arbitrary dependent sums and dependent products"; in other words, "dependent types" means "full fat dependent types", and it's the things that are less powerful that require qualifiers.
(So when Sail says it has "lightweight dependent types", that seems fine to me (it does seem to do more than it could with simple types or polymorphic types), but if it simply asserted that it "had dependent types" I would feel misled.)
The wording is subtle and language does change, but what I want to push back on is the confusion I see from time to time that "if I can write anything that looks like a function from values to types, I have the same thing that everybody talking about dependent types has". If you think this you don't know what you're missing, or even that there is something you're missing, and what you're missing is very cool!
