Tuesday, 8 April 2025

ACCU 2025

 I spoke at ACCU 2025 this year. It took place in Bristol, but was hybrid, so I also gave an online poster presentation. 

The schedule is here: https://accuconference.org/2025/schedule. The opening keynote was given by Anastasia Kazakova about  The Next Coding Horizon: Proactive LLMs for Enhanced Productivity. She shared some stats about what tools etc programmers are using and told us some Jetbrains tools related to LLMs. Anastasia kept telling us to wait for more details at Daisy's keynote talk on Thursday. 

I went to Heaps Don't Lie - Guidelines for Memory Allocation in C++ by Mathieu Ropert next, which talked through malloc being slow and some alternatives, which ended up being worryingly close to writing your own malloc! Meanwhile, Dom Davies filled a slot in the room next door, because the intended speaker couldn't make it. He played some music which almost drowned out Mathieu, who handled this very well. 

Mathieu pointing out allocations in code


I took some time out after lunch to use the gym at the hotel, so missed the next slot. After that I went to A Very Small Language Model by Jez Higgins. He explained Markov chains: what happens next depends on the current state, not how you got to the current state. He used these to build a text generator, in JavaScript, using n-grams, starting with 2, and then increasing. This means using the last two words to predict the next word, based on a corpus (or document, like the Complete Works of Sherlock Holmes or Jane Austin). You tokenise the text (break into words), and build a lookup table of what follows 2-grams (or 3-grams etc). That gives you a probability of the next word, so you can probabilistically select what to generate next. Many silly sentences were generated. 

Jez explaining predictive text

There were 10 lightning talks that evening. A speaker gets up to five minutes, and is kicked off stage if they go on for too long.  You had to be there (but they may be online at some point). 

First session of lightning talks

The second day started with KEYNOTE: C++ Exceptions are Code Compression by Khalil Estell. This went into some depth, but showed how to use exceptions in systems people claim you can't use exceptions in, and furthermore how the code might be smaller and more efficient. Khalil started by saying he told his student the accepted wisdom that exceptions are slow and bloat code, but when his students kept asking why he wanted to demonstrate why. It took some fiddling to make the exceptions work, but it turned out the common claim is wrong, sometimes. Khalil has talked about this before: for example https://www.linkedin.com/posts/khalil-estell_new-exception-performance-pr-reached-activity-7289806930766675968-KCyG/. I suspect each version has more details. 

Khalil starting his keynote


After an in-depth start, I went to C++ Coroutines - Gods from the Machine by Phil Nash. I did attend a workshop he ran, taking a similar approach at CppOnSea a couple of years ago. He starts by adding co_return to a function and follows the compiler error messages from there to get a working coroutine. If you need help writing a coroutine, listen to his talks when it's online. 

There was a poster session, and a student, Jacob Farrow, from Bradford University had his poster proposal accepted. His poster title was "Tracking Success: Enhancing Visual Tracking Skills in Children with Cerebral Visual Impairment through Interactive Digital Tools". I attempted to join, but couldn't find a quiet spot with enough WiFi coverage, so couldn't listen in. A shame. (I'm an industrial advisor at the Uni, so I shared the call of proposals with some CompSci lecturers, who persuaded the student to join in.) By this point, my brain had overloaded, so I skipped a session and went for a walk. 

In the afternoon I went to How old am I in Seconds and other insights from the C++ chrono library by Nicolai M. Josuttis. He gave a great introduction to using std::chrono for time and durations in C++. He didn't really answer the questions posed in the title - he lied about his date of birth, allegedly, and pointed out the different leap seconds used by different clocks. Howard Hinnant has a blog about leap seconds: https://howardhinnant.github.io/date/d0355r4.html, if you can't wait for Nico's recording on YouTube. (The blog covers much more than leap seconds.)

Nico counting in seconds

There were more lightning talks that evening, followed by a pub quiz (which I didn't attend because I needed some tea). I shared my poster and pointed out to attendees the conference was hybrid, so some people were online. 

More lightning talks (including me)

Thursday began with a  KEYNOTE: Learning to stop writing code (and why you won't miss it) by Daisy Hollman. She told us about Claude and Anthropic. Many people know ChatGPT, but not Claude. They are both LLMs, generating various types of output. Daisy explained how they work, and told us some inside information (Think harder). She put an emphasis on agents: at a high level, using several smaller parts rather than one big framework. What I found interesting was trying to wire in json or similar so the "AI" can use tools too. This might generate better code. Watch this space.

Daisy talking about agents


I went to / Error Handling Omitted / by Roger Orr next. I was speaking afterwards, so my mind wasn't 100% focused. And Dom was in the room next door, and his microphone was coming out through the speakers in this room to begin with! However, Roger did suggest you at least hint at error handling in docs or code examples. He explored various ways to report errors, and maybe he'll write it up for Overload one day. (Or 'll look at my notes and add more details here, later). 

I attended some of the ACCU's AGM over lunch, but had to leave early to set up for my talk afterwards. My talk was called An introduction to reinforcement learning: Snake your way out of a paper bag. I used a simple type of reinforcement learning, called Q-learning, and demonstrated an agent (that word again), moving in space. I gradually got it to play a game of Snake. Reinforcement learning doesn't use labelled data. Instead, agents trying actions, and either get a reward or penalty. They can then probabilistically pick an action next time. They look as though they are learning, but this begs a question about what learning really means. 

After my talk, Steve Love talked about C#: Puzzling C#. He's written a book for PragProg: https://pragprog.com/titles/csharpbt/c-brain-teasers/, which will be in paper form soon. His talk went through a few puzzles from the book in depth, and introduced some new puzzles. I know some C#, but have lost track recently, so this was a good way to get a glimpse of newer features and things to watch out for. 

Steve ready to give his talk


There was a speakers' dinner on Thursday evening, so the final day started with slightly later sessions, leaving the keynote to the end. I had a late breakfast, so I missed the first sessions. I did make it to How to write a Rubik's cube solver by Sam Saariste. He used Python for his code. He's been working on this with his son, who has entered speed cubing competitions and is doing very well at these. I had to leave before he finished, but his talking made me think, both about how to represent a Rubik's cube and how to enumerate moves. His visualisations were lovely. 

Sam's cube image, which he could rotate to demo playing. The numbers are a way to represent the cube which his son helped invent.

I had to leave early to be in my poster session. I sat in the backstage area, hoping the WiFi would work better, which it did. I shared some details about my Learn C++ by Example book, listing the table of contents and ways to try to (re)learn C++ over the various new standards. I believe writing small programs that do something, for example games, are a great way to learn. Only one person turned up, but we had a long chat about writing books about tech stuff that keeps changing. A challenge :-)

I managed to grab some lunch, then went to The Past, Present and Future of Programming Languages by Kevlin Henney. He listed various languages according to various indices, like TIOBE. As usual, he covered a huge range of topics, and sneaked in a few jokes. He also reminded us of history - for example why we have paradigms in programming. This dates back to a paper, "The paradigms of programming" by Robert W. Floyd from Communications of the ACM, Volume 22, Issue 8, Published: 01 August 1979, available here: https://dl.acm.org/doi/10.1145/359138.359140. There were lots of other lessons from history, and a musing on what might come next. The main thing I remember is that nothing much has changed for a while, in terms of new languages. 


One of Kevlin's slides: The past, present and future walk into a bar. It was a tense situation.

Finally, we had the closing KEYNOTE: Teaching an Old Dog New Tricks: A Tale of Two Emulators by Matt Godbolt. He showed us two emulators for the ZX Spectrum he had written. One implemented the way he usually approaches emulators, and the second trying to use modern C++, including templates, coroutines and modules. It's really encouraging to see a person of renown being honest about things they find confusing or that didn't work. He had various slides of old games which some people managed to guess when asked. It was a great talk, with some neat tricks. (I'll dust off my notes and list some later). 


Matt summing up
His summary reminded us
  • Learning is uncomfortable
  • Challenge your assumptions
  • Do things that bring you joy
  • Testing is always worth it

I had a great conference, met new people, caught up with others I already knew and was very tired by the end. We got a new kitten about 6 weeks beforehand, so we weren't sure how she would react when we got home. She was pleased to see us, and demonstrated this by playing lots. 

Willow showing off how to play "put a toy in a box"




Thursday, 20 March 2025

CppOnline 2025

I attended CppOnline this year. The conference happens entirely online, which makes the tickets cheaper. And you can even get one for free if you give a talk, volunteer or give a poster presentation. Phil Nash organises this, with help from many people, and kicked things off.



I gave a talk, called "Don't be negative". I asked how do you remove negative numbers from a container? C++ can be confusing sometimes. For example, the algorithm remove_if does not remove elements. More modern C++ gives us better approaches which are less confusing. I showed old and new ways to remove negatives, getting you to think about what is going on under the hood and why. I also gave some silly examples, for example randomly removing elements, and seeing if what was left was non-negative, inspired by bogosort. A slightly lossy algorithm, which may never complete. 

We recently got a new kitten, Willow, so trying to view the talks on a laptop proved difficult. The power key is on the keyboard, so Willow managed to turn the machine off. And disable the camera. And chat in the discord for CppOnline. 



I only made a few of the sessions, but there are recordings which will be on YouTube at some point. 


I listened in on the lightning talks, which were a nice mix of informative and silly. If you ever attend a conference, consider giving a lightning talk if you have the opportunity. It's a good way to try public speaking. There are over quickly - usually you get up to 5 minutes. 


I managed to listen to two complete talks - others I had to dip in and out of due to having far too much to do, including giving a poster presentation, and recovering afterwards.  

The first talk was by Andrew Drakeford. He gave a lightning talk at CppOnSea, when I was hosting them a while ago. I believe this was his first talk, and he wrote it up for ACCU's Overload magazine. He has now given at least a couple of longer, and very interesting talks. His talk this time was about Data-Oriented design: using data layouts and better algorithms and similar to optimize a program. He reminded me about George Pólya's book "How to solve it: A new aspect of mathematical method." Pólya gave four steps:

1. Understand the problem,
2. Devise a plan,
3. Carry out the plan,
4. Look back and check your work. 

If this fails, Pólya suggests "If you cannot solve the proposed problem, try to solve first some related problem. Could you imagine a more accessible related problem?"
His code example was trying to do regression (maths not breaking code) leaving out one element at a time from a million elements. He talked about memory access and layout and vectorization. He finally showed how a different equation meant far fewer calculations, which sped things up loads. The slides are online, and as I said, the talk will be too at some point. 

I also listened to all of  the "Art of friendship" by Mateusz Pusz. He showed how to use friend in C++, pointing out the benefits, like avoiding lots of error messages for globally accessible overloads when you make a mistake, and the potential problems. The slides are online, and the talk will be at some point. 

I mentioned posters. I did a PhD years ago, and gave poster presentations at conferences. They even counted towards my publications, so this is a great opportunity for graduate students. It's also an opportunity for people too shy to go on stage (whether in real life or online) and give a talk. Grad posters in real life are huge printed posters. The presenter stands by the poster and anyone can go up and chat or ask questions. I am starting to think giving a talk is easier - you can pre-plan what you are going to say. The poster presentation kinda jumps straight to the questions at the end of a talk, so you have no idea what you are going to walk into! 

I made a pdf showing the cover of my Learn C++ by Example book, and called the poster (Re)Learn C++ by Example, to emphasise it assumes some previous knowledge of C++. 

My Learn C++ by Example book cover. 
Available in various places including via my affiliate link: https://mng.bz/1aVV

I listed the chapter titles:
  1. Hello again, C++!
  2. Containers, iterators, and ranges
  3. Input of strings and numbers
  4. Time points, duration, and literals
  5. Creating and using objects and arrays
  6. Smart pointers and polymorphism
  7. Associative containers and files
  8. Unordered maps and coroutines
  9. Parameter packs and std::visit

I added a short overview of why catch up and how:
There has been a new standard every three years, since C++11.
This book didn't cover all the newer features: it gives just enough to help you catch up.
How do you catch up?
  • Write small projects
  • Command line games are great for learning
  • Focus on 1 or 2 features, and learn more than you intended
  • Have fun!

Nothing new, but it was an opportunity to chat. There were two time slots. The first had a few people turning up together, so I gave a small demo of my higher/lower card game. A nice simple program to write, which actually gives you the chance to try arrays, variants, random shuffle, and learn about comparisons via the spaceship operator. The second panned out differently. One person at a time showed up, so we just chatted. A guy asked what the difference between by ref and by value is in C++. That seemed like an easy to answer question, so I gave an answer (What would you say, BTW?). I then said "Why do you ask?" Apparently, he had been told to use pointers to speed up his code (?!) and making the change had caused a regression (code bug, not maths this time). I pointed out the difference between pass by ref and pass by value. You know this, right? What is the difference between these functions:

void do_stuff_one_way(std::vector values);
void do_stuff_or_another(const std::vector & values);
void do_stuff(std::vector & values);

The first copies the originals. If you have millions this will be slow. 
The second does not copy, so can be quicker, and the function will not change the original values.
The third does not copy, so can also be quicker, but might change the values because they are not const

Apparently this was helpful. I'm sad that someone sent the attendee down a painful rabbit hole. Here's my ProTip

If someone says "Do it this other way, it's better," ask why. Or say "Prove it." People are wrong, sometimes.