Threads for rbetts
-
How do you know if somebody does not use a debugger/line numbers/syntax highlighting? They are going to tell you!
Seriously though, what is that? Trying to show how smart you are? I use the excellent debugging facilities of Intellij for java, python and js almost daily and would not want to miss them. I have debugged hairy classpath issues in datacenters on other continents with my IDE. It is a wonderful tool. The thing is though, that unlike Mr. Professor here I can’t do green field development, but have to work in big messy production code bases.
Sorry, but this really annoys me.
-
Seriously though, what is that? Trying to show how smart you are?
So here’s an example from personal experience. I program with extremely limited syntax highlighting. Everything is in black font, except for comments which are (a fairly bright, almost garish) green. It’s limited enough that I’ve had coworkers ask how I work without syntax highlighting, so I’ll claim to qualify as using “no syntax highlighting” :)
I have a not all that rare, but uncommon enough corneal disease. It reduces my visual acuity. The low contrast themes that seem to be perpetually in vogue (think Zenburn, Solarized, Gruvbox) can have elements that contrast so poorly with the background that I would need to crank the font up to a huge size to really see and read them. And if I don’t make the font uselessly big, I find myself working harder to read the thing someone tried to hint away from me with a low contrast color choice - talk about irony.
When I have attempted to yak-shave my way to a color scheme that I can see well, I’ve found that what it tells me doesn’t actually help me in any meaningful way: I don’t need to highlight “function”, I know I’m in a function because I trust my editor/style enforcer to set the right indentation, because I jumped to the tag, because I navigated by balanced expression - whatever. And because I’m an easily distracted person, the visual noise from a screen filled with colors denoting data types, control structures, function calls… it’s just too much cognitive load. So I turn it off – with the exception of comments, but that’s easy for my brain, “black is live, green is dead”.
I can’t defend the others, but that doesn’t mean they are indefensible. Of course, it’s also quite possible that those choices are ascetic cargo culting of the bad old days too.
-
I have a not all that rare, but uncommon enough corneal disease. It reduces my visual acuity.
This makes a lot of sense to adapt to a unique setup based on what works for you personally! A lot of “I don’t need syntax highlighting” talk feels more like “I don’t need this and neither should you” which comes across as a superiority complex on top of just not understanding how the typical visual cortex processes color.
-
I strongly agree with the low contrast color schemes, I can’t stand them either. I am not arguing that everyone should use any of the things I mentioned, I am just annoyed by people that try to show off by not using them and the article came across like that. To each their own.
-
-
I’ll use an IDE when it doesn’t crash within five minutes of me using it.
Seriously, every couple of years, I attempt to use an IDE, and without fail (starting from the late 80s mind you) I have not had one that did crash on me. And I wasn’t trying to load millions of lines of code into the thing—no, generally, just a single simple file and in five minutes, poof—there goes the IDE down in flames and forget it, I’m not wasting my time. I move back to my previous editor (back in the 80s to mid-90s that was PE from IBM, and from the mid-90s to today it’s joe because I now work mostly in Unix). They work. I don’t need an IDE per language, nor do I need a few gigabytes just to run the environment and by now, it doesn’t get in my way of editing.
As for debugging, I can get by without one, and since I tend to play around with languages from time to time, a debugger might not even exist for the language I’m using. And oh, hey! At work I too have to deal with a big, messy production code base spread across three languages!
Sorry, but programmers who have to use an IDE annoy me. Get off my lawn!
-
-
I agree that IDEs are very useful. But they’re also very slow. I have a license for IntelliJ IDEA via my university and have been very impressed with it. But it takes a non-trivial time to start even on my rather powerful desktop PC. And when I program on UNIX, I usually use hardware from the early 2000s. My favorite editor is (n)vi. On Windows, I usually use Notepad2.
Would I like the tons of useful features that IDEs provide? Sure. But if I have to choose between useful features and low latency, I’ll personally choose low latency. I find I get by pretty well without the features. Vi’s ! and | commands are able to make up for much of the lost functionality.
Not to mention the immense, confusing complexity of the IntelliJ GUI…
-
But it takes a non-trivial time to start even on my rather powerful desktop PC.
Sure, but an IDE is meant to be started once a day (or kept running all the time) It is the tool you are going to spend all day in, so I think it is fine if it takes a bit to start.
I program on UNIX, I usually use hardware from the early 2000s.
Luckily my employer gives me hardware that is less than 15+ years old..
My favorite editor is (n)vi.
I prefer more than one level of undo tbh. vim it is for me.
Not to mention the immense, confusing complexity of the IntelliJ GUI…
Any expert tool will be complex. A 3D modeling, CAD or photo editing tool will not be simple and obvous either.
-
I prefer more than one level of undo tbh. vim it is for me.
Most vi implementations have multiple undo. Unlike Vim, however, most don’t have the Ctrl-R binding. Instead, you press . (period) to continue undoing, then u again to undo the last undo, then . to undo the previous undo, and so on.
Any expert tool will be complex. A 3D modeling, CAD or photo editing tool will not be simple and obvous either.
Eh, I think Photoshop has a pretty good interface, despite being an expert tool. For the most part. I’m quite comfortable in it despite knowing very little about it.
-
Unlike Vim, however, most don’t have the Ctrl-R binding.
Ctrl-R is redo, not multiple undos though: https://vimhelp.org/undo.txt.html#CTRL-R
For the most part. I’m quite comfortable in it despite knowing very little about it.
well, then scratch the photo editor from the list. My point still stands.
-
Ctrl-R is redo, not multiple undos though
Yeah, I mean that Vim uses uu for “undo two changes” and ^R^R for “undo two undos”, whereas many other vi implementations use u. for both (depending on which “direction” you’re currently going). uu is “undo one change and then undo the undo”, which makes people think that vi doesn’t have multiple undo.
well, then scratch the photo editor from the list. My point still stands.
Or perhaps other companies could learn something from Adobe :-)
In any case, I agree as others have noted that this whole discussion really is about employed programmers vs people who program their own stuff.
-
-
-
-
-
Or … different people work in different domains and benefit from different approaches? I’ve spent a lot of years debugging interactions between systems where logging, tracing, pcap, and other log-oriented tools have been more useful to me than debuggers. I’ve also spent lots of time debugging customer reported problems in on-premise installations that I don’t have access to - so robust logging becomes a supportability requirement.
-
-
Interesting that the discussion around this all sort of seems to assume that the maintainers are choosing not to fix bugs and therefore must be bad at running their projects.
That’s probably true pretty often. But I think it’s also often true that open-source projects have a small, more-or-less-fixed time budget for maintenance that does not expand at the same rate as the growth of the user base, whereas the volume of bug reports does expand along with the user base. Over the years I’ve frequently been surprised to learn that some piece of software I use constantly was the product of one person working solo and it wasn’t even their day job.
If I publish something I wrote in my spare time to scratch an itch, and it happens to get popular enough to generate more bug reports than I can handle in the few hours a week I’m able to spend on the thing, what are my options, other than quitting my job and working full-time on bug fixing? Do I delete the popular repo that people are finding useful enough to file lots of bug reports about, in the name of reducing the number of unhealthy projects in the world? Do I just let the bug list expand to infinity knowing I’ll never have time to clear the backlog? Do I spend my project time reviewing historical bug reports rather than working on the code?
In theory, of course, a project that gets bug reports should have lots of people volunteering to fix the bugs. But the quantity and quality of community contributions seems to vary dramatically from one project to the next.
-
It’s not about not fixing bugs. That’s expected, normal, fine. Maintainer does not owe me labour. Closing issues that aren’t fixed is just an FU to the users, though. Let the issue stay until someone fixes it, hopefully someone being affected by it.
-
-
-
Eh. Caveats first:
-
I’m not a fan of simple auto-closing stale bots (roughly: I think the incentives are misaligned, and ~stale is a not-quite-right proxy of a few real problems, and it is trying to work around some limitations of using the GH issue system for triage)
-
but I am a big fan of having a way to punt unactionable issues back to the reporter, and let automation close the issue if the reporter never responds or return it to the triage queue if they do
That out of the way: in a busy long-term project, a stack of open bug reports comes with ongoing logistical overhead. GH’s UI/X exacerbates this, but some of it just comes with the territory.
- This cost is an aggregate of: maintainer time spent managing the requests, the opportunity-cost of that time, the motivation it saps from the maintainers as they spend more time doing paperwork and less time making electrons dance, and the despair that comes from feeling obliged to play Sisyphus on an ever-growing mountain of reports (or the guilt that comes with having to ignore the reports).
- Each person helping with bug triage will be paying a pretty similar cost unless you have tools/processes for de-duplicating logistical effort (unlikely for most volunteer efforts).
- This cost is somewhat proportional to the amount of time each triager is able to invest. If you have 100 contributors doing 1 hour of triage a week, there’s going to be a lot more duplicate effort in the reports they read than if you have 2 people doing 50 hours of triage a week.
- As the pile grows, efficiently pairing people with reports that are the best use of their time will get both harder and more important to your success.
- At scale, the high-leverage maintainers most-likely to have the authority (whether literally the permission, or just the reputational capital) to go around closing reports manually will usually have more critical things to invest their time in. Those the task actually falls to aren’t as likely to be empowered to weed the garden.
- Unless you’re willing to declare bug-bankruptcy or use automation (i.e., ideally #2 above–though obviously also a stale-bot), weeding out old dead-weight reports with the same care/consideration you’d usually run triage with can be (ironically?) a massive ongoing timesink in its own right.
Reports don’t have to be bad or obsolete to contribute to this cost. 10 or 20 brilliant suggestions may be an asset if you can find time to implement 1 a year for the next 5 years. 1000 brilliant suggestions may be an albatross if the extra logistical overhead fritters away the time and motivation you need to implement one.
It doesn’t, of course, apply to all reports equally. It’s better to have a single long-lived “darkmode pls” issue with gobs of comments and reactions than to deal with someone opening a new one every few days.
-
-
-
-
-
Yes. The issue trackers we have need the following features.
- accept issues
- comments on issues
- occasional attachments to issues (need? Maybe not)
- assigning people to issues
- lifecycles as makes sense for your team and organization (open, closed, or on the other extreme: open, ready, in work, in testing, merged, in production, closed)
- tags on issues for classifications
- filtering on reporter, tag, assignee, and status, including default filtering.
You do that, you fit 99% of people’s needs.
Imagine if github had a tag “maintainers will not address” and the automatic filter (currently set to only show issues where their lifecycle is at “open”) only showed “open & not(tag:will-not-address-but-might-merge)”
People would be happier to tune that automatic filter for their own needs, and this would allow a tag to banish the issue from a maintainer’s headspace.
-
-
-
Mostly that there will be a certain number of old bugs that get fixed or rendered irrelevant as a side effect of some other change, and searching through the bug database will become less useful if a sizable portion of the bug reports reflect an obsolete reality.
I’ve occasionally run into this on existing projects, in fact: I will search for some error message I’m seeing, find a bug report with some discussion that includes workarounds people used, and only after wasting time trying those workarounds and digging into why they’re not working for me do I discover that the bug they were talking about is in a part of the code that no longer even exists.
Of course, in those kinds of cases, issues being auto-closed by a stale bot wouldn’t have helped much; I’d have still found them and probably still tried the obsolete workarounds. I don’t have a perfect answer for this either!
-
I haven’t heard a good case for a stale-bot. In the article it says “to reduce the number of open tickets”, but it doesn’t explain why that is a good thing – the number could be reduced to zero by not having a bug tracker at all!
Perhaps it is a UI thing, and Github should display the number of “active” open tickets, for some activity metric.
-
I turned a stale bot on for a popular project because I thought it would be a more honest communication of the likely fate of old GitHub reports - “this is stale and we aren’t planning to triage or address it further”. Few others perceived it that way and, after a few months, the bot was removed.
The triage work is substantial - we spend easily 120 hours a week on community question/support/defect/feature-request triage. I’d love to do more but of course there are fixed dollars and hours to allocate across many priorities.
Anyway, that was my reasoning, which turned out to be incorrect.
-
-
-
-
-
i have used the following style for state-machine implementation to great advantage. for larger more complicated cases i have found that HSM or hierarchical-state-machines are also pretty useful toolkit to have around.
-
Searching for HSMs, I stumbled across this description of behavior trees, which are new to me: https://web.stanford.edu/class/cs123/lectures/CS123_lec08_HFSM_BT.pdf. Neat construction.
-
Would recommend this pre-print book for a thorough discussion of behaviour trees.
Edit: And this old paper from Harel (PDF) for hierarchical state charts.
-
yes, i am familiar with harel’s paper, and have used that as a basis for design & development of hsm’s used @day-job. thanks for the book link on behavior trees. looks pretty interesting.
as a side note, for parsing, specifically network protocols where things are strictly (a very loose definition of strict fwiw) specified through rfc’s etc., i have relied mostly on ragel. would love it hear your (and other folks as well!) experiences/wisdom in this regard as well.
-
-
-
-
Heh, I personally just implement the thing myself (1, 2) :)
More practically, I think there are these choices available:
- use smart IDE, like IntelliJ
- use editor with LSP support (and bug LSP, editor and server developers to improve support for this, as they don’t allow you to filter your code vs library code, or test vs main code)
- produce symbol index as a part of build process (Google’s kythe).
- use offline regex based index (ctags). This works well enough, but might not be super precise (as regexes can’t parse programming languages), and have a drawback that index rebuild must be triggered manually.
The next two options are a straightforward (Christmas holidays scale) extensions to the last one, but I don’t think they are available as a popular stand-alone tool.
- online indexing – listen for the file changes and apply an incremental diff to the index, rather than recomputing it from scratch
- plug tree sitter instead of regular expressions for richer and more correct indexes.
-
Sourcegraph has an open source core, for a standalone tool: https://github.com/sourcegraph/sourcegraph
-
But does the core actually has indexing capabilities? I don’t know, but I think they are consumers of LSIF (a feature of LSP) and ctags, rather then producers?
GitHub’s semantic might be closer to what I am talking about (but, again, haven’t looked close at it):
And, naturally, IntelliJ is open source, that would be (well, it is :) ) the first place for me to look how to do language-aware tooling:
-
-
I was thinking about this comment more after replying and I think my first reply is confusing/wrong. I was thinking, as an end-user, does open source Sourcegraph have code search capabilities.
You’re right - the core consumes LSIF.
https://docs.sourcegraph.com/code_intelligence/references/indexers https://lsif.dev
-
-
-
-
plug tree sitter instead of regular expressions for richer and more correct indexes.
I assume you’re referring to this tree sitter? Looks like an awesome project!
@matklad are you aware of any projects using tree sitter for symbol tagging/indexing? And, with your work on rust-analyzer (and thank you for all you’ve put into that) do you have any thoughts on where effort is best placed to improve code indexing outside of big IDEs like IntelliJ? I.e: working more on LSPs to expand support for indexing and searching, and ensure they are robust and work well on large codebases vs building a modern ctags-like tool that is perhaps based on tree sitter.
-
@matklad are you aware of any projects using tree sitter for symbol tagging/indexing?
I think GitHub’s semantic does that (although not sure), but it tries to go way beyond simple indexing. In terms of making a dent, I think if you want to support a specific language, you really should push on the LSP implementation for that language making server more robust & fast, making client more powerful, and making the protocol more capable and less bet.
If you want to improve the base line support for all languages, I think a tree-sitter based map-reduced indexer could make a meaningful difference. Basically:
- some infra to write mappers which take tree-sitter’s syntax tree and output the list of (symbol name, symbol kind, symbol span) triples (with maybe some extra attributes)
- some fuzzy-search index for symbol names (if using rust, just take the fst crate (or copy-paste
symbol_index.rsfrom rust-analyzer)) - a driver which can:
- process a bunch of files offline embarrassingly parallel
- incrementally update the index when files change (that is, if file
xchanges, remove allxkeys from the index, and then re-add the keys after the mapper step).
- some client API – LSP protocol for easy integration, custom search protocl for more features (streaming & filtering) or just a CLI for unix way
- an optional persistence layer, to load the index from disk (but you most definitely can live with purely in-memory index for a long time, don’t implement this from the start, postpone)
- some pluggability, so that it’s not you, but your users who maintain grammars & mappers.
- a kind of a feature creep, but why not – a tri-gram index on top of driver/mapper infrastructure, to speed-up text-based greps.
-
-
The book “It’s not Carpal Tunnel Syndrome” helped me eliminate pain by becoming aware of slouched shoulders and leaning on elbows as a source.
https://www.amazon.com/Its-Carpal-Tunnel-Syndrome-Professionals/dp/0965510999
-
Yes. I’d gotten used to a sit/stand desk for the last few years at work, then the pandemic hit and I was back to old sitting slouching bad habits full time, and RSI kicked in for the first time ever (Oh, also, perfect storm - see Intellivision stupidity in my other response :).
Using a standing mat and a standing keyboard riser to make my home desk into a standing desk has helped a LOT along with wearing my wrist brace, almost to the point where I’m not in pain on the regular anymore.
-
For those Mail.app users, does Mail now support keyboard shortcuts for archiving and moving to the next message in the mailbox? Looking at https://support.apple.com/guide/mail/keyboard-shortcuts-mlhlb94f262b/mac I don’t see anything.
In Gmail, this is
[and]; If my old muscle memory is right, in mutt this is justspace.Yes for archiving: cmd+ctrl+a. For next / previous message I don’t think there’s an equivalent.
Down arrow? Might be misunderstanding the question though.
I believe they’re referring to a key for next message without defocusing or backing out of the message view, like the arrows in the top right of the iOS Mail message view.