|
Tikhon Jelvis
@
tikhonjelvis
Berkeley, CA
|
|
I like programming languages. A lot.
Especially Haskell.
Principal AI Scientist at Target
|
|
|
1.952
Tweetovi
|
205
Pratim
|
2.077
Osobe koje vas prate
|
| Tweetovi |
|
|
Tikhon Jelvis
@tikhonjelvis
|
10 h |
|
Sure, I picked ICFP vs POPL because I think their topics—at least as stated—overlap *a lot*. The differences between them (which are important for getting a paper accepted) are subjective and exist more as implicit cultural knowledge than anything else.
|
||
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
10 h |
|
Right, that's what I'm getting at—not that they're stupid, but that they're opinionated, and that the system's feedback loops *increase* this tendency rather than dampening it.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
10 h |
|
One thing I see is how the standard for "interesting" work varies even between conferences in the same field.
I'm reasonably certain that there are interesting papers at ICFP that would be on topic (and sufficiently "good") for PLDI, but wouldn't get in.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
10 h |
|
Also, Twitter's UI keeps moving my response around or something :/. I was trying to respond to your post about "interesting and relevant" specifically.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
"Radical" vs "non-radical" isn't necessarily the same axis—I imagine you'd have no trouble getting radical research in as long as it matched the essential aesthetic of the conference, and get less radical work rejected because it didn't.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
Of course, industry conferences—which aren't comparable because they don't affect careers or business direction the same way—are even worse.
Let's have two days of talks about how everyone is solving the same problems with microservice architectures in the same ways...
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
It's particularly annoying because those trends rarely match up with my own opinions on what's worth researching and what isn't :P.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
From what I see on the outside, it's not only fundamentally subjective, but also heavily driven by academic fashions. The system pushes people to work on things that are popular—which they already do anyway, since people tend to do popular things.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
At a macro level, it's a bit disturbing how much an academic researcher's career is driven by being able to understand and work towards the particular set of topics that a small number of top conferences deem "interesting and relevant".
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
Decoupling examples from unit tests just makes it easier to reuse the values in non-test-specific contexts (ie profiling and benchmarking).
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
Yeah, I used to do that too, or use unit tests for that same function.
Keeping them around instead of deleting them ends up super useful in practice, with only a small cost (writing them in the first place and updating them during refactors).
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
It's not meant to be a general-purpose data generator or anything like that (that would be a much bigger investment), just enough for people to play with locally as they work on the code.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
11 h |
|
It could just be a realistic value called "example".
In more complicated cases, we have functions to produce examples: something like "demand distributions for N stores with a mean demand of X at each store".
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
12 h |
|
You could differentiate yourself by getting some cats instead.
As a bonus, there's more pun potential :).
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
13 h |
|
We haven't been 100% consistent about this, so I bet it would be even nicer if it was a convention across the entire codebase.
That way, you can always rely on getting example values to play with, without needing to spend much time on it.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
13 h |
|
Trick that's been working well at work: when you define domain-specific data types, include functions that generate representative examples of the type.
This will make life easier when you're playing around at the REPL, writing tests, profiling, benchmarking... etc.
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
3. velj |
|
To be fair, I've written tests that just ensure the program continues doing whatever it did the first time :).
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
3. velj |
|
As long as your tooling isn't boring.
Which...
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
2. velj |
|
Making important tasks like writing tests *less boring* would go a long way to improving software engineering quality in the real world—but I don't see people talking about that very much :P. twitter.com/tikhonjelvis/s…
|
||
|
|
||
|
|
Tikhon Jelvis
@tikhonjelvis
|
2. velj |
|
Worse than that, it's *tedious*.
It's a lot easier to convince myself to do something hard than to do something boring :).
|
||
|
|
||