Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++11 and Boost - Succinct like Python

fendrich.se

Post reply on HN
Print view View original

131–140 of 172 posts

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

#131

Post by Peaker »

undershirt wrote: post #66
ajross wrote: 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…

Here's an example: A co-worker looked at a function I wrote that converts a table to a tree, and he said to me, "I thought Python was supposed to be readable, but I have no idea what this is doing." See for yourself: https://gist.github.com/3988350

Manually capturing free variables via:

  def __init__(self, x, y, ..):
    self.x = x
    self.y = y
Is so tedious and DRY-violating.

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

#132

Post by Peaker »

sremani wrote: post #81
ifij775 wrote: post #13

The changes to C++ are too little, too late. These changes should have been made years ago, and C++ has lost momentum and credibility. Is anyone comparing Python to c++? nope, only the other way around.

C++ does not need the credibility. Hey, in what language is your Python compiler written in C/C++. When performance is the criteria C++ will shine. The world runs on C/C++, this comes from a C# developer.

CPython is written in C, not C++. Two very different languages.

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

#133

Post by danking00 »

fusiongyro wrote: post #115
Locke1689 wrote: post #104

Earlier quoted context omitted.

Just to elaborate on what danking00 is saying, the extra syntax in this case is not adding any extra information (to the compiler). The left hand type of the expression can be completely inferred at compile time, in this case. What that required syntax is adding is pain, but no gain (except for imperceptibly faster compile time). In Haskell this would look like: TagDataMap = [ ("title", ((3, 30, stripnulls)), ("artis…

"the extra syntax in this case is not adding any extra information (to the compiler)." This actually isn't true in C++, because there could be many classes in scope that could take a list initializer like this. In Haskell, no literal with [] can "turn into" something besides a list, but that can happen in C++: vector items = {1,2,3,4}; int[] items = {1,2,3,4}; These have different types, so how would C++ know which o…

Your example,

    void foo() {
      auto items = {1,2,3,4};
      return;
    }
is the case of poorly designed syntax, in a truly Hindley-Milner system there is no expression which doesn't have a type. Now, we could add some syntax that screws that up, say:

    let v = I-HAVE-AN-AMBIGUOUS-TYPE in 0
But that's rather silly, isn't it? If a value isn't used then I would, personally, like my language to optimize it away. So why not ditch such silly syntax?

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);
which expands to something like:

    auto items;
    items.push_back(1);
    items.push_back(2);
    items.push_back(3);
    items.push_back(4);
If you're interested in true syntactic macros for non-sexp languages (though I do suggest getting over the parentheses, my color settings make them nearly indistinguishable from the background) look at Rust [1].

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/

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

#134

Post by LnxPrgr3 »

daivd wrote: post #109
mattgreenrocks wrote: post #93

Earlier quoted context omitted.

Too little, too late? There's no zero sum game here. Perhaps you're conflating Internet-popular (which doesn't mean shit) with useful?

Internet popular means libraries on github and good tutorials, means useful.

Are you suggesting C++ lacks available libraries? Because for all of its faults, lack of libraries is not one I've run into.

Many desktop and server applications are still written in C or C++, including the Web browser I'm writing this on. Reports of their deaths are exaggerations.

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

#135

Post by fusiongyro »

danking00 wrote: post #133
fusiongyro wrote: post #115

Earlier quoted context omitted.

"the extra syntax in this case is not adding any extra information (to the compiler)." This actually isn't true in C++, because there could be many classes in scope that could take a list initializer like this. In Haskell, no literal with [] can "turn into" something besides a list, but that can happen in C++: vector items = {1,2,3,4}; int[] items = {1,2,3,4}; These have different types, so how would C++ know which o…

Your example, void foo() { auto items = {1,2,3,4}; return; } is the case of poorly designed syntax, in a truly Hindley-Milner system there is no expression which doesn't have a type. Now, we could add some syntax that screws that up, say: let v = I-HAVE-AN-AMBIGUOUS-TYPE in 0 But that's rather silly, isn't it? If a value isn't used then I would, personally, like my language to optimize it away. So why not ditch such…

Having programmed Haskell for the last seven years (and C++ for zero) I have a fairly decent handle on what HM is all about. If all you had said is that the foundations of C++ are too far gone, there wouldn't be anything to discuss. But the foundations of C++ being what they are, there's no point being offended when unfixable things go unfixed. I love HM, but you can't just throw it in any old language simply because it's cool. The language's semantics need to allow for it, and they just don't with C++.

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

#136

Post by longlivedeath »

daivd wrote: post #105
danking00 wrote: post #90

Earlier quoted context omitted.

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.

Even in Hindley-Miller type systems it is considered good practice to add types as documentation to top-level constructs (see Haskell). In Python it is also considered good practice to add argument and return type info in the doc string. In a dynamic language you would also have to add a unit test or two for cases for some of the things that the compiler can catch for you. Looking at the complete picture makes a lang…

> it is considered good practice to add types as documentation to top-level constructs

But with type inference your tools can do that for you (e.g. C-u C-c C-t in haskell-mode).

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

#137

Post by mattgreenrocks »

daivd wrote: post #109
mattgreenrocks wrote: post #93

Earlier quoted context omitted.

Too little, too late? There's no zero sum game here. Perhaps you're conflating Internet-popular (which doesn't mean shit) with useful?

Internet popular means libraries on github and good tutorials, means useful.

Unfortunately, many programming tutorials are written by an intermediate for a beginner. This means they can only take you so far. Thankfully, C++ is so old that there are quite a few superb books on both the language (and it's many pitfalls) and applying the strengths to build large scale, maintainable programs.

I'll take that over a tutorial any day.

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

#138

Post by songgao »

drivebyacct2 wrote: post #78
songgao wrote: post #32

Earlier quoted context omitted.

It's not essentially threads since multiple goroutines are mapped onto one thread (or more if set). It feels like threading but you could just use it as much as you need since it doesn't bring as much overhead as a thread :-) Check this out: http://en.munknex.net/2011/12/golang-goroutines-performance....

Sorry, that was my point. The new concurrency stuff in C++11 still isn't the same as go's goroutines. Certainly my application would not work very well if a goroutine mapped to a thread. :o

Aha, I got you now :-)

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

#139

Post by Evbn »

eru wrote: post #128
derleth wrote: post #94

Earlier quoted context omitted.

> The extra syntax is not there for nothing. 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. https://sites.goo…

But aren't all allocation styles basically the same once you get GC? (I guess unless you broaden the scope of the word, and let it describe the lengths you go in Haskell to avoid allocation at all, aka triggering stream fusion and automatic deforrestation in general.)

There are other issues: Go has stuff like slice for efficiently allocating array data more finely than a Java array, perl has autovivication.

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

#140

Post by Evbn »

drivebyacct2 wrote: post #86
alpatters wrote: post #74

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.

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.
Post reply on HN