This is a great question! I tend to find my debugging practice differs depending on the language I’m using and the array of problems, but the recurring common denominator is printf.
In Python I mostly rely on print(f) debugging, especially when working on multiprocessing programs, which I do rather frequently. With multiprocessed Python, pdb is useless. pdb is great, but not for a multi-process program. Most of my issues are related to sub-optimal API documentation that fails to point out argument types, and find I do a lot of trial-and-error programming, for which printf’s are great. Occasionally I drop into `import pdb; pdb.set_trace()` to inspect objects or the REPL to try out ideas.
JavaScript is an interesting beast where, next to console.log, I find myself using linters a great deal. A linter isn’t as sophisticated as compile-time checks, but does a frightfully good job at most trivial mistakes that are hard to debug in runtime. I often find myself running the linter under watch(1) so it updates when I make changes.
In Perl and shell, which I use ever more infrequently, the equivalent of the printf debugging is the norm. The only language I have found the debugger to be the first choice has been Java.
With Rust, I find myself resorting to a debugger surprisingly seldom. Its type system and the safety checks in the compiler catches most of the mistakes I make.
I don’t do much C programming anymore, but if I did, I would be interested in using rr (http://rr-project.org/), which allows you to record a run of the program and replay it _exactly_ as it was the first time, essentially letting you reproduce and fix race conditions.
There’s not necessarily an antagonism between distributed and centralised in this case. You can still have a centralised frontend such as Github Issues, backed by a versioned and distributed backend using i.e. git.
Isn’t it a little bit strange that the paper itself is writing about this, and presenting it as if it was a serious news story instead of a shameless plug for itself?
I can accept this for small, local papers, but this seems ludicrous.
If a user has a sub-par experience browsing a website in one browser, she will switch to another and the loss is on the browser vendor’s behalf and not the website’s.
The vendor has an obligation to create the best web experience for the user and while it’s certainly a sad state of affairs that not more sites are testing for features rather than the UA string, it’s a sad fact that not all web authors care enough about interoperability to remedy their bad ways.
The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done.
Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was Mozilla's recommended workflow. Queues are a novel way to organise your work in progress, but is quite different from what people are used to coming from svn or git.
More recently bookmarks were added (also as an extension you have to opt-in to), which are reminiscent of git branches. They make it possible to have a HEAD-based workflow where you rebase frequently, much like you would with git, only that the defaults of `hg log` and various other commands don't interop very well, which means you have to memorise a lot of flags and arguments.
There are also many strange defaults in hg that you simply have to get used to, for example that `hg push` by default pushes everything. I have a hook in place on the remote end which prevents me from doing that.
By far the most frustrating experience with hg is that you cannot expect the default installation to come with sensible defaults. The argument is that keeping "advanced" functionality out of core prevents new users from accidentally using it.
An unintended consequence is that it sometimes makes it difficult for other people to help when you're stuck because more often than not their environment won't match yours.
One frequently lauded aspect of hg is that the user interface is easier to understand. Whilst I appreciate difference in taste, my experience is the opposite. If you follow the HEAD-based bookmark-style workflow, I find many cognitive dissonances in how the bookmark feature interacts with other commands.
At Mozilla we use hg for the canonical repositories and we have many Mozilla related extensions, but whereas I use hg every day now and it's a fine experience as long as I stay within the marked lines, I would return to git in a heartbeat if I had the chance.
"The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done.
Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was Mozilla's recommended workflow. Queues are a novel way to organise your work in progress, but is quite different from what people are used to coming from svn or git."
Up to this point your comment was true, objective, and very helpful (though I would remove the word "obscure"). Then it starts to sound like maybe you learned git first and got used to it's defaults and now mercurial tastes a little funny to you. I'm guessing this because I got good with mercurial first and then when I tried git it left a funny taste in my mouth. I thought, what is this "fast-forward merge" that doesn't actually merge anything? Why do people talk about deleting a branch when it doesn't actually delete the branch of commits in the DAG of commits, just a pointer? Why does pull do a pull (fetch) and merge (mercurial's pull just pulls, or fetches, I guess)? Stuff like that.
Do you realise that "HEAD-based" doesn't mean anything? In git you are always at HEAD, by definition. It refers to the commit currently checked out, wherever it may be in history. The only way to not be at HEAD is to have a bare repo without a working directory. Mercurial calls this commit "the parent of the working directory" and uses the notation "." to refer to it.
It's a very widespread common misconception that "HEAD" means "latest", probably because this is what it means in svn.
And this brings up some very interesting usability research from Google: the vast majority of people who use any VCS don't really understand it:
I realise you are trying to say that you like to rebase and linearise your hg history. This is just `hg pull --rebase`, just like `git pull --rebase`.
> only that the defaults of `hg log` and various other commands don't interop very well, which means you have to memorise a lot of flags and arguments.
I assume you want something like git where "log" by default starts from the currently checked out commit and hides the rest?
You can have that, and if you don't like memorising the incantations to do that, you can save them as aliases in your ~/.hgrc
It's worth noting with bookmarks that the workflow you describe doesn't even need to use bookmarks at all (and I wouldn't call when they were put into core to be "recent"). All a bookmark does is give a development line a tag that can move.
In Python I mostly rely on print(f) debugging, especially when working on multiprocessing programs, which I do rather frequently. With multiprocessed Python, pdb is useless. pdb is great, but not for a multi-process program. Most of my issues are related to sub-optimal API documentation that fails to point out argument types, and find I do a lot of trial-and-error programming, for which printf’s are great. Occasionally I drop into `import pdb; pdb.set_trace()` to inspect objects or the REPL to try out ideas.
JavaScript is an interesting beast where, next to console.log, I find myself using linters a great deal. A linter isn’t as sophisticated as compile-time checks, but does a frightfully good job at most trivial mistakes that are hard to debug in runtime. I often find myself running the linter under watch(1) so it updates when I make changes.
In Perl and shell, which I use ever more infrequently, the equivalent of the printf debugging is the norm. The only language I have found the debugger to be the first choice has been Java.
With Rust, I find myself resorting to a debugger surprisingly seldom. Its type system and the safety checks in the compiler catches most of the mistakes I make.
I don’t do much C programming anymore, but if I did, I would be interested in using rr (http://rr-project.org/), which allows you to record a run of the program and replay it _exactly_ as it was the first time, essentially letting you reproduce and fix race conditions.