alxprc

RailsCasts helped me so much in getting started with Rails in the late 2000s. It opened my eyes to how one can effectively structure a web application in general, from caching to authorisation. Ryan’s explanations were concise yet accessible; it felt like a colleague showing me cool stuff.

I figured it must have been popular, but wouldn’t have guessed as high as $1M revenue. Looking forward to reading the rest of this series.

Maybe Plumbum: https://plumbum.readthedocs.io/en/latest/

This release is particularly interesting because it includes the sidebar patch, which has existed in various forms for about 10 years [1].

Mutt has generally been quite conservative in accepting patches. NeoMutt [2] is a project hoping to kick-start development on the Mutt project, by being much more willing to accept contributor patches.

The repository [3] is becoming more and more active; help is always greatly appreciated!

[1]: http://www.lunar-linux.org/mutt-sidebar/

[2]: http://www.neomutt.org/

[3]: https://github.com/neomutt/neomutt

I use LaunchBar and didn't know about this; cool! For those who also didn't know about it: it's the 'Instant Send' feature under 'Shortcuts' in the preferences.

It doesn't seem to work for words selected in the terminal, though, like in vim, or a scrollback buffer in tmux or less (you can click-and-drag to highlight things, but I mean highlighting in the apps themselves, like `viw` in vim to select the word under the cursor). That would be very nice.

Dash [1] is an OS X app for browsing documentation of many different APIs.

[1]: https://kapeli.com/dash

Thanks for clarifying. You're right that I was too broad, and it's certainly true that many physicists don't share my opinion (I'm working on that).

Speed is always a concern, but I don't think it dictates that C++ should be the primary ‘user-facing’ interface. Numpy is fast, but it doesn't sacrifice a nice API to achieve it.

Personally, a big difference is that a lot of the Python packages feel fast to use and, most importantly, to write. ROOT can be fast to execute, no question, but I feel like I'm fighting against it (and I'm sorry that's very vague and qualitative).

It would be very interesting to hear more about the genomics use-case, and how they evaluated the other options.

I am a particle physicist, and used to use ROOT every working day. It is still used daily by thousands of other particle physicists, though, and is a core part of many high-energy physics experiments.

I think there are a few of objectively neat features of ROOT:

* Versioned persistency of C++ objects deriving from the TObject base class [1];

* Script-like execution of C++ and a C++ REPL based on clang [2]; and

* Dynamic bindings of the C++ classes to Python [3].

There's an accompanying, but independently developed, file access protocol for reading and writing ROOT files over a network, too [4].

On the other (subjective) hand, ROOT is regarded a pain to use by ‘analysts’, the people who use ROOT to make the results that go in to physics papers. There are already some good, old-but-still-valid critiques [5, 6], so I won't say too much, but I think a large part of the problem comes from two things:

1. ROOT tries its best to do everything that a particle physicist might want to do. This encompasses a very wide range of things, and this has lead to ROOT having a very large, often intractable codebase that cannot be modularised.

2. It has failed to keep up with contemporary coding techniques and analysis methods. Most of the PhD students I know use the Python interface to ROOT, and yet the ROOT developers are planning to drop Python support for the next major version (ROOT 7, which is expected in 2018). Those that do use C++ aren't able to use even C++11 effectively with ROOT, as its interfaces aren't compatible.

Luckily, I'm confident that analysts will move to a better way. I've been very encouraged by the astrophysics and machine learning communities in particular, who are using Python to do low- and high-level analysis on large datasets, as we do in particle physics, and are producing fantastic results. Tools like pandas, matplotlib, and scikit-learn are an absolute joy to use in comparison with ROOT, and the communities within the Python ecosystem are wonderful: they foster very open code development, and value readable, well-documented, fast code.

I don't need ROOT to get any better, because I think the future is already here.

[1]: https://root.cern.ch/root/html534/guides/users-guide/InputOu...

[2]: https://root.cern.ch/cint-prompt

[3]: https://root.cern.ch/pyroot

[4]: http://xrootd.org

[5]: http://www.insectnation.org/articles/problems-with-root.html

[6]: http://www.insectnation.org/articles/root-wishlist.html

Hey author, it'd be cool if you gave me a mention, as you did comment on my post about it [1]!

[1] https://alexpearce.me/2012/04/simple-jekyll-searching/#disqu...

Sure, but what if you have more than another section that should be styled differently? Classes can help differentiate same-name elements with different contexts, so you don't need unwieldy structure-specific CSS selectors like

  main > section > main

just

  main.semantic-class

As it says in the article, this is the discovery of parity, P, violation in a system where it's not been seen before. In a "nice" universe, one might expect mirror images to behave the same, but here they've discovered that interactions between electrons and quarks are different depending on the spin of the electron.

So, it's related to CP violation in the sense that it something "violates CP symmetry" if it's behaviour changes when you flip the charge and the parity of the system simultaneous. Here, they only flip the parity.