Just Do It

Alex Jordan

About moi

Arch Linux

Emacs

Git

zsh

Node.js

Firefox

Also about moi

Radical FLOSS zealot

Self-hoster

High school senior

he/him

I'll get right into it.

LOOK AT WHAT COMPUTERS CAN DO.

Um, I see that every day.

It's just a Python prompt.

Yeah, but not everyone sees that.

Away from FLOSS...

There's no equivalent.

On Windows, C# is the dominant language.

On OS X, it's Swift.

Guess what? They're both compiled.

(Swift has the concept of "playgrounds", but it's not the same.)

So you want to use Python (on a proprietary platform)

Have fun.

C# looks like Windows.

Swift looks like OS X.

If you don't use them, you'll be fighting.

A language "looks" like something?

Languages have designs,

regardless of the author's intent.

Any language that doesn't intentionally follow a design will fail.

Unless, of course, it's orders of magnitude easier for web scripting and shared hosting.

Operating systems have designs, too.

A programming language takes a certain view of the world:

How objects map to underlying resources

How the filesystem works

How processes and threads are modeled

What users are

Example: OpenCV in Java

In robotics, we started looking at OpenCV's Java bindings

Matt: "where are the pointers?"

Java doesn't have pointers...

...but the API looked like it should, because it was a port from C

In FLOSS?

C looks like POSIX.

Python looks like POSIX.

Even shell is more POSIX than C# or Swift.

It's POSIX all the way down.

Why POSIX?

POSIX = Unix

And Unix was built by engineers, for engineers

Windows and OS X are built for users and enterprises

"The enterprise"

C# and Swift are compiled because compiled languages are "fit for the enterprise"

They're "what professionals use"

They're performant

C# and Swift are rigid and correct

Python is not. Python is infinitely flexible.

Back to Python

Python is flexible

Python is somewhat forgiving

Python requires no boilerplate

print('Hello World!')

Why those things?

Because Python is designed by engineers, for engineers

Those things make sense

They make for code that is elegant and beautiful

Elegance & beauty

Ruby is the fully-fledged embodiment of this idea

"Describe your program in an English sentence. Congradulations, you just wrote some Ruby."

% python3

Having an interactive prompt makes sense

Especially since our community values hackability so much

This is the reason why people teach programming with Python.

Just code

Nothing getting in your way

No boilerplate

No overengineered architecture

Just stuff that makes sense.

"Why do I have to use this AbstractUnicodeStringFactoryFactory?

GNOME, we need to talk.

Hey KDE, you should hear this too.

Everything is complicated.

Let's talk about a file synchronization tool in GNOME

GNOME file sync daemon

GTK+

GObject

D-Bus

XDG notifications

More, you say!?

XDG user directories

System tray

Session startup

dconf

Public Domain

All of this stuff gets in the way.

To be clear: it's for a good reason.

All of these things solve real problems

And all of the people who work on these projects are good people.

But at the same time...

This is why we're losing them.

There's no path forward.

I speak from personal experience when I say: it's not easy to learn this stuff.

That's where we lose them

Suddenly there's way more stuff that you have to understand

"Why do I have to use this AbstractUnicodeStringFactoryFactory?

Let's fix this: better docs

I'll call out GLib in particular: there are no Python docs

All the API examples are in C

Not only that, there are no (comprehensive) tutorials

Docs aren't fun, but they're the future

Sufjan, the OpenHatch mascot

OpenHatch

OpenHatch is as critical as the FSF

The FSF is very, very important

But it's been doing short-term work for 30 years.

OpenHatch is doing the long-term work:

Ensuring that our community has people in it in 50 years.

We need to invest in outreach programs, like OpenHatch

Last but not least: architecture

We need to make it easier to transition from print('Hello World!') to GTK+ apps

Lots of complex interdependencies

These need to be learned at once, to a certain extent.

But how?

There needs to be a more gradual way to adopt stuff.

GObject needs to take a back seat

Not go away, because it's still super useful

But it needs to be possible to do stuff without it.

Duplication

Yes, that may have some problems with duplicate efforts

But that's what a long-term investment looks like.

You put a little more in now, and get a lot more later.

Thoughts?

@strugee2

alex@pump.strugee.net

strugee.net

Access this presention again

https://strugee.net/presentation-just-do-it

Or, check out the source.