mezuzza

I've used Arch since at least 2011 and I know exactly what you're talking about. When I first started using it, it had the stupid blue install script (pacstrap was it?).

Around that time, I had to reinstall arch ~4 times for some reason or another. It was not a great experience. It made me learn a lot of Linux stuff just to keep it up and hitting `pacman -Syyu` was always a scary thing to do. You could never hit yes to prompts without first going to archlinux.org first to make sure that there was no arcane ceremony to conduct before you upgraded your system (I probably know enough now that it would no longer be arcane, but, hey, we all have to start from nothing).

My experience since around 2014 has been drastically different. Things have been incredibly stable and I've never had to reinstall arch in the past 3 years. I don't really know what caused the change - maybe it was just maturity - but I do welcome it and working on arch has been amazing. I'm saying this not to convince you to go back, but to allay others' fears that Arch is unapproachable or impossible to deal with. At this point, it's still a hard Linux to work with, but it's no harder than any Linux in which you have to work on the command line.

Alternatively, add the following to your `~/.pylintrc`. Granted pylint just stops checking those particular modules, but it's better than nothing.

    [TYPECHECK]
    ignored-modules = ssl,pyodbc

This point should be understood very clearly: The article isn't wrong that an ArrayList has O(n) for a single insertion. However, the article misses that amortized analysis shows that the same structure can be made to have O(n) for n insertions as well. In effect, ArrayLists can be thought to have O(1) insertion time in practice meaning that all you are comparing are the differences in constants between the two structures.

I think the biggest takeaway from this isn't that big-O can fool you (which it very well can), but that misunderstanding analysis can lead to poor decisions.

A better argument for big-O fooling you can be found using Quicksort and any proper O(n Log(n)) sorting algorithm. Quicksort will outperform most in practical cases, but is technically O(n^2) in the worst case (average case O(n Log(n)).

I like to think of it as a way to combine monads. Two classic examples might be the State monad and the Maybe monad.

So let's say you want to create a function that operates on some state and might return a value. These are clearly both monads that you've heard about in Haskell, but how do you use them together? The answer is to use a monad transformer.

StateT is the state monad transformer that takes any other monad and adds state to it. `StateT s m a' is a monad that adds a state of type s to a monad m. So `StateT Int Maybe a' is thing that when given an int which is its state, might return a value.

This particular combination was a little esoteric, so I'm not sure what a great example of this would be. However, you could also think of a situation where you want to have some sort of read-only state (such as flags from the command line) and the ability to write to a log.

In Haskell these are provided by the Reader and Writer monads. But again, you have two separate monads here and in order to actually make use of them, you'll need to combine them somehow. Enter a monad transformer. You can either transform a Writer monad with the ReaderT monad transform or transform a Reader monad with the WriterT transform.

  ReaderT r (Writer w) a
  OR
  WriterT w (Reader r) a