How to Use Abstraction to Kill Your API - Jonathan Marler - Software You Can Love Vancouver 2023

Official website: softwareyoucan.love
Vancouver Conference Website: softwareyoucanlove.ca
Abstract:
Join me for a fascinating dive into the world of libraries and API design, where we'll explore the reasons behind failures and how they could have been improved. In particular, I'll take a deep dive into libX11, sharing my experience of creating an innovative alternative library in Zig.
My library takes a different approach by not abstracting too much from the application, and I've put it to the test by replacing the libX11 backend in the iconic 1993 DOOM engine. The results are impressive, including the ability to create distro-agnostic executables, reduced runtime overhead, improved error handling, smaller executable sizes, and the ability to run on multiple operating systems such as Windows and MAC.
In this talk, I'll make a case for why my new library is simpler to use, understand and maintain than its predecessor. I'll also share the challenges I faced when tempted to add more abstraction but ultimately resisted, highlighting why libraries can often be their own worst enemy.
So, join me for an enlightening and thought-provoking exploration of how to build better libraries and avoid the pitfalls that lead to project failure.

[@delphicdescant]

Unlearn the teachings of enterprise software development, you must. - Zig Yoda

[@rj7250a]

Average class name in enterprise Java software: abstractFactorySingletonInterfaceHandlerFactory.

[@hck1bloodday]

@@rj7250a you used factory two times, that's not DRY, the correct name should be abstractFactorySingletonInterfaceHandlerBuilderDecorator

[@nXqd]

it's true, I think with the grow and changes of software development, there are some practices that must be changed.

[@megamaser]

People see a pattern and they copy it without thinking about whether it's applicable or if they're using it in a way that's helpful.

[@chbrules]

Zig looks very promising. My only concern is that I'd like to use it in a mission critical environment, but it's definitely not ready for prime time. There is also no formal language spec yet, so you can't rely on your code working next release or any future release.

[@stercorarius]

It was a shame for the D community to lose this guy

[@L0wPressure]

What’s the D, did I miss something?

[@gamcd]

@@L0wPressureDlang, C with more features and abstractions

[@nathanfranck5822]

A c++ alternative popular in the 2000s

[@L0wPressure]

@@nathanfranck5822 oh, got it, thanks!

[@NerdyWasTaken]

@@L0wPressure Language with 3 different compilers

[@martinweber988]

great talk and very refreshing to see a focus on efficiency in all aspects. Sweet.

[@megamaser]

You won't get much done without abstraction. But you also won't get much done if all you do is build abstractions.

[@UliTroyo]

What a cool talk! I'll definitely be re-watching this at some point :)

[@AK-vx4dy]

Excelent presentation! Interesting and funy!

[@MatheusCatarino]

Awesome!

[@aqezzz]

oh man, this is awesome. great work! i'm going to have to do some zig

[@CallousCoder]

Ooh nice! I can't wait!

[@ForeverZer0]

Zig is showing so much promise, and I can't wait to see where it goes in the future, It just might be the true successor to C for the modern era if it doesn't go the way of C++/Rust and go crazy adding too many features to the language. I have two peevs that I would love to see addressed at some point, both are minor: 1. Size of binaries 2. Inconsistent naming of language symbols: mix of Pascal-, camel-case, etc. (yes, this is very petty, but it irks me, and I see no legitimate reason for the inconsistencies)

[@notuxnobux]

Do you mean size of the zig binary or the size of binaries it produces? because with releaseSmall and debug symbol strip the binaries are smaller than even C with musl.

[@diskpoppy]

The capitalization of the symbols is to convey information without conventions that would be even uglier, like hungarian notation. In that regards, it's consistent - for example Pascal case is for symbols that indicate types (with the basic types - bools, integers and floating point being the exception).

[@nicolasgrilly]

@@diskpoppy Yes. I understand the idea is to keep TitleCase for types and snake_case for functions, variables, constants, fields, etc. I think one of the reasons for not keeping camelCase for functions is that there is no difference between camelCase and snake_case for one word identifiers.

[@etodemerzel2627]

Inconsistent naming? What are you referring to? The style guide (you can find it in the official documentation) says TitleCase for types, camelCase for functions and snake_case for everything else (including structs with 0 fields). What's inconsistent about that?

[@ForeverZer0]

@@etodemerzel2627 I am not talking about common naming conventions and code styles that are a good practice to (optionally) follow, but the symbols that built-in to the language itself. The list of built-in functions might shed some insights: What is the common rule being followed for a list that contains the following: @sizeOf, @TypeOf, @memset Something like @memset might have been kept as such for legacy reasons with its C analog, but then why not the same with @sizeOf or @alignOf. How does @Type, @TypeOff, or @Vector fit into this naming rule? It is possible for someone not be bothered by it, but this is objectively not consistent or based on a naming rule.

[@MahmoudAbduljawad]

Amazing talk! Learnt a lot.

[@samuelschwager]

Finally a guy that could fix my printer :P

[@employee9911]

Great talk!

[@felgenh399]

very cool!

[@acorad30]

Very interesting

[@nXqd]

super cool, talk and very nice audience

[@anasouardini]

The most important point here is Zig>C.

[@markblacket8900]

more like >= C

[@trondenver5017]

Great talk

[@yash1152]

0:03 how are they all making the presentation on this pixel art form??

[@alexdubkov6998]

Wow, he has a beard, so we can trust Zig!

[@mehmetedex]

Zigx is really cool

[@nanthilrodriguez]

What did this have to do with abstraction at all?

[@shrin210]

Zig has better abstraction implementation than C.

[@yash1152]

22:00 will watch later.

[@yash1152]

30:00*

[@VoyivodaFTW1]

i knew it was gonna be doom! lmao

[@StefaNoneD]

Sure a good talk, but this scratching sound issue is really nasty! 🙁

[@ryanlancer86]

The only thing I do not like about zig is the mascot

[@anagram]

What!?! It's the best thing ever! You are being crazy

[@Cons-Cat]

Terrible take! Ziggy is adorable

[@etodemerzel2627]

Blasphemy

[@saiv46]

Unlike *some alternative* Linux mascot, Zig one is pretty and cool. Who doesn't love reptiles?

[@martinmartin6300]

The fact that you need to assign return values to variables in zig is a very bad design choice. It is really annoying.

[@rinumu2736]

It's made that way, so that if you want to ignore the return value, you have to be explicit about it by assigning to _. In C it's very easy to forget to check the return value of functions. Many people don't even know that e.g. printf has a return value (I know I didn't even though I opened it's manual page many times).

[@andrewbreidenbach8788]

@@rinumu2736 I personally prefer Nim's discard keyword and discardable pragma

[@pierreollivier1]

It's on purpose, because one of the goal of the language is to be explicit, if you can discard the values returned by a function how can you at a glance know which functions is suppose to return something. in my humble opinion everything related to typing code is a non issue when you know that most code lives and need to be maintained. Id' rather type the four character needed to discard a value rather than having to deal with the mental load of checking every function signature to see who returns what. On top of that zig has really good type inference, a lot of what you pay in typing more returns you save it on type you don't need to type over and over again. It also has the benefit that changing the type of a function signature, doesn't brake anything if the type is compatible with the logic of your code.

[@gaius_enceladus]

Great talk!