Inventing GObject ES6 classes

Hello again! If you’re a GJS user, I’d like your opinion and ideas. After my last post where I talked about new features coming in GNOME 3.26 to GJS, GNOME’s Javascript engine, I’m happy to say that the patches are nearly ready to be landed. We just need to figure out how to build SpiderMonkey 52 consistently even though Mozilla hasn’t made an official standalone release of it yet.

A top view of a latte next to a notebook with a pen, with coffee beans strewed artfully around.

A better literal depiction of JAVA SCRIPT I could not ask for… (Public domain image courtesy of Engin_Akyurt)

As I reported last time:

After that is done, I will refactor GJS’s class system (Lang.Class and GObject.Class). I believe this needs to be done before GNOME 3.26. That’s because [we will] gain ES6 classes, and I want to avoid the situation where we have two competing, and possibly incompatible, ways to write classes.

That’s what I’m busy doing now, in the run-up to GUADEC later this month, and I wanted to think out loud in this blog post, and give GJS users a chance to comment.

First of all, the legacy Lang.Class classes will continue to work. You will be able to write ES6 classes that inherit from legacy classes, so you can start using ES6 classes without refactoring all of your code at once.

That was the good news, now the bad

However, there is not an obvious way to carry over the ability to create GObject classes and interfaces from legacy classes to ES6 classes. The main problem is that Lang.Class and its subclasses formed a metaclass framework. This was used to carry out certain activities at the time the class object itself was constructed, such as registering with the GType system.

ES6 classes don’t have a syntax for that, so we’ll have to get a bit creative. My goals are to invent something (1) that’s concise and pleasant to use, and (2) that doesn’t get in the way when classes gain more features in future ES releases; that is, not too magical. (Lang.Class is pretty magical, but then again, there wasn’t really an alternative at the time.)

Here is how the legacy classes worked, with illustrations of all the possible bells and whistles:

const MyClass = new Lang.Class({
    Name: 'MyClass',
    GTypeName: 'MyNamespaceMyClass',
    Extends: GObject.Object,
    Implements: [Gio.Initable, MyCustomInterface],
    Properties: {
        'prop': GObject.ParamSpec.int( /* etc., etc. */ ),
    },
    Signals: {
        'signal': { param_types: [ /* etc., etc. */ ] },
    },
    _init(props={}) {
        this.parent(props);
        // etc.
    },
get prop() { /* … */ },
method(arg) { /* … */ },
});

view raw
legacy.js
hosted with ❤ by GitHub

The metaclass magic in Lang.Class notices that the class extends GObject.Object, and redirects the construction of the class object to GObject.Class. There, the other magic properties such as Properties and Signals are processed and removed from the prototype, and it calls a C function to register the type with the GObject type system.

Without metaclasses, it’s not possible to automatically carry out magic like that at the time a class object is constructed. However, that is exactly the time when we need to register the type with GObject. So, you pretty much need to remember to call a function after the class declaration to do the registering.

The most straightforwardly translated (fictional) implementation might look something like this:

class MyClass extends GObject.Object {
    static get GTypeName { return 'MyNamespaceMyClass'; }
    static get Implements { return [Gio.Initable, MyCustomInterface]; }
    static get Properties {
        return {
            'prop': GObject.ParamSpec.int( /* etc., etc. */ ),
        };
    }
    static get Signals {
        return {
            'signal': { /* etc. */ },
        };
    }
    constructor(props={}) {
        super(props);
        // etc.
    }
get prop() { /* … */ }
    method(arg) { /* … */ }
}
GObject.registerClass(MyClass);

view raw
verbose.js
hosted with ❤ by GitHub

The fictional GObject.registerClass() function would take the role of the metaclass’s constructor.

This is a step backwards in a few ways compared to the legacy classes, and very unsatisfying. ES6 classes don’t yet have syntax for fields, only properties with getters, and the resulting static get syntax is quite unwieldy. Having to call the fictional registerClass() function separately from the class is unpleasant, because you can easily forget it.

On the other hand, if we had decorators in the language we’d be able to make something much more satisfying. If you’re familiar with Python’s decorators, these are much the same thing: the decorator is a function which takes the object that it decorates as input, performs some action on the object, and returns it. There is a proposed decorator syntax for Javascript that allows you to decorate classes and class properties. This would be an example, with some more fictional API:

@GObject.Class('MyNamespaceMyClass')
@GObject.implements([Gio.Initable, MyCustomInterface])
@GObject.signal('signal', { /* etc. */ })
class MyClass extends GObject.Object {
    constructor(props={}) {
super(props);
// etc.
}
 
    @GObject.property.int('Short name', 'Blurb', GObject.ParamFlags.READABLE, 42)
    get prop() { /* etc. */ }
 
    method(arg) { /* etc. */ }
}

view raw
decorators.js
hosted with ❤ by GitHub

This is a lot more concise and natural, and the property decorators are similar to the equivalent in PyGObject, but unfortunately it doesn’t exist. Decorators are still only a proposal, and none of the major browser engines implement them yet. Nonetheless, we can take the above syntax as an inspiration, use a class expression, and move the registerClass() function around it and the GObject stuff outside of it:

var MyClass = GObject.registerClass({
    GTypeName: 'MyNamespaceMyClass',
    Implements: [Gio.Initable, MyInterface],
    Properties: { 'prop': GObject.ParamSpec.int( /* etc. */ ) },
    Signals: { 'signal': { /* etc. */ } },
}, class MyClass extends GObject.Object {
    constructor(props={}) {
super(props);
// etc.
}
 
    get prop() { /* … */ }
 
    method(arg) { /* … */ }
});

view raw
class.js
hosted with ❤ by GitHub

var MyInterface = GObject.registerInterface({
    GTypeName: 'MyNamespaceMyInterface',
    Requires: [Gio.Initable],
    Properties: { 'prop': GObject.ParamSpec.int( /* etc. */ ) },
    Signals: { 'signal': { /* etc. */ } },
}, class MyInterface {
    get prop() { /* … */ }
 
    method(arg) { /* … */ }
});

view raw
interface.js
hosted with ❤ by GitHub

Here, the body of the class is almost identical to what it would be with the decorator syntax. All the extra stuff for GObject is contained at the top of the class like it would be with the decorators. We don’t have the elegance of the property decorator, but this is quite an improvement on the first iteration. It’s not overly magical, it even acts like a decorator: it takes a class expression, and gives back a GObject-ized class. And when decorators eventually make it into standard Javascript, the basic idea is the same, so converting your code will be easy enough. (Or those who use transpiling tools can already go ahead and implement the decorator-based API.)

This is the best API I’ve been able to come up with so far. What do you think? Would you want to use it? Reply to this post or come talk to me in #javascript on GNOME IRC.

Next steps

Note first of all that none of this code exists yet. Depending on what feedback I get here, I hope to have a draft version working before GUADEC, and around the same time I’ll post a more detailed proposal to the javascript-list mailing list.

In addition, I will be speaking about this and more at GUADEC in my talk, “Modern Javascript in GNOME“. If you are attending, come talk to me there! Thanks to the GNOME Foundation for sponsoring my travel and accommodations.

Official badge from the GUADEC website: "I'm going to The GNOME Conference GUADEC Manchester, United Kingdom"

The GJS documentation is back

Aside

We have once again a set of accurate, up-to-date documentation for GJS. Find it at devdocs.baznga.org!

Many thanks are due to Everaldo Canuto, Patrick Griffis, and Dustin Falgout for helping get the website back online, and to Nuveo for sponsoring the hosting.

In addition, thanks to Patrick’s lead, we have a docker image if you want to run the documentation site yourself.

If you find any inaccuracies in the documentation, please report a bug at this issue tracker.

GJS: What’s next?

In my last post, I went into detail about all the new stuff that GJS brought to GNOME 3.24. Now, it’s time to talk about the near future: what GJS will bring to GNOME 3.26.

Javascript engine

The highest priority is to keep upgrading the Javascript engine. At the time of writing, I’ve got SpiderMonkey 45 almost, but not quite, working, and Mozilla is on the verge of releasing the standalone version of SpiderMonkey 52. If we can get there, then we’ll finally be on a supported release which means we can have a closer collaboration with the Mozilla team. (During the past six months, they’ve been patient with me asking questions about old, unsupported releases, but it’s not fair to ask them to continue doing that.)

I plan to upgrade to 45 but not merge it, and then immediately continue upgrading to 52 on the same branch, then merge it all in at the same time. That way, we won’t have an interregnum where everyone has to build SpiderMonkey 45 in JHBuild and Continuous and the Flatpak SDK. Subscribe to bug 781429 and its offshoots if you want to follow along.

The main language features that this will bring in are: classes (45) and ES7 async/await statements (52). At that point, the only major ES6 feature that we will still be missing is modules.

ES6 Classes

After that is done, I will refactor GJS’s class system (Lang.Class and GObject.Class). I believe this needs to be done before GNOME 3.26. That’s because in SpiderMonkey 45, we gain ES6 classes, and I want to avoid the situation where we have two competing, and possibly incompatible, ways to write classes.

ES6 Modules

Full ES6 module support is still missing in SpiderMonkey 52, but at least some parts of it are implemented. I’ll need to investigate if it’s possible to enable them in GJS already. Although, we will definitely not enable them yet if there’s no way to keep the existing modules working; we don’t want to break everyone’s code.

Developer tools

Next comes a debugger. There are not one, not two, but three existing implementations of a GJS debugger sitting unattended in Bugzilla or a Git branch. None of them will apply to the codebase as is, so my task will be to fix them up, evaluate the merits of each one, and hopefully come up with one patchset to rule them all.

Christian Hergert is planning to add a profiler, so that you can profile your Javascript code with Sysprof, inside Builder.

Documentation

I would very much like to get the GJS documentation browser back online. I hosted it on EC2, but I have run out of free hosting. If you have a server where it can be parked, let me know! (It’s a web app, not static pages, so I can’t just put it on GitHub Pages.) If you want to run the web app locally yourself, you can find instructions here for how I set it up on EC2, on a RHEL 7 box.

Misc.

All that is probably more than I’ll have time for, but here are some of the things that I’d like to get done after that:

  • Update the tutorials on developer.gnome.org to use more modern GJS
  • Better integration with Builder
  • Use structured logging to clean up the “debug topics” mechanism
  • Reduce the list of unreviewed patches in Bugzilla down to 0
  • Find ways to bring in some of the conveniences that Node developers are used to

Chun-wei Fan is working on converting some of the codebase to use C++ smart pointers so that we get the memory leak safety advantages of g_autoptr without losing portability to MSVC.

Build system

The question is inevitable: are we going to switch the build system to Meson? I’m looking forward to it, but no, not until Meson is more mature and some of the open questions about distribution and autobuilding have been answered.

Help!

I think it’s great that once I started contributing, other people soon started contributing too. The 1.48.0 release had way more patches and contributors than 1.46.0, even if you don’t count all the stale patches that I souped up. GNOME’s #javascript IRC channel is starting to be a lively place, compared to how deserted it was last year.

What I’d most like to encourage is for more people to contribute major features so that the above list doesn’t read like a to-do list that’s mostly for me. I’m happy to provide guidance. I think it would be great for GJS to become a more competitive development language for apps using the GNOME technology stack1 and we won’t get there with just me.

Another way you can help is by using the development version of GJS while developing your apps or GNOME Shell, thereby helping to try out the new features. We had some serious bugs up to, or even past, the last minute in GNOME 3.24, and this seems like the best way to prevent that.

Finally, you can help by sharing your experiences with GJS: good and bad. Talk on the mailing list or IRC, or file a bug on bugzilla.gnome.org if there’s something wrong.


[1] In that regard I’d love to prove wrong Michael Catanzaro’s opinion about using GJS: “there’s no way to change the reality that JavaScript is a terrible language. It has close to zero redeeming features, and many confusing ones.” There is a way! In my opinion ES6 and ES7 have gone a long way towards filling in those potholes. To name just a few, arrow functions mean you can almost always stop caring about the pitfall of what this refers to, and the prospect of doing asynchronous I/O with Promises instead of callbacks actually makes me want to use JS. Of course, in-browser JS is still a terrible language because it has to support the lowest common denominator of Javascripts so that people who haven’t upgraded their browser since Internet Explorer 8 can still visit your website, and that’s why modern web developers preprocess and transpile it to high heaven. But we don’t have to care about all those browser users!

Healthy Code

I work on a team of software developers that maintains several large codebases — too much code for any one person to easily know what’s going on in every part of it at any particular time. I found myself thinking a lot about how to keep the code healthy and a while ago I set my thoughts down as a list of good practices. Thanks to my coworkers at Endless for input, editing, and debate.

The good practices in this post differ slightly from the ones we adopted at work, which reflect the opinions of the whole team; these are worded to reflect my personal opinions.

Assumptions

I don’t like rules without a rationale. I believe these six assumptions underlie the rules that I set out below. That is, if you don’t agree with these assumptions then you probably won’t agree with the rules… ☺︎

  1. We can never know that our own code is correct.
  2. Left unchecked, we will believe our own code to be correct.
  3. Even small mistakes can lead to catastrophic data loss.
  4. Non-trivial programs have interconnections too complex to keep entirely in one person’s mind.
  5. Modifying non-trivial programs will break code unrelated to the modifications.
  6. The business value of maintainable code is only visible to developers.

Good practices for code health

Use your judgement

As always, rules apply only in the absence of any overriding reason to ignore them. Breaking them should be in mutual agreement between the writer of the code and the reviewer. (This system only works if everyone agrees about what the rules are in the first place, though.)

Example reason to break this rule: If no agreement can be reached, then the default is to follow the coding standards.

Review code

Code gets reviewed by a developer who didn’t write any part of it, because of assumptions #1, #2, and #3 — and to spread familiarity with different parts of the codebase throughout the team. Develop with ease of reading in mind, as if you are writing a letter to an unfamiliar code reviewer. Review code skeptically and with full attention, as if it came from a malicious agent out to erase your hard drive.

Example reason to break this rule: You are committing a trivial fix for a broken build and your continuous integration system acts as the code reviewer.

Observe the style

Code follows the coding style. Coding style is important because when code looks the same it’s quicker to read and errors jump out more easily. Apply automated tools when possible to save the code reviewer from becoming a parenthesis counter.

Example reason to break this rule: The code reviewer agrees with you that deviating from the style is more readable.

Test your code

Code needs automated tests. The rationale for this is assumptions #2 and #5, but could be the subject of an entire blog post itself. Lack of tests can be by itself a reason to fail code review, or at least start a dialogue between developer and reviewer about why tests are not necessary in this particular case.

Example reasons to break this rule: A one-off script. A component that proxies an external resource which can’t easily be mocked out.

Refactor on write

You will always have to deal with legacy code (code on which development has ceased but still must be maintained) and rushed code (code which you were forced by circumstances to check in that didn’t quite work well, works but is difficult to maintain, or is not tested.) By assumption #6, you will probably never set aside time to refactor code for its own sake. Therefore, refactor bit by bit to leave the code in a slightly better state each time it’s touched. In this way, code receives refactoring attention roughly proportional to the benefit you receive from refactoring it. If at all possible, add new code with a unit test even if the rest of the code is not written in a testable way.

Example reasons to break this rule: The code is already in good shape. The feature is critical and cannot be delayed. You are contributing your code to an open source project, in which case it is better to work with the upstream community to refactor.

Refactor only on write

Make your diffs per commit no larger than they have to be, in order to make code review easier. Since diffs go line-by-line, do not fix style errors in lines that that are not already being touched in the same commit. Use separate commits if there is an opportunity to make other style fixes.

Example reason to break this rule: If it makes more sense to fix lines other than the ones being edited in one shot (e.g. large sections with wrong indentation), do so throughout the whole file in a separate commit.

Pay down technical debt

Sometimes it’s not possible to build a feature without doing a large refactor first. Determine this as early as possible and include it in the time estimate for the feature. Do not shy away from paying down this debt; it will only compound if you borrow more on top of it. However, keep the changes incremental, and the functionality unimpeded while making these changes.

Example reason to break this rule: Extreme time constraints force you to take out a second mortgage on the code (even then, do this only with a healthy dose of disgust.)

Moving text messages between Android phones

I recently got a new Android phone secondhand, and after resetting it I wanted to move the text message archive over from my old phone. It turns out that you can do this easily if you have root access. Well, technically you can do anything easily if you have root access, but the trick is knowing how. I hope that by putting this out on the internet, other people will be able to know how too.

I had root access on both phones, as they were flashed with CyanogenMod. The new phone is a Nexus 4, and the old phone is an HTC G1 (Android 2.2 is the highest that could run on it.)

On both (and as far as I know, all) versions of Android, all the text messages are stored in this file, which you need root access to read:

/data/data/com.android.providers.telephony/databases/mmssms.db

Getting the file off the G1 was easy; I entered the Terminal Emulator app (I think it’s installed automatically when you flash CyanogenMod) and copied the file to the SD card:

su
cp /data/data/com.android.providers.telephony/databases/mmssms.db /sdcard/

(su requests superuser permissions, which you have to grant.) Then I connected the G1 to my computer with its USB cable and transferred the file off of it.

Getting the file onto the Nexus 4 was harder. What I did not know is that the Nexus 4 can’t mount its SD card as USB Mass Storage (see the explanation), so I ended up using my Apple laptop to do the transfer, and had to download a program called Android File Transfer. Still, I got it onto the phone’s SD card.

Since the newer version of Cyanogenmod comes with a file manager app, I decided to use that to put the file into the correct place, instead of Terminal Emulator (typing shell commands on a phone is no joke.) The file manager is set to “Safe mode” by default which means it won’t request root access. I changed it to “Prompt User mode” in the settings, then navigated to the above databases/ folder and made a backup copy of the old (empty? 100 KB? It’s a sqlite DB so maybe there are still deleted records in there, but I don’t care to check) database. Then I copied the G1’s mmssms.db file over top of it. Unlike on the G1, there was also a mmssms.db-journal file there, which I hoped wouldn’t mess with things…

I couldn’t see my text messages after going into the messaging app, but after rebooting the phone, they were there.

Geek tip: Malloc debugging on OSX

I’ve been trying to chase down an annoying bug that I suspected to be a case of using uninitialized memory. The problem is, it only shows up about 1 in 30 times (I was lucky to notice it in the first place), and never in a debugger.

Fortunately I found that there’s a library on OSX that tweaks malloc() to help you debug:

DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib MallocPreScribble=1 ./myprogram

Or, to do this in LLDB, since due to System Integrity Protection, your linker-affecting environment variables get wiped when you execute a system program:

lldb -- ./myprogram
env DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
env MallocPreScribble=1
run

This triggered the bug every time, both inside and outside the debugger.

For more information about what you can do with libgmalloc, see this documentation. It only tells how to use that facility in Xcode, though, so the above instructions should help if you’re on the command line.

Wave at the camera

You have probably seen the fake advertisement for Wave, the new way of charging your iOS 8 phone in any standard household microwave. (Although I would venture that some of the responses with fried microwaves and phones are hoaxes as well.)

I admit I did giggle when I first read it — some chump microwaved their expensive phone and blew it up, funny, right? Only I realized that it’s not funny at all.

Why shouldn’t people believe that a new technology would allow them to charge their phone by microwaving it? It’s no more or less magical than any other new technology being invented every day. It just happens not to have been invented yet.

Yes, people need to think critically, check sources, use common sense, and become less science-illiterate. Is microwaving your phone a smart thing to do? No. Could the average person probably have known better? Yes. But if you are lucky enough to be in the minority for whom this is obvious, you don’t have any right to laugh at those for whom it is not.

Nature, why?!

Scientific journals charge subscription fees in order to access their content. If you’re an employed scientist, the university or company where you work usually buys an institution-wide subscription to a journal. In that case you don’t have to log in to the journal website because it recognizes your IP address as belonging to a subscribing institution. In fact, you don’t even get an account on the journal website, because it’s impractical to issue an account to every single user at a university, for example.

So what do you do when you have to look up something when you’re away from your office? You use SSH with port forwarding to connect to work, then visit the website using a proxy server on that port. Since you are now browsing through a work computer, you can read the journal. There’s nothing wrong with this, because your employer has already paid for your access that content, but the barrier was simply the impracticality of issuing you an individual account.

So it’s really strange that Nature Publishing Group, which publishes the overrated Nature family of journals, seems to want to discourage this practice. If you visit the site of a Nature journal from a non-subscriber IP address, they set a cookie in your browser that says you are not a subscriber. So even when you turn on your proxy server and revisit the site, it still tells you you’re not a subscriber and can’t access the journal article. Luckily, it is easily remedied by erasing your browser’s cookies. (Easily done, that is, but not easily thought of. Hope this helps someone.)

Why, Nature, why? Why would you do this? Do you have scientists’ best interests at heart and you want to prevent them from working at home? Or do you hope that people are gullible enough to pay twice for the same content?

Discretization, Part II

In this post I described how I encountered the Sell Your Science contest and was entirely fed up with how they perpetuate the myth that scientists are a bunch of timewasters and that marketable research is the only research worth doing. I wrote the organizers, Science Alliance, a letter and urged other people to do the same. Well, it took fewer letters than I expected for something to happen.

My coworker Jelmer Renema wrote them a more strongly worded e-mail than I did. Today he got a telephone call from someone from Science Alliance who wanted to talk about the e-mail. The outcome of the telephone call was that the Science Alliance employee said they didn’t mean that economic gain was the only valid reason for science; social relevance and curiosity from the public are important too. He admitted that the blurb could have been worded differently, although he claimed that there was a large group of scientists opposed to bringing research to market. No, Jelmer told him, nobody’s opposed to that — they’re opposed to the idea that marketable research is the only worthwhile research. In the end, Science Alliance promised to do better next year and Jelmer offered them his assistance in matters of science communication.

By coincidence, an interview appeared in the Delft University newspaper this week. Professor Piet Borst, former scientific director of the Dutch Cancer Institute, says that the whole ‘valorization’ business has gone too far and gets quite angry about it (translation mine):

“We are going about this in such an absurd way. There’s really no other way to put it. [The ministry of] Economic Affairs is living in the 1970s, they think like this: ‘Those wretched university researchers and other academics, busy only with their own hamfisted hobbies, we have to force them to do useful work, and we can only do that by making them dependent on industry financing. They need guidance from our watchful industrialists over what they do.’ They’re delusional. It’s a recipe for how to do it wrong.”

Note that this man isn’t one of those mythical ‘hermit scientists’ either: he says in the interview that those who do research with public money have a duty to allow their findings to be turned into products, which create jobs.

One other important point that Borst makes is that if you, as a researcher, have a significant stake in a spinoff company, then can you really be trusted to publish findings that will cause your shares to plummet? As the interviewer says in the article, “The answer is obvious once you’ve asked the question.”

Discretization is the better part of valorization

V is for Valorization. What’s that? A buzzword coined by the Dutch government that signifies how all scientific research should make money, and lots of it, sooner rather than later. It’s certainly not an English word, as evidenced by the quizzical looks on the faces of physicists who haven’t been working in the Netherlands lately, when some official government delegate gets to make a speech at a Dutch physics conference and says, beaming into the audience, “We are ferry heppy to see so much fellorizable research going on here!”

(UPDATE: Merlijn van Deen reports that valorisation is, in fact, a borrowing from French, where it is used in the same context of scientific research as in Dutch. In English, according to Wikipedia, it is used only as a translation of the German Verwertung, a technical term coined by Marx in Das Kapital meaning to add surplus value to capital by human action.)

I don’t fit the popular caricature of a scientist who thinks all research should be pure and untouched by worldly concerns. On the contrary, I have a Master’s degree in applied physics. One of my current projects is to build a new kind of wavefront sensor that works on a different principle than the commercially available ones. I’m firmly of the opinion that the original reason for this ‘valorization’ policy is quite sound: to get academia and industry interested enough in each other so that academia’s more marketable efforts get passed on to industry instead of dying the death of obscurity in a professor’s filing cabinet, and industry knocks on academia’s door when they have an interesting problem to solve with a longer time-to-market.

But it’s been blown all out of proportion now. The government has declared some research more valuable than other research: fields like high tech systems and energie (energy) are now designated topsectoren (top sectors,) research to which funds should be diverted at the expense of all other research. They are headed by topteams (top teams) each including a captain of science and captain of industry, which draw up innovatiecontracten (innovation contracts) that are required to hit each vertex of the gouden driehoek (golden triangle) of kennis, kunde, kassa (knowledge, expertise, and cash.) It will be successful in making the Netherlands #1 worldwide in the use of buzzwords, which I’ve italicized and translated (only where necessary, since half of them are in English anyway to make them sound more important.) If you read the actual documents, you get the feeling that the government is telling the big companies, “Hey! Want some cheap contract research? We’ve given those scientists free rein for too long and it’s time they worked for you to redeem themselves!”

The thing that spurred me out of lethargy was this, the Sell Your Science contest. You have to make a 90-second video about your research and the winner gets the title “Best Science Communicator of the Netherlands.” Sounds great. But it turns out that you literally have to sell your research: in the description, they treat ‘the audience’ and ‘investors’ as one and the same! I’m sorry, but science communication and sales pitches are two different things. Nothing wrong with a sales pitch contest, but at least call it by its rightful name!

Science crosses borders that politics doesn’t, so it may not have even occurred to their bureaucrat brains that they’re shutting out a large share of the scientists in the Netherlands, who are not Dutch and might not speak it well enough to read the rules of the contest which aren’t in English.

And this part really makes my blood boil (translation mine):

Nowadays, it’s not enough just to write scientific articles and to talk to people in your own field. A broader, open attitude towards society is expected, and valorization sections are required in NWO grant applications. The modern scientist will have to communicate differently and more widely in order to propagate their research.

I explain exactly why this makes my blood boil in the letter that I sent them on May 10. My own English translation is reproduced below. It’s been two weeks and I’ve received no reply. So I’m sharing it:

Dear Sir or Madam, (cc: editorial office of the Leiden University employee newsletter)

I read about the ‘Sell Your Science’ contest in Leiden University’s employee newsletter, and from there I clicked over to the website www.valorisatie.nu. My astonishment was boundless when I read there that this contest is failing to distinguish between the two entirely disparate concepts of ‘science communication’ and ‘science valorization.’ I would like to take a moment of your time to explain why I think this is wrong.

Science communication is, as you say, presenting research to a broad audience in a clear and understandable way. But is that the same as ‘valorization’? Only if one assumes that the broad audience is exclusively interested in marketable research. That is a dangerous fallacy.

The passion that drives a researcher to be good at science communication usually doesn’t spring from the commercialization of research. It’s likely that someone who’s motivated by commercialization won’t choose a career in research. These days, there are those who would rather deny that, but it’s a fact. The description of Sell Your Science, in which scientists are portrayed as hermits, only speaking to their fellow scientists and avoiding contact with society, and in which you say that the ‘modern’ scientist has to start doing things differently, feels like a slap in the face of my profession. There are countless scientists, both in the past and in modern times, who may not necessarily be oriented towards industry, but do stand 100% squarely in society. These people are marginalized by the tendentious introduction on the website. ‘Hermits’ may exist, it’s true, but they are a small minority.

Anyone that I’ve ever encountered who’s been good at communicating science, was able to captivate their audience using their dedication and passion, no matter what the economic value of the research was. Good science communication makes sure the audience has learned something by the time they leave. Good science communication fans the sparks of curiosity in the audience, so that someone, the day after or the day after that, might just hit upon the idea to ask “How does that work, anyway?” A scientist who can captivate an audience (apparently, a hostile one at that) with ‘unmarketable’ science and at the same time, manages to convey its importance despite its unmarketability, is a much better candidate for the title of “Best Science Communicator of the Netherlands” than someone who can sell ‘marketable’ science to investors. That’s the difference between ‘science communication’ and ‘science valorization.’

Sincerely,
Philip Chimento
PhD student, physics
Leiden University

Writing letters seems to have had an actual effect — read Part II.