4 ms·

Some resources for those who aren't too active in keeping up with C++, these slides are a good quick summary[0]. The talks linked on this page[1] are particular

Some resources for those who aren't too active in keeping up with C++, these slides are a good quick summary[0]. The talks linked on this page[1] are particularly good, especially the CppCon16 Gor Nishanov talk[2]. Paulo[3] has some interesting things to say (though I think some semantics may have changed since, so grain of salt and all). [0] https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-coroutines-a-negative-overhead- https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-cor... Interesting to note, slide #11 uses a tokenizer to demonstrate the usefulness of coroutines. IIRC, Rob Pike used a very similar (maybe his was a lexer/parser?) example in '14 re: Go. [1] http://luncliff.postach.io/post/exploring-msvc-coroutine http://luncliff.postach.io/post/exploring-msvc-coroutine [2] https://channel9.msdn.com/events/CPP/CppCon-2016/CppCon-2016-Gor-Nishanov-C-Coroutines-Under-the-covers https://channel9.msdn.com/events/CPP/CppCon-2016/CppCon-2016... [3]https://paoloseverini.wordpress.com/2015/03/06/stackless-coroutines-with-vs2015/ https://paoloseverini.wordpress.com/2015/03/06/stackless-cor... -- Side-note : Love it or hate it, the C++ community is certainly moving at a vibrant pace. I don't write production C++ code anymore (and haven't for a long time) but I still go out of my way to watch the CppCon talks. IMO, they consistently produce best quality talks just because you have so many excellent programmers from various industries using select subsets of C++ in all sorts of different ways. The people writing games are focused on making sure they're portable 'enough' to hit all the major platforms, without getting too tied to platform-specific low-level calls, while retaining the necessary performance to get satisfactory models/meshes/lighting/collision detection/raytracing/dozens-of-other-things completed within that tiny 16.33 millisecond gap to complete the framebuffer and swap in the next frame. The academics who are doing vast numerical computations will be talking about their new MPI utilizations (and undoubtedly, next years talk will be re: a boatload of RDMA/NUMA optimizations). People complain that C++ is a mishmash of too many concepts (pun not intended). I.e., you can write it in the "C with Objects" style, or the "I use TMP so much my code is basically Haskell", and anywhere in between - but it's that heterogeneity that ends up yielding such high caliber talks.

Cyph0n 9y ago
> People complain that C++ is a mishmash of too many concepts [...] but it's that heterogeneity that ends up yielding such high caliber talks. I agree. Scala gets the same kind of criticism, but just like with C++, you can easily limit Scala to whatever subset suits you (e.g., pure OOP or pure FP). C++ and Scala are among my favorite languages to work with, so I might be slightly biased :P
- pjmlp 9y ago
  Also if one looks at any successful programming language in the market that began by fighting complexity, it is easy to observe that they had to eventually embrace complexity to adapt and survive in the market of programming languages. Even if they kept the core simple, the complexity was shovelled into the libraries instead. For example, I doubt there is anyone able to know the complete Python 3.6.1 documentation by heart, plus all major libraries, tools and implementations. Yet it is touted as a simple language.
  - w_t_payne 9y ago
    It seems to me that the engineering trade-off is found in how we distribute complexity between: (1). The language itself. (2). The tooling (IDE, build system, linters etc...). (3). The standard library. (4). The ecosystem of third-party libraries. (5). The developer's application code. Moving complexity away from (5) might make applications smaller and easier to maintain, but it is done at the risk of increasing the training / learning burden on the development team. If too much complexity ends up in (1), then we create a barrier to entry for new developers and hiring becomes harder. If too much complexity ends up in (4), then we end up with endemic not-invented-here syndrome, because it becomes too hard to learn new libraries. It seems to me that a lot of this is driven by learning and learnability -- any educational specialists around who want to wade in on this discussion?
    - pjmlp 9y ago
      A good example is music. Yes knowing how to play scales and reading notes might seem easy, but mastering an instrument and its variations (e.g. string instruments) takes a whole life.
- JustSomeNobody 9y ago
  Kotlin has been in everyone's ear lately and it gets praised for borrowing concepts from many different languages. Sigh. Go figure.
  - 9y ago
imron 9y ago
Link [0] is broken. It's missing 'abstraction' at the end.
Curbfoot 9y ago
Link [0] is broken / missing one word at the end. iheartmemcache probably meant: https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-coroutines-a-negative-overhead-abstraction https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-cor...

Cyph0n 9y ago

> People complain that C++ is a mishmash of too many concepts [...] but it's that heterogeneity that ends up yielding such high caliber talks. I agree. Scala gets the same kind of criticism, but just like with C++, you can easily limit Scala to whatever subset suits you (e.g., pure OOP or pure FP). C++ and Scala are among my favorite languages to work with, so I might be slightly biased :P

pjmlp 9y ago
Also if one looks at any successful programming language in the market that began by fighting complexity, it is easy to observe that they had to eventually embrace complexity to adapt and survive in the market of programming languages. Even if they kept the core simple, the complexity was shovelled into the libraries instead. For example, I doubt there is anyone able to know the complete Python 3.6.1 documentation by heart, plus all major libraries, tools and implementations. Yet it is touted as a simple language.
- w_t_payne 9y ago
  It seems to me that the engineering trade-off is found in how we distribute complexity between: (1). The language itself. (2). The tooling (IDE, build system, linters etc...). (3). The standard library. (4). The ecosystem of third-party libraries. (5). The developer's application code. Moving complexity away from (5) might make applications smaller and easier to maintain, but it is done at the risk of increasing the training / learning burden on the development team. If too much complexity ends up in (1), then we create a barrier to entry for new developers and hiring becomes harder. If too much complexity ends up in (4), then we end up with endemic not-invented-here syndrome, because it becomes too hard to learn new libraries. It seems to me that a lot of this is driven by learning and learnability -- any educational specialists around who want to wade in on this discussion?
  - pjmlp 9y ago
    A good example is music. Yes knowing how to play scales and reading notes might seem easy, but mastering an instrument and its variations (e.g. string instruments) takes a whole life.
JustSomeNobody 9y ago
Kotlin has been in everyone's ear lately and it gets praised for borrowing concepts from many different languages. Sigh. Go figure.
- 9y ago

imron 9y ago

Link [0] is broken. It's missing 'abstraction' at the end.

Curbfoot 9y ago

Link [0] is broken / missing one word at the end. iheartmemcache probably meant: https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-coroutines-a-negative-overhead-abstraction https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-cor...