So for correct programs the end result might be the same in terms of values. For buggy code and runtime speed that's not necessarily the case.
Nobody would argue that C++11 code can be much cleaner than old C++ code. But to say it's almost as clean as Python goes to far, and isn't fooling anybody. So why not be satisfied beating old C++?
I cannot put up with type systems that don't have complete or near-complete type inference. I don't know why one would start a new project in a language that didn't support Hindley-Milner.
In Haskell this would look like:
TagDataMap = [
("title", ((3, 30, stripnulls)),
("artist", ((33, 30, stripnulls)),
...
Ok, technically this is an associative list, not a Python dictionary, but it is a map and can be accessed like one. Hell, most people use dictionaries with less than 10 items, which are much slower than arrays most of the time
vector<int> items = {1,2,3,4};
int[] items = {1,2,3,4};
auto items = {1,2,3,4};
Edit: Just to clarify, in a Hindley-Milner system you could maybe get away with something like that, but everything you name in an HM system you must use, and that isn't the case in C++:
void foo() {
auto items = {1,2,3,4};
return;
}
struct FooClass {
FooClass(std::initializer_list<int> list) {
cout << "Made a Foo!" << endl;
}
};
struct BarClass {
BarClass(std::initializer_list<int> list) {
format_your_hard_disk();
}
};
This might be a convoluted example, and it may be flawed, but conjuring up others is not hard and demonstrates that C++ simply cannot ever have true HM type inferencing. Since the "real deal" is not possible, the language is complex and the standard is large, I would not expect to be able to live without annotations in C++-land. (Again, the FQA makes the horror of multiple non-orthogonal solutions to the same problems quite clear).
C++ could also type its list initializers with some polymorphic type (similar to Haskell's Num) but didn't do so.
This is not inherent.
There are no polymorphic literals in ML, just polymorphic math operators, which is enough of a blight on the standard that OCaml discarded it and forces you to use different operators for real and integer arithmetic. And there's only one kind of string in both MLs.
Haskell's Num hierarchy is troublesome. They traded usability for + with complexity for /. It's extremely unlikely that you could write a program in Haskell that does much arithmetic and have it build correctly on the first try without any manifest typing. This is one reason students of Haskell find things so confusing: type declarations are necessary at the top level simply because the extensions and complexity of modern Haskell break HM if you try using it everywhere. Also, the class system in there is not especially mathematically correct, which leads to the numerous replacement Preludes that try to do a better job but haven't caught on.
Strings are edge cases because they are not polymorphic unless you enable OverloadedStrings. Once you do, you will either replace the built-in string with something else (ByteString or Text) or find yourself in the same kind of trouble you'd be in with Num.
Let me be clear: I'm not saying that these problems are showstoppers. They're really minor annoyances once you're experienced, though they contribute to confusion for beginners. The point I'm trying to make is that you can't just drop HM into any old language and expect it to work. A greater point would perhaps be that all languages have warts simply because they're large, complex beasts (Haskell and C++ especially) and it's unproductive to point to a missing feature in one and demand some sort of perfected version of the other's.
Do you really believe Num overloading is a counterintuitive mess? I disagree completely.
> OCaml discarded it and forces you to use different operators for real and integer arithmetic
Which is pretty terrible.
> Haskell's Num hierarchy is troublesome.
Yes, but that's an orthogonal issue.
> This is one reason students of Haskell find things so confusing: type declarations are necessary at the top level simply because the extensions and complexity of modern Haskell break HM if you try using it everywhere
That sounds like FUD to me, a heavy Haskell user. Type declarations at the top-level are generally necessary to avoid the dreaded MR and for documentation purposes. Modern Haskell doesn't heavily use extensions that require type annotations on the top-level.
> Strings are edge cases because they are not polymorphic unless you enable OverloadedStrings. Once you do, you will either replace the built-in string with something else (ByteString or Text) or find yourself in the same kind of trouble you'd be in with Num.
It lets me use literals for Lazy Text, Strict Text, and String with the same syntax, which is nice.
My point is merely that giving a type to a polymorphic initializer is possible, and C++ chose not to.
https://github.com/Peaker/bottle/blob/master/codeedit/Editor...
I removed all the top-level type declarations, and only one definition broke, because of the MR.
showP :: Show a => a -> String
showP = parenify . show
showP x = parenify (show x)
Feel free to browse the bottle repo -- and try to build it without top-level declaration. Apart from a few functions in the entire project that use Rank2, you won't need any declarations.
This is very good code.
One difference I see between our styles that may explain the differences in behavior we see is that you're quite meticulous about importing only the parts of modules you need, and you make heavy use of qualified imports. My style has been to import everything in case I need it later and only use qualified imports when absolutely necessary, and it must be creating the unnecessary ambiguity that I have to deal with. I will try to adopt your style and see if it cleans up my error messages, and I'll encourage my friends to do the same.
void foo() {
auto items = {1,2,3,4};
return;
}
let v = I-HAVE-AN-AMBIGUOUS-TYPE in 0
This is part of why I said that the foundations of C++ are too far-gone.
And this syntax isn't necessary to save on typing. In a language that supported syntactic macros (such as Scheme or Racket) we could write something like:
auto items = my-vector-syntax(1,2,3,4);
auto items;
items.push_back(1);
items.push_back(2);
items.push_back(3);
items.push_back(4);
Actually, Rust also has type inference [2].
Hell, stop programming in C++ and start using Rust! [3]
[1] http://dl.rust-lang.org/doc/tutorial-macros.html [2] http://dl.rust-lang.org/doc/0.4/rust.html#type-system [3] http://www.rust-lang.org/
I suggest using a HM language when you start a new project.
You might end up in trouble if you did something like
auto v = vec(
vec(1.2, 3.4),
vec(0)
)
Looking at the complete picture makes a language with local type inference (like C++11) more or less as verbose as one with complete type inference.
But with type inference your tools can do that for you (e.g. C-u C-c C-t in haskell-mode).
_ f(_ a, _ b, _ c) { YOUR; CODE; HERE; }
?
Try to remember that Hindley-Milner is very hard to do outside of functional languages like ML and Haskell.
Furthermore, I assert that this truly is the wrong foundation. For new projects that must have OO, Scala provides local type inference and object orientation. If you're really hurting for some manual memory management, look at Rust [3] or Habit [2].
If we can recover the features we love on a new foundation that provides new features like type inference or memory-safety, then we've found a better foundation, IMHO.
[1] http://www.cs.ucla.edu/~palsberg/typeflow.html
const map<const string, const tuple<int, int, StrToStr>> TagDataMap {
{"title" , make_tuple( 3, 30, stripnulls)},
I don't think C++ can figure out the map<..> part simply because lots of things could have list initializers that accept lists of 2 item lists. C++'s overloading and implicit conversion conflicts with perfect type inferencing. This is an example of the kind of thing the FQA talks about, where several of C++'s issues collide to produce counter-intuitive behavior.
I do wonder if you could get away with this:
const map<const auto, const auto> TagDataMap { ...
const auto TagDataMap = map_initializer( { "foo", { 1, 20, func }, ... } );
In real C++ code, this would almost never be what you actually want, though, as the types in an initializer list in C++ do not imply the types being initialized, they are parameters to a constructor to be determined elsewhere.
You could say the same thing about everything old C++ compelled you to type. Or old COBOL, for that matter.
I'm more interested in what the C++ memory allocation style does to verbosity. Memory-handling styles are often more important than the traditional paradigms (functional, OO, etc.) in determining what's reasonable/pleasant to do in a given language.