PoignardAzur

Object-oriented smells

Object-oriented programming is widespread in industrial codebases.

This is in part because of inertia: OOP has been the dominant paradigm for decades; an entire generation of programmers has been taught from the onset that OOP was The Right Way To Program.

There are also strong reasons to do OOP: objects are somewhat intuitive abstractions, and encapsulation is a convenient way to separate responsibilities so that a very large team can work on the same code without bumping into each other; inheritance and abstract classes add modularity and reusability to the mix.

But OOP also has strong flaws, which I rarely see discussed. People who criticize OOP tend to do so from the perspective of performance: OOP leads to vtables, heterogenous collections, and sprawling object graphs which put a lot of pressure on CPU caches. But people rarely discuss what I see as the main problem with object-oriented codebases:

PoignardAzur

About variadics in Rust

This is an analysis of how variadic generics could be added to Rust. It's not a proposal so much as a summary of existing work, and a toolbox for creating an eventual proposal.

Introduction

Variadic generics (aka variadic templates, or variadic tuples), are an often-requested feature that would enable traits, functions and data structures to be generic over a variable number of types.

To give a quick example, a Rust function with variadic generics might look like this:

PoignardAzur

function generateSVG(N, M, S) {
  const rects = [];
  for (let y = 0; y < M; y++) {
    for (let x = 0; x < N; x++) {
      rects.push(`<rect x="${x * S}" y="${y * S}" width="${S}" height="${S}" fill="none" stroke="black" stroke-width="2"/>`);
    }
  }
  const width = N * S;
  const height = M * S;
  return `<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}">${rects.join('')}</svg>`;

PoignardAzur

Inline SVGS in labels should be represented using the font's height as their constraint.

PoignardAzur

These are snippets from a bunch of conversations / monologues I've had about GUI design on the Druid zulip.

PoignardAzur

macro_rules! impl_into_view_for_tuples {
  ($($ty:ident),* $(,)?) => {
    impl<$($ty),*> IntoView for ($($ty,)*)
    where
      $($ty: IntoView),*
    {
      #[inline]
      fn into_view(self) -> View {
        paste::paste! {

PoignardAzur

My recommendations for Vello in 2024

Basic Documentation:

• Write a main function.
• Point to the SceneBuilder types.

All the following come after shipping 0.1.

• Implement WebGL compatibility

PoignardAzur

Roadmap for Xilem backend

As you may have heard by now, Google Fonts is funding me this year to work on Xilem.

I'm not alone in that: Aaron Muir Hamilton, Daniel McNab and Matt Campbell were funded as well to work on various parts of the ecosystem. I believe this is Matt's third year getting funding from Google Fonts.

Now, what I was hired to do might be unclear to you. The scope we agreed on was fairly broad and was stated as "contributing to Xilem's view tree and developer experience", but that could mean a lot of things.

This is something I want to fix ASAP. I have a a lot of plans for Xilem, and they involve major changes from the current architectures, changes that might be worrying to the community at large or even to Raph Levien. I certainly don't want to give the impression that I'm wresting the project away from the Linebender community for Google's interest, and that means being transparent early and often about the things I want to break.

PoignardAzur

• For every feature, lay out at least one accidental "path" through which the user can stumble on this feature organically.

  • Express this path in a data structure that can be checked in CI.

• When browsing a hierarchy, make it really easy to quickly see the list of all parents

• Do not make the user make changes that they don't know how to cancel. (even without ctrl-Z)

  • Cancelling should generally be as easy as "Remove object I just created"

• Make "git diff" visible in object hierarchy

PoignardAzur

Notes on convert_wiki project

This article is a post-mortem on a small project I've been working on for the past few months.

The project itself is mundane: I was tasked with converting a MediaWiki archive into a Git repository, with revision history included.

Where it gets interesting is that, while I initially expected to finish the project in less than a week, it ended up taking about twenty days, spread over three months. Over those months, I've made mistakes, changed course a few times, realized that not everything had to be written in Rust, and resolved that this would be a learning experience for me.

This post-mortem is an attempt to both share the lessons I've learned, and actually figure out what those lessons were.