When you play a bridge tournament, you play as part of a 4-person team. All the cards are dealt and placed in boards such that once they're played, they're replaced back as the North, South, East, or West hand.

Now your team of 4 is split into two partnerships, one playing all the N/S hands, one playing all the E/W hands. For any given hand of N,S,E,W, what counts isn't what your partnership does on your cards (either N/S or E/W), it's the delta between what your other partnership scored and what you scored. So, if you and X are playing North/South, and your other team members are playing E/W, then for every hand its your score - their score becomes your team score for that deck of cards.

In this way, there is no element of luck. Every team plays the same cards, every team plays both pairings (N/S and E/W), and only the difference matters. It's pure skill, both in bidding what you will make, and then playing the cards to actually make your bid. You can "win" the deck by causing someone who bid a grand-slam to lose a trick, and get the maximum points for that deck to your team.

Bridge is a truly excellent game. Simple rules, but incredibly challenging to execute correctly every time.

Simon

It's not the features that you stare at with no idea what they do that cause a problem. As you say, a quick look at the manual can help to sort that out (though it does add to the overall cognitive load). It's all the potentially subtle things that you don't even realise are features and so never look up and don't realise that, contrary to first inspection, the code is actually doing something subtly different to what you expect.

[sigh]

*gives up trying to reason. There's none so blind as those who don't want to see...

I think you're proving my point about the black-and-white nature of how people regard free speech in the USA. See, I'm very much in favour of free speech, it's been a fundamental right of UK society now for longer than the USA has existed in its current form, and pretty much any UK citizen would be equally for it.

Where we differ is in nuance. The UK approach is a shades-of-gray one, where the right to speak whatever you want, no matter how hurtful to others, is actually counter-balanced by how much what you say hurts the target of your invective; and this in turn is counter-balanced by the importance of what it is that you're saying to society as a whole. There's a whole spectrum of things to consider when making a judgement, which is why the UK position is that if a free-speech issue comes up, it ought to be decided by a judge rather than a black/white hard-and-fast rule.

Now does this matter, in day-to-day life ? No. People say and do pretty much the same thing on both sides of the pond; but when a big issue comes up and a judgement has to be rendered, the courts take a more reasoned view than "Is this free speech ? Yes ? Ok then, feel free to ".

I'll ignore the idiotic purposeful misreading of the Fire thing...

This is a very US-typical way of thinking.

In the UK, it's more of a "where is the harm" approach. If there is more perceived harm in the exercise of said speech than in allowing it, it won't be allowed. This is more difficult to administer (it means someone, usually a judge) has to make a decision about this rather than it just being black and white. It does make life more pleasant for more people.

Having lived in the UK and the US for over a decade each, I have some perspective on this, and personally I think it's worth it, worshipping at the altar of "Free Speech At All Costs[*]" is an absolute, and I tend to distrust absolutes.

Simon.

[*] It's not a real absolute in the USA, you can't shout "Fire!" in a crowded theatre in the US either, for example, but it's a massively more common mindset of US people compared to UK people in my experience.

Except math is almost never actually done that way in practice. Euclid was wonderful, but almost all modern math does not work that strictly (and Euclid really should have been more careful with the parallel postulate -- there's "more than one thing at a time" involved there). Yes, proofs are careful and detailed, but so is, say, technical writing in English. Except for a few cases (check out metamath.org, or Homotopy Type Theory) almost no-one actually pedantically lays out all the formal steps introducing "only one concept at a time".

I don't think you need math even to be a great programmer. I do think a lot of great programmers are people who think in mathematical terms and thus benefit from mathematics. But I also believe you can be a great programmer and not be the sort of person who thinks in those terms. I expect the latter is harder, but then I'm a mathematician so I'm more than read to accept that I have some bias in this topic.

Math is a language. Just because you can frame things in that language doesn't mean that that language is necessary. Recipes are often in English. English is sequencing (words are a serial stream after all). That doesn't mean English is necessary for programming (there seem to many competent non-english speaking programmers as far as I can tell).

Disclaimer: I am a professional research mathematician; I do understand math just fine.

Of course there was a time when college education was supposed to be education and not just vocational training.

The other part of the problem is that math is so diverse. There's calculus and engineering math with all kinds of techniques for solving this or that PDE; there's set theoretic foundations; there's graph theory and design theory and combinatorics and a slew of other discrete math topics; there's topology and metric spaces and various abstractions for continuity; there's linear algebra and all the finer points of matrices and matrix decompositions and tensors and on into Hilbert spaces and other infinite dimensional things; there's category theory and stacks and topos theory and other esoterica of abstraction. On and on, and all very different and I can't even pretend to have anything but cursory knowledge of most of them ... and I have a Ph.D. in math and work for a research institute trying to stay abreast of a decent range of topics. The people who actually study these topics in depth are all called "mathematicians", but if you're an algebraic geometer then sure, you're probably familiar with category theory and homological algebra; if you do design theory and graph theory then those seem like the most useful subject available.

Calculus is perhaps not the best measure however. Depending on where you go in the programming field calculus is likely less useful than some decent depth of knowledge in graph theory, abstract algebra, category theory, or combinatorics and optimization. I imagine a number of people would chime in with statistics, but to do statistics right you need calculus (which is an example of one of the directions where calculus can be useful for programming).

Of course the reality is that you don't need any of those subjects. Those subjects can, however, be very useful to you as a programmer. So yes you can certainly be a programmer, and even a very successful and productive one without any knowledge of calculus, or graph theory say. On the other hand, there may well be times when graph theory, or calculus, or statistics could prove very useful. what it comes down to is whether you are inclined to think that way -- and if so it can be a benefit; if not it won't be the way you think about the problem anyway.

Questioning and asking are two completely different things, otherwise one wouldn't "ask a question", one would either ask or question.

To question something is to doubt the premises that lead to a given statement. To ask something is to enquire about something. When one has doubts a conclusion (i.e.: questions), one normally asks to ascertain the veracity of the conclusion. This leads to the construct "to ask a question" as in "to resolve a doubt".

Simon

You may want to look into pandas as a middle ground. It's great for sucking in tabular or csv data and then applying statistical analysis tools to it. It has a native "dataframe" object which is similar to database tables, and has efficient merge, join, and groupby semantics. If you have a ton of data then a database and SQL is the right answer, but for a decent range of use cases in between pandas is extremely powerful and effective.

Python has the default implementation CPython which compiles python to an interpreted bytecode; there's also Jython which compiles to JVM, and IronPython which compiles Microsoft's CLR. There's also Cython (which requires extra annotations) which compiles to C and thence to machine code, and numba which does compilation to LLVM. Finally there's Pypy which is a python JIT compiler/interpreter written in a restricted subset of Python.

They are memes in the sense that they are specifically finding words and phrases that are frequently inherited by papers (where "descendant" is determined by citation links), and rarely appear spontaneously (i.e. without appearing in any of the papers cites by a paper). An important feature is that their method used zero linguistic information, didn't bother with pruning out stopwords, or indeed, do any preprocessing other than simple tokenisation by whitespace and punctuation. Managing to come out with nouns and complex phrases under such conditions is actually very impressive. You should try actually reading the paper.