splinterofchaos's comments

There exist very accurate tests for autism, but /getting/ a diagnosis can be difficult. A teacher spotted autistic symptoms in me back when I was ten and recommended I get tested. It wasn't until three years later that a couple thousand dollars got taken out of my college fund and I received a day's trial of tests to determine that I have it. Insurance did not cover the procedure.

Now-a-days, people have more understanding and awareness (this was a little over ten years ago), but it is still an expensive procedure, involving many specialists of different areas, sometimes neurologists and brain scans.

The classic C/C++ versions are recursive, and using the STL, c++'s quick sort looks very similar to the functional one.

From cppreference.com: http://coliru.stacked-crooked.com/view?id=0b2cec4d8c69ffaf

http://en.cppreference.com/w/cpp/algorithm/partition

There do exist object-oriented functional languages (Ocaml). Functional vs OOP is a false dichotomy, though a very common one. I prefer to use functional techniques in imperative languages with simple objects.

> A language that is brief and concise gives you fewer opportunities to make mistakes

I don't think that's necessarily true. Look at brainfuck!

But in all seriousness, dynamically typed languages could be categorized as "more expressive" than statically typed languages, and generally allow for cleaner interfaces, but turns static-typing compile-time errors into dynamic run-time errors. What's worse is that your tests might not cover the specific conditions that cause it. So, while you might consider C++ less expressive and concise than Python, at least you'll never try to take the square root of a string.

The ease of writing bug-free code and debugging depends on a lot of factors. How well designed is the interface/API? How structured is the code? How good are the available tools? It's not what language you use, but /how/ you use it.

How about:

    def move_pos(x):
        if random() > 0.3:
            return x + 1
        return x

    def move_cars(positions):
        return map(move_pos, positions)

I do not believe that functional programming benefits from brevity, except at the top layer. Unfortunately, functional programmers often expand their equations which, having examined them thoroughly, they understand implicitly, but can give too much information to the reader all at once.

Though, I have to agree, the FP community really hasn't been able to demonstrate how to do it without losing efficiency, and yet many proponents claim we should abandon all other paradigms. All of these articles seem very biassed towards FP.

I enjoy functional programming, but I prefer to work in imperative languages where I have a choice between paradigms.

I called "bar" with "<int&&>" to demonstrate that you can bind an rvalue-ref to an rvalue-ref, not to suggest that's how it should be called.

At least "forwarding" specifies "for use in perfect forwarding", but it must be made clear that this term refers to the syntactic phenomena and they are not distinct from rvalue references.

I did not mean "any rvalue-reference" and bind to "any l- or rvalue", but that you can have an "int &&", "int& &&", "const int& &&", and even "int&& &&". I updated my comment to say "can be made from" instead "can bind to".

Your code example does not work because you call "foo" instead of "bar". But consider this one:

#include <iostream>

using namespace std;

template<class T> T bar(T&& i){ return std::forward<T>(i); }

int main() {

  int i=0;

  cout << bar<int&&>(6) << endl;

  return 0;

}

Not a bad article, but I'm so sick of the term "universal references". Perhaps useful for explaining things to the uninitiate, but a more technical understanding requires the knowledge that rvalue references can be made from any l- or rvalue.

So when I see "Don't let T&& fool you here - T is not an rvalue reference" -- yes it fricking is! And if you're going to work on a low enough type-level that you need perfect forwarding, you NEED TO KNOW THAT.

This was my thought as well. Sherlock's method can be seen as a special case of the scientific method that focuses on gathering all the facts before making your HYPOTHESIS. (You can't call it a theory until you've tested it, and even then, the theory explains the facts, not the other way around.)

Also, completely missing from this story is how deductions are made and the difference between deductions, hypothesis, and facts.

For example, fact: The message isn't sent. Deduction: cURL works, so the problem isn't the system. Hypothesis: The problem is in the API.

Nope. See the bottom item on the FAQ: https://github.com/neovim/neovim/wiki/FAQ#are-plugin-authors...

They'll work just fine, by being "transpiled".

The most popular neovim feature (based on reddit's reactions) seems to be job control, although not enough people are using it. You can start an asynchronous job via `jobstart('name', 'prog', ['arg'...])` which will return a job id. You can send data to the job via `jobsend(id, 'text'). Every time the program has some output available, it will trigger an autocmd to let you process it. (This happens synchronously.)

We have refactored some of the code base using modern coding standards, which makes it more hackable. Some of these systems have become more efficient by, for example, using pipes over temp files.

We accept upstream patches in order to stay on top of vim, so I hope that no one will ever not use neovim because of a feature lacking (aside from a GUI--see below).

neovim creates a socket for each instance that external programs can communicate with, allowing one to write a plugin or extension in any language, providing it has a msgpack implementation. These plugins may eventually control things like the GUIs, spell checkers, syntax analysers, allowing nvim to become more focused, like a micro-kernel.

As of right now, many people have switched without having any real problems.

You want either mem_fn (C++11) or mem_fun.

http://en.cppreference.com/w/cpp/utility/functional

> The sort of immutable container logic that people associate with FP is against the nature of C++...

My argument is that C++, a multi-paradigm language, benefits from not being bound to purity and that being able to mix imperative and functional code is a good thing. We aren't stuck in pure-land so we can insert IO where it needs to be, not where it propagates, but neither do we need to be stuck in state-land. Functional programming is not against the "nature" of the language, it gives us the freedom to choose.

> Because the first does not copy the container and its elements...

This is a quality of implementation detail. It would have been detrimental to the point of the article to waste time showing optimizations such as "if F is a function X to X, use the in-place version". But I assure you, my optimization testing has shown there is little difference between the code generated by this and vanilla <algorithm>. In fact, it is at times better.

https://github.com/splinterofchaos/Pure/blob/master/samples/...

Technically, those are free functions defined on strings, not members functions of the class string.

But also: std::to_string

http://en.cppreference.com/w/cpp/string/basic_string/to_stri...

This particular feature isn't offered by anyone else, so I would not write a program with it and force anyone else who wanted to compile the code to use an unsupported, bleeding edge version of GCC. But I /will/ create a branch of a project or two, using this auto deduction, and send bug reports back if necessary.

I, and many others, have been writing code in Clang and GCC for years that could not be compiled in MSVC. But that code was standard c++11. This is experimental and people should be aware of that while using it.

> Having said that, it sounds like if I just followed your advice above I may get the same results as I get from listening to the tracks getsomeheadspace provides.

Perhaps. Some like to listen to light jazz or classical music while meditating, but I like white noise, wind blowing, and passing traffic best. I think it's very important that you don't meditate in front of your computer because it puts your brain in a high-activity, instant-gratification mode, which is the opposite of what you want. Just the fan on my computer in enough to make me think about checking reddit or my email or whatever. Even something as simple as moving to a room you don't normally stay in can be enough to wind down your mind and become more relaxed.

> Meditation was a bit of mystery to me before watching them.

Meditation IS a mystery. If anyone ever tells you "IT IS THIS!", they are wrong. There are countless methods devised by people from all over the world and they all work. Some think you must lay down and listen to music. Others think you must sit cross-legged. Some even believe you must to it standing up! Some think you must count to ten, others say do it backwards. There are those who say think "nothing", and those who say think "anything". Some say "concentrate", some say "relax".

But the best advice I ever got: "Just sit."

They seriously want you to pay for meditation? That's absolute bull crap. The best advice I've ever gotten for meditation: Just sit. Make it at least 15 minutes. Maintain good posture; some of the positive effects of meditation relate to spending time with your spinal chord straight, stomach a little out, rib cage supported, leading to good blood flow to the brain. Let your mind wander, but don't lose focus of your posture.

It is said that when one is still for long enough, the brain switches modes. The unmoving mind. We spend all day interacting with the world, filling our brains with facts, experiences, feelings, etc. Take a step back and empty your mind. But don't pay money for it.

What a wonderful piece of programming history! This deserves more up-votes. How many programmers are alive today who can speak about their experiences in computer science in the 60's?