Earlier quoted context omitted.
This is what caught my eye too as being really ugly and hard to read. const map > TagDataMap { {"title" , make_tuple( 3, 30, stripnulls)}, Why can't the compiler figure out the types involved in this map structure itself? The user-defined functions are declared above, make_tuple will be declared in some library, and the others are string/int literals.
One thing you cannot do is infer `const`ness. This isn't a problem in Hindley-Milner systems because variables are not assignable--they're all `const`, all the time. Literals are inherently immutable but when you assign a C++ variable a literal value, sometimes you want a const variable and sometimes you don't. I don't think C++ can figure out the map part simply because lots of things could have list initializers th…
C++11 and Boost - Succinct like Python
141–150 of 172 posts
Re: C++11 and Boost - Succinct like Python
#142Earlier quoted context omitted.
I call shenanigans. That's true of simple scripts, I'm sure. But you can't seriously claim to me that you can understand decorator idioms, iterables or list comprehensions without a deep understanding of the language. What you say might have been true for Python c. 1998, it certainly isn't true today. Broadly: reading code is just hard. It's much harder than writing code. There are no non-trivial codebases that can b…
That is a given, I agree. But a complex program written in C++ (or using advanced C++ constructs) will scale much worse than a Python one, in my opinion.
Re: C++11 and Boost - Succinct like Python
#143Well, I liked C++11 a lot. But now I think I'll replace it with Go whenever possible. I don't really mind so much the verbose syntax. What matters is how difficult it is to write efficient code. I recently rewrote one of my C++ projects(which uses C++11 features and Boost.asio) in Go. It took me half the time, less than 2/3 lines of code compared to the C++ version. This is expected. But most surprisingly, despite th…
Go is certainly a fine language. One common instance where I would prefer C++, though, is when you are writing libraries for others to use. A language that runs on a VM can not easily be used as a library inside a language that uses another VM. You cannot easily write a library for Python in Go or vice versa. If you use a VM-less language like C or C++, your work can be used (through various wrappers, like SWIG or th…
Re: C++11 and Boost - Succinct like Python
#144Earlier quoted context omitted.
In most programming languages the [] operator allows one to access elements in a container. In this case, we are accessing the position "two colons minus one". I refuse to believe this makes any sort of sense for someone that has no deep knowledge of Python.
Lots of languages use [] with colon separators for array slicing, e.g. F#, Perl, Ruby. The idea that this syntax involves "deep knowledge" is laughable. Your criticism is analogous to me looking at "int* foo = bar()" and saying, hey, we're multiplying a type by a name! How ridiculous!
Re: C++11 and Boost - Succinct like Python
#145Re: C++11 and Boost - Succinct like Python
#146Earlier quoted context omitted.
Yeah, I agree with the claim that this is not in the same realm of readability (seriously, just consider for 10 seconds what an at-scale C++11 codebase looks like versus a scaled up python code base. But I understand why they're different and I can't get enough of the statically typed kool-aid lately.
I am picturing Python drowning in isinstance checks to avoid constant crashing every time a new function is added.
Re: C++11 and Boost - Succinct like Python
#147You will still need C++ for dealing with all the legacy C++ out there, but if you are starting a new project, you ought to be able to get the small, fast, efficient runtime advantages of a legacy monster like C++ from a much smaller, simpler language with a modern standard library.
Maybe it will be Go, but even if not, we need a simple, safe, productive language with modern features pre-installed (unicode strings, safe arrays, lists, maps) and a modern standard library that statically compiles to small, fast, native executables.
C++ with its "if you use the most recent 10% and pretend the old 90% doesn't exist, it's a great language" ethos is not what we need for new code.
Re: C++11 and Boost - Succinct like Python
#148It's succint, all right (well, sort of). But Python's major strength is readability, even more than coinciseness, or better, to provide both at the same time. C was born as a terse language, sacrificing readability for coinciseness (the original examples in K&R are incredibly succint, almost elegant, but far from readable). I can't see many improvements in C++ (a language that arguably has worse coinciseness than C,…
I call shenanigans. That's true of simple scripts, I'm sure. But you can't seriously claim to me that you can understand decorator idioms, iterables or list comprehensions without a deep understanding of the language. What you say might have been true for Python c. 1998, it certainly isn't true today. Broadly: reading code is just hard. It's much harder than writing code. There are no non-trivial codebases that can b…
Even now, I still like Haskell's
[fn(x) | x
over Python's equivalent [fn(x) for x in myList if x
Of course, I'm a mathematician, so that probably explains everything about my convoluted path of understanding these things, and my preferences to this day. :-)Re: C++11 and Boost - Succinct like Python
#149Earlier quoted context omitted.
The extra syntax is not there for nothing. It's adding type information. Thus allowing error checking or dispatching by type or optimisations at compile time. It is a cost in terms of syntax and readability but it's not for nothing. 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.
And this is where I decide the language is too far developed on the wrong foundation. 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.
Try to remember that Hindley-Milner is very hard to do outside of functional languages like ML and Haskell.
Re: C++11 and Boost - Succinct like Python
#150Is it too late for me to bang my Go drum? http://play.golang.org/p/53jSv32wSF (You can't access the filesystem on the playground, so it doesn't run.) * Look at that error handling. Mmmmhmmm, clear and explicit. If something goes wrong, I'll know about it. * Apart from, of course, errors that I ignore, such as when converting the year from 4 chars to an int (line 54). I don't care if I can't parse that. * Note the dif…
if err != nil {
return nil, err
}