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

161–170 of 172 posts

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

#161

Post by lmm »

ajross wrote: post #34
Kurtz79 wrote: 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…

List comprehensions read like what they are (except for the stupid backwards order if you have multiple 'for's).

Decorators are pretty opaque; idiomatic python makes minimal use of them, and uses them only for things that don't change the meaning of the method inside. I've never used @classmethod and hope to never have to. I don't think it's fair to compare to an STL iterator, which is something you're encouraged to use as much as possible.

I don't know what you're talking about for iterables; aren't they obvious?

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

#162

Post by [deleted] »

danking00 wrote: post #158
codewright wrote: post #149

Earlier quoted context omitted.

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.

Yes type inference is harder with C++'s language design (OO comes to mind as a particular problem), thus my claim that it's the wrong foundation to build on. Of course, people like challenging problems and are working to bring more type inference to OO languages [1]. Furthermore, I assert that this truly is the wrong foundation. For new projects that must have OO, Scala provides local type inference and object orient…

[deleted]

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

#163

Post by lmm »

alpatters wrote: post #46
huhtenberg wrote: post #9

cout I'm sorry, but as "succinct" as it is, this is basically an unreadable bullshit. Reminds me strongly of a macro abuse in C.

you might not like the syntax of this particular boost lib, but it bears no relation to macro abuse in C. For one it is strongly typed. Of course it is unreadable if you don't know C++ or boost range. But it is not more complex than a python map or filter with a lambda, if you don't know python.

It is visibly worse than python. '|' - I thought that was bitwise or? - rather than an (admittedly technical) English word like 'map' or 'filter' (and '<<' has the same problem). 'transformed([](pv){...})' may be necessary for compatibility, but the brackets are harder to follow than 'transformed(lambda pv: ...)'. And the type declaration as "propMap::value_type" is just noise - it doesn't tell the reader anything about what the actual type is, and it isn't necessary for static typechecking either (it would be optional in a modern statically typed language e.g. Scala).

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

#164

Post by comex »

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…

It's possible to do exactly that (a function that initialized a vector with its arguments) in C++ with variadic templates...

You might end up in trouble if you did something like

    auto v = vec(
                  vec(1.2, 3.4),
                  vec(0)
                )
not sure how well other languages deal with that.

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

#165

Post by fusiongyro »

Peaker wrote: post #157
fusiongyro wrote: post #155

Earlier quoted context omitted.

They're not worth discussing because they're a counterintuitive mess rather than a case study of the glory of HM. Maybe edge case isn't the right word, but they're definitely not something I would hail as a perfect resounding success. 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 f…

> They're not worth discussing because they're a counterintuitive mess 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 conf…

The distinction between your point and mine is becoming miniscule, but I must defend my position on Haskell, as a heavy user myself. If Num doesn't seem to be a problem to you, it's because you supply top-level annotations that disambiguate it. Try removing all the annotations from whatever you did last week and see if it still compiles cleanly. I'd wager it doesn't. This isn't an issue in practice because we supply annotations in most cases, but don't be fooled: top level annotations, despite the rhetoric, actually are essential for modern Haskell programs to disambiguate. As for strings, the problem doesn't appear in practice because people mostly don't intermingle string types in the same module. That's what makes Num tricky; it's easy to find yourself with Ints and Integers together, wanting to divide them and get a float, and figuring out how to resolve these minor issues is significant for learners. Just ask my friends!

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

#166

Post by longlivedeath »

lmm wrote: post #159
longlivedeath wrote: post #136

Earlier quoted context omitted.

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

A good IDE can fill in the types in C++ too.

Is there a C++ IDE that can figure out the function signature after you have written something like

_ f(_ a, _ b, _ c) { YOUR; CODE; HERE; }

?

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

#167

Post by [deleted] »

danking00 wrote: post #90
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.

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.

[deleted]

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

#168

Post by Peaker »

lmm wrote: post #160
Peaker wrote: post #131

Earlier quoted context omitted.

Manually capturing free variables via: def __init__(self, x, y, ..): self.x = x self.y = y Is so tedious and DRY-violating.

This is true. I'd prefer scala-style constructor syntax - though I'm not sure how you could retain python's wonderful symmetry between constructors and methods, and the distinction between allocation and initialization.

I don't know Scala, but the Erights language does something like (pseudo-syntax):

  def Circle(center, radius):
    circumference = 2 * pi * radius
    return object:
      to getCircumference():
         return circumference
      to ...
The "self" is the lexical scope. Simple and more effective than Python's method, IMO.

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

#169

Post by Peaker »

fusiongyro wrote: post #165
Peaker wrote: post #157

Earlier quoted context omitted.

> They're not worth discussing because they're a counterintuitive mess 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 conf…

The distinction between your point and mine is becoming miniscule, but I must defend my position on Haskell, as a heavy user myself. If Num doesn't seem to be a problem to you, it's because you supply top-level annotations that disambiguate it. Try removing all the annotations from whatever you did last week and see if it still compiles cleanly. I'd wager it doesn't. This isn't an issue in practice because we supply…

This is one of the files in a project I've worked on last week.

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
Once I removed the type declaration, I made it work again by adding a parameter to avoid the MR:

  showP x = parenify (show x)
and everything compiles smoothly.

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.

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

#170

Post by ajross »

lmm wrote: post #161
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…

List comprehensions read like what they are (except for the stupid backwards order if you have multiple 'for's). Decorators are pretty opaque; idiomatic python makes minimal use of them, and uses them only for things that don't change the meaning of the method inside. I've never used @classmethod and hope to never have to. I don't think it's fair to compare to an STL iterator, which is something you're encouraged to…

The iterable point was that the syntax is obvious but the behavior is not. They "look like plain data" sometimes, and some times they don't; and the only way to tell the difference is to know the characteristics of what you are iterating over. They're the same kind of too-clever-by-half design that C++ tends to confuse people with. People who know it love it, and people who don't think it's voodoo.
Post reply on HN