Відео

A perfectly crafted presentation. Three thumbs up.

C++ -> CppFront

35:27 - I've noticed that everyone apologizes when I get their old code. It's never, "Hey, this thing is cool, have fun!"

1:25:59 I think the _Psi_ combinator has the same typo as earlier, where the left x should be w

After C++ will be Cext/C++ext . Those are small extensions to C. Extansion small but powerful.

C++ syntax final boss :)

Very interesting talk! The long-term memory + pattern aspect was new to me in this context, but really explains a lot. For example why it can be so annoying to read code with the 'wrong' formatting/style!!! The brain just gets distracted by the micro-analysis required instead of just matching the patterns. Of course good naming is crucial for the same reason - making the beacons obvious, rather than requiring micro-analysis.

Last time I peeked I saw three sad nerds mumbling something about "no diagnostic required"

After fighting this for quite a while I came to the conclusion that the only way is to NOT have global state. What this boils down to: in the example at 51:40, the user has to be ALLOWED to create a second instance of 'api' and have it work independently I often wonder why this (my) thinking is not common practice

38:20 “… You only need as much temporary storage as you have physical threads that will be active” - note that threads that are stuck in wait_for_predecessor_prefix (the latency hiding feature) will also consume their temporary storage while they are waiting - I guess they are considered “active”.

51:05 [right vs. write] I think he said “..so the interval on the left is what we’re going to use for the *write*”

The question is it will take decades to make shift all legacy from C++ to Carbon

30:00 Combinator = Composition Pattern

thank you!

Pointless addition to the language. Violates the rules of structured programming and enabled spaghetti code.

when will it be ready for production usage?.

Nice intro talk. Now I am interested in looking into Nix

I think it is worth giving some mention that on the front of static typing Rust actually is meaningfully stronger than C++, as C++ number types internally behave like a dynamic typed language, which can turn into surprises.

Exactly what I was looking for Thanks 🙏

Super informative

In the future they will look back at the last 50 years of computer programming and think of it as the Dark Ages: a time of confusion, superstition, tribalism and madness. This is not a joke or a criticism of the lecture. As an industry we are constantly making up new ways of telling ourselves we are in control, but in reality it is a Tower of Babel.

Amazing presentation ❤

With all humility, not wishing to imply that I have his greatness (or indeed anything more than glints of occasional competence)... Late in his career, Neil Peart took drum lessons -- in jazz. So it might also be for me, coming from a procedural/object-based background (heavy on the former), as I take the plunge into functional /combinatorial. I find it all very intriguing. Thanks to Conor and everyone for the talks.

I don't like C++ but I do like listening to Kate Gregory.

That fromEnum solution is absolutely awful and haskell does have a count function... Not like you couldn't have defined it yourself

The definition of pure function and distinction isn't really correct. A combinator is a pure function that is not a closure, that's it.

Really good talk!

00:00:12 Rust foundation be like: "What did you just say??? I haven't heard you ask for permission"

Conor is easily one of the best programming speakers! Combinatorial logic and array programming are such interesting subjects. Keep up the great work!

Amazing!

What about any of this is "experimental"? They just took elements from the most popular langauges and put them into their langauge. Its not even that they took parts from several radically different langauges and the combination of those is a unique product, its just a subset of other popular languages. They only call it "experimental" as to qualify their claim of being a successor to Cpp, as to not sound as arrogant.

Same as the new Zig Language you're using the massive LLVM Libraries. An LLVM-only build requires anywhere from 1 to 3 GB of space on any machine. A full build of LLVM and Clang will need around 15 to 20 GB of disk space. The exact space requirements will vary by system but damn. They claim it's so large because of all the debugging information and the fact that the libraries are statically linked into multiple tools. I call that "Organized Despair". No Offence, however just before using Carbon for your own Application Builds, your using a Program that is ten times larger than a Linux Ubuntu OS just to achieve it. You would be much better off to have gone with a Python Like Approach using C++ as a base language with an Interpreter instead right?

I don't know if he's trying to sensationalize this talk or if he's received brain damage in the past couple of years, but there are several "points" he makes that are just wrong. For starters, outside of niche mathematical uses, overflow isn't a problem, and in those instances where it could be a problem you can detect overflow yourself before causing it and thus prevent even the possibility of ill effects. Part of the problem I see relating to it is people not checking user input, and if you're not checking user input then you probably shouldn't be a programmer. As far as sorting floating point data, you can provide your own comparator if you don't like what the default does, but there's nothing in the standard preventing you from calling std::sort() on such arrays. And I'm going to skip all the rest to say that no language should have an unsafe keyword. That's the kind of garbage that gives newbies a false sense of security which causes even worse subtle bugs to crop up. No programming language should constrain programmers like that. Far too many new languages keep popping up that constrain you in ways that prevent valid use cases and try to push this propaganda that it's justified because it prevents bad programs, even though there are whole classes of problems that they do nothing to prevent and which can be far more pernicious than the classes of problems they do prevent. But ultimately, if you want to constrain code that scares you into "unsafe" sections, use a static analyzer, as there are many to pick from, including free and open source analyzers, and just add a comment around that code labeling it unsafe.

Futhark sample: let SumOfSquares a = map2 (\x i -> if length a % (i+1) == 0 then x*x else 0) a (indices a) |> reduce_comm (+) 0 This isn't point free but does use three different combinators. |> could be replaced by reordering with parenthesis, but the map-reduce array combinators are the expected way to handle arrays. The filter was avoided using a neutral element, because realizing the filtered list could cause multiple heavier passes.

Nice talk but wrong in so many ways that I am not interested to discuss. It its a very opinionated talk about what are the strength of C++. Lot's of love for auto but no mentioning what so ever for smart pointers, which are way more important to write sound code. And being standardised isn't really helping in writing good software. It is just helping in writing portable software. And it is somewhat dismissed by available compilers not implementing standards. Most of the time you need to figure out by experiment what your C++ compiler is able to do. Programming languages where there is only one compiler available, which is constructed by the people designing the language, set their standards by implementation. I prefer that way. I never was disappointed by a rust or swift compiler - but I found that I was very dependent on the specific version of gcc or clang to use C++ "standard" features. E.g. C++ has modules since C++20, but even setting your compiler standard to c++23 won't make it work with cmake, as the way to process modules and link to them is very compiler specific. As of now it isn't something to rely on for production code, at least not of production code supposed to be portable. If one goes into the list of supported C++ features of gcc or clang on the internet, one will find a mess. Standards do not help C++ as compiler vendors seem to adopt to them just as they feel like it.

8:40 they did not fix it in post

No one got the joke, 1420 is not 420. 20:55

I simply cannot believe that people are using anything other than C linkage on the API boundary. Using C++ types just leads to eventual misery, and is holding the language back because now nobody wants to break ABI.

Wonderful talk. I completely agree on using asserts and also making sure they don't change algo complexity. For developer time, it is one of the most efficient ways to (partially) verify correctness.

life after c++, it's fun to dream, although I'd be happy if there was only C and assembly, have we ever really needed anything else?

superb talk !!

34:55 most important statement of the whole talk? Because so much other stuff follows from this seemingly innocuous statement.

12:00, *1888. 15:34, what?! Do you know any other kind of software they are willing to pay millions? 38:30, to map true/false keeping their positions/indexes. If that's not required, std::partition puts all trues at the beginning, returning a pointer to where they finish and to where the falses start. And std::stable_partition, despite obviously not keeping their indexes, keep their positions related to each other, at each group. 56:00, auto sum_of_squares (std::vector<int> nums) {return std::accumulate (nums.begin(), nums.end(), 0, [](auto x, auto i) {return !(nums.size() % i)*x*x;});}

Good clear points. On another hand, it's a bit depressing how 20 years of the language went into just getting rid of redundant typing in C++03 for loops with a bunch of new concepts and new syntax. And it skips all the gotchas along the way.

So my take away from all this is that C++ has an ugly syntax, C++ is overly complex, C++ is not safe in anyway. Likely none of this can be fixed. Makes me feel OK that after decades of using C++ I gave up in disgust a few years ago and moved on. It's good to know smarter people than me feel the same.

Hoekstra family sounds like one of the scariest families. Three children who can APL and work with data and numbers.

Is it "undefined behaviour" to use a cursor from one sequence onto another sequence? e.g., `flux::inc(seq2, flux::first(seq1))`

Great explanations. Thank you for sharing❤

At 22:00 I have to question the sanity of a person who writes (or rather generates) such code and calls it a feature of a modern language. If you can't do it in C, you're simply doing it wrong 😉

I owe my career to "this should work". As an autodidactic programmer, everything I've done in my career started out as something I didn't know how to do, but believed it could be done. If I ever really doubted it, I couldn't have accomplished it.