First, the situation is more complicated outside of math/physics/cs. E.g. in biology, getting papers is much more complicated, which has connections to computer literacy of authors, conventions in the field, and maybe also conditions of the journals.

Second, if you are an institutional researcher, there are good chances that your institution has subscription to the major places relevant for your research.

I hope it's a problem solved over time largely by natural selection. I'm much less likely to cite papers that I can't read easily.

AFAIK Elsevier's pricing structure and conditions on things like arxiv uploads is much stricter than Springer's. Not sure though.

Ok, that makes sense. I use vim only on Linux, so I wouldn't know. Ctrl-v in normal mode is what always does this for me in terminal vim, but I guess it might interfere with clipboard shortcuts on other platforms.

(Then again, the argument sounds as that vim loses because vim has this different across platforms, while, Notepad++ wins because, well, it is not available on some platforms. In Linux desktop environments, alt+drag typically drags the window and is not passed to the application.)

No, my point is that it's often easiest to *understand* things from a couple of examples, especially when your programming fundamentals are solid.

But even what *you* are saying is nothing bad to do, when you just need to do a quick hack - quickly. (The real burden is on deciding when a quick hack will or will not do.)

In the end, it's about whether what you create works. SO helps that happen.

Exactly. When the concepts are already well sorted out in your head but you need to quickly get something going with an unfamiliar API, it's typically way more time-efficient to just peek at a few code snippets over ten seconds rather than plodding through a confusing API docs written by a graphomaniac with ADHD. StackOverflow is a god-send that made me immensely more productive, especially in unfamiliar programming environments.

Really, you start with "Those days are long gone", then talk about "letter-sized printouts at 10 characters per inch"?

To me, 8 is just perfect when viewing on a computer screen, it has the perfect balance of clarity and horizontal space management. But if someone thinks it's too much, that's fine - because I'm using tabs, so they can reconfigure. This is where all the anti-tab arguers shoot themselves in the foot. There are some good arguments against tabs that make the spaces vs. tabs choice non-obvious, but seems like noone on this thread has a clue about these.

(Of course, in Python I just follow PEP and :set et, tw=4, sw=4. A whole-ecosystem convention trumps personal preferences, and Python especially (with its semantic indenting) has good reasons to abolish tabs.)

You do know about vim's visual block mode, right? Care to explain in what ways is Notepad++ superior to vim in this or other regards, or link somewhere?

I really wondered while reading the wild stories behind the talk system why a "good enough" solution wasn't first created quickly and deployed.

IMO the 20% effort (or much less) that would fix the 80% (or much more) of UI issues would be simply automating the mediawiki markup editing on talk pages! Just add “add new topic” button to the page, “reply” link after each ~~~~ that’ll show up a textarea for your comment and upon submission simply edit the wiki source automatically, adding your comment. New users don’t have to learn all the syntax rules and discussion can proceed quickly and with much smaller amount of editing races. Power users can still just edit the page when it’s needed in the very long tail of uncommon cases.

This could all take days to develop, weeks to push through live beta to full deployment. What am I missing? I guess part of it is that TFA never properly defined what problems are being solved here, so maybe my assumptions about that (UX while adding comments) are wrong.

Ah, I see; thanks!

(That's not really that relevant to keep for vast majority of applications, though - and an AI knowledge base does not need to contain these for sure.)

enwiki is ~40GB expanded as of 20150112. Do you mean with images or all languages?

C++ is the wrong language to compare Perl to. Python is what you need to align with it. And it is so much tougher to build a good case for Perl in that light. (Not impossible, but it probably won't be very convincing. Perl is the anarchocapitalism of programming languages - you have near-absolute freedom to choose your ways, which is delightful for the top 20% users, but unfortunately most people choose the most awful and dirty ways in the face of this freedom, typically just for lack of experience.)

(I love both Perl and Python. But in the past few years, I find myself writing vastly more Python that Perl code, except the oneliners of course.)

^ this. You have (i) existing modules in your project that are not python3 compatible, (ii) existing external modules that are not python3 compatible.

The situation is a lot better now than it used to be, but for example you still cannot use the deep learning theano-based libraries. This means people still produce python2 code at this point, which means issue (i) will be going to be an issue for even longer... (Even if you are starting a project from scratch, you often want to borrow some code from a different project you have access to - which may be python2.)

(Actually dealing with unicode was always painful for me in python2 and python3 typically results in less code therefore. Depends a bit on what you do.)

Still, the transition to Python3 is much smoother than it'd be to transition to Perl6. It seems to me kind of unfortunate that they chose "Perl 6" as a name for this newfangled language that has not that much to do with the current Perl. C++ is more "backwards" compatible to C than Perl 6 is to Perl 5, it seems to me. I think the idea of transition is not on the table at all for 80% Perl developers; you just go to Perl6 if you want to pick up a new language that seems fun. Whereas regarding Python I think even most 9-to-5 code-grinding guys recognize that migration makes sense (in a few more years).

Indeed, someone meanwhile made the point about loudness wars and difference in mastering above. That makes total sense and wasn't something I knew before. I wish the article was about that. :-)

Audio is just a crazy world of snake oil and placebo.

Really, the argument that's supposed to convince us is this?

> That warm vinyl sound: "I think this is what people like about it: it pins very closely to the way that human beings hear music organically," Gonsalves said. "It's very mid-range-y and very warm," a sound that flatters the fuzzy guitars of rock 'n' roll.

I'm sorry but I just don't buy it. There seems to be no obvious reason why you couldn't easily hack up a digital audio filter that makes stuff "sound like a vinyl". I'd even wager that it already exists?

Especially when you skip the compression and use FLACs. (But no, I'm not that kind of person who would claim to be able to distnguish 320kbps mp3 from a FLAC.)

I don't really use side-by-side windows but I still like portrait mode - because I get to have enough room for sideways tabs!

Seriously, I don't get it why by default the browsers still ship the tab bar at the top. As soon as you have more than 6-10 tabs open, tab bar on the side becomes incredibly more convenient to work with.

Do you have any links discussing this more in depth? I took a look at http://en.wikipedia.org/wiki/P... and that one is pretty brief and it's not remotely clear if it succeeded at these or not.