Live data from Hacker News

C++11 and Boost - Succinct like Python

fendrich.se

141–150 of 172 posts

Re: C++11 and Boost - Succinct like Python

#141

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…

It would help a lot if the keyword 'const' were replaced by a punctuation character or shorter simpler keyword like 'val'

Re: C++11 and Boost - Succinct like Python

#142
post #37
post #34

Earlier 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.

RuntimeError: cannot add String and Integer

Re: C++11 and Boost - Succinct like Python

#143
post #16
post #12

Well, 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…

I have worked on a large C++ program that uses Python for UI and some scripting components. I don't see why it would be harder for Go to use Python. Also, Lua is used everywhere.

Re: C++11 and Boost - Succinct like Python

#144
post #100

Earlier 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!

Well, that is ridiculous. It makes the language literally impossible to parts without context-sensive semantic analysis. Go Language fixes that bug by always having a type name first or a colon after introducing a variable.

Re: C++11 and Boost - Succinct like Python

#146
post #140

Earlier 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.

I'm just imagining how many nights in a row I've committed more lines of code than exist in my project in a snapshot because it's so damn confusing, interconnected, and concurrent. The thought of doing it in a dynamic language is downright nauseating.

Re: C++11 and Boost - Succinct like Python

#147
Periodically throwing some new ingredients into old soup to freshen it up can only extend the life of leftovers so far. There comes a time when, even with a handful of fresh veggies, it's no longer good soup. You need to toss out the leftovers, scrub the kettle, and start a fresh batch.

You 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

#148
post #34
post #27

It'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…

Ironically, I didn't understand Python's list comprehensions until I learned about Haskell's version (which is the original source of Python's), along with the explanation that Haskell's list comprehensions are taken straight from mathematics. Indeed, Haskell's version are almost ASCII-art mathematical set notations.

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

#149

Earlier 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.

Wrong foundation? No. Foundation you don't want? Sure.

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

#150

Is 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…

Having this all the time seems really verbose compared to exceptions:

    if err != nil {
        return nil, err
    }
Post reply on HN