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.
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.
I'm not willing to say that dynamically typed languages are more expressive. It's hard to compare two languages and just say "A is more expressive than B." Usually they just express different things with different degrees of conciseness. (In particular, Brainfuck is not concise. It has a small grammar, but an equivalent print statement has much more room for error, since it takes a longer string of obfuscated code to produce.)
My point is that the _goal_ of expressiveness is still there and still valuable. We need languages that express our intent safely, clearly, and quickly. The better this is achieved, the less debugging you have to do -- because, by definition, the code will express what you want more clearly and with less room for error.
>It's not what language you use, but /how/ you use it.
How you use a language is determined by the grammar of that language. So I don't see any value in your point here, save for trying to dodge specificity and feign wisdom.
I agree with your skepticism of the idea that that dynamically typed languages are more expressive. It is not as if we are writing poetry here; we are actually trying to specify, with great accuracy, a virtual machine. Fortunately, we can state for sure that there is no fundamental difference between the capabilities of Turing-equivalence languages; if this were not the case, the arguments over expressiveness would be interminable.
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.
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.
> So when I see "Don't let T&& fool you here - T is not an rvalue reference" -- yes it fricking is!
T&& is only an rvalue reference when T is a non-lvalue-reference type. If T = U& then T&& = U& because of the reference collapsing rules. If you're saying that you should understand how type deduction works and interacts with reference collapsing if you're going to write C++11 then I agree. Like much of C++, perfect forwarding's design is an ugly mess and is not amenable to a superficial understanding unless you like shooting yourself in the foot.
At C++Now 2014 there was some agreement on renaming 'universal references' to 'forwarding references'. Apparently, Scott Meyers, the guy that came up with the term universal references, even agreed to update his upcoming book with the new term.
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;
}
Maybe you're confusing reference collapsing with universal references?
In your example, replace bar<int&&>(6) to bar<int&&>(i).
It won't compile because i is not an r value. bar(i) will compile, because the template parameter is a universal reverence that will become an lvalue (not an rvalue) through reference collapsing.
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.
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.
No, Vim plugins wouldn't work anymore. Vimscript will be transpiled to Lua under the hood, though, and other languages will be fully supported for writing plugins.
> 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.
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.