Fork me on GitHub
#clojure-europe
<
2021-09-14
>
dharrigan06:09:15

Good Morning!

slipset07:09:30

Todays little nugget. If you want peformant code, you need to write specific code.

4
👍 2
slipset07:09:04

As in, if you want to go fast, you need to do as little as possible.

slipset07:09:32

If you know nothing, you can assume nothing, and you have to cater for everything.

borkdude07:09:00

I suggested a patch for CLJS for removing dead code in println in the name of "doing less is faster". But it wasn't well received because "the golden rule is to not change" or something 😁

simongray09:09:41

I think the Clojure core team is often a bit too dogmatic about this kinda stuff. Surely you can rewrite internal logic or refactor code in such a way that it doesn’t bother anyone. Isn’t that the point of having abstractions?

slipset07:09:13

And, yes, I’m looking at a very specific piece of Javascript code which could/should be a lot faster than it is.

borkdude07:09:32

> the golden rule is to change nothing - unless we're adding something or fixing a bug

borkdude07:09:46

(found it on Zulip)

Jakub Holý (HolyJak)07:09:44

I guess the rules differ between your app code and the language itself, where any misstep is kind of disastrous

slipset08:09:25

We could argue that slowness is a bug.

❤️ 2
borkdude08:09:49

You could also argue that dead code is confusing and doesn't contribute to understandability

💯 6
mpenet08:09:55

"do a little as possible" rarely translates to less code tho

borkdude08:09:23

haha I concur. I've made a lot of optimizations in SCI to do less but the code became way more boilerplatey

reefersleep08:09:49

Two great arguments

javahippie08:09:08

Good Morning!

reefersleep08:09:13

The older I get, the more I appreciate speed optimizations.

☝️ 2
reefersleep08:09:29

Those miliseconds that I’m waiting are miliseconds off of my life! 🙂

reefersleep08:09:29

Actually, the same for dead/confusing code. The time I spend rummaging around spaghetti is time I’m not doing productive and/or enjoyable stuff

mpenet08:09:58

I tend to favor readability/maintainability personally

☝️ 2
2
2
mpenet08:09:11

unless it's strictly necessary to grind for performance

javahippie08:09:16

The customer project I’m currently at had a strict “Readability before Performance” policy in place. Now, two years later, it has grown a lot and 40% of the bugs I get are performance-related 😕

reefersleep09:09:30

Hopefully, you are then able to easily find the relevant parts of the code, with the high readability aspect in place 🙂

javahippie10:09:11

It’s okay I guess. Vented with an article on shortcomings of enterprise software projects last week, which took some beatings in the comments. Code quality and architecture in big project-style setups is insanely hard, imho.

reefersleep12:09:17

It just is, isn’t it?

reefersleep12:09:44

Everything looks good in example code 🙂

reefersleep12:09:14

Big projects accrue more or less undocumented compromises en masse, and even if you have sane conventions for everything you’re doing, it can be hard to keep them, or enforce them. It can make you feel a bit hopeless at times. And it can make you love deleting cruft; I sure do!

❤️ 2
mpenet08:09:35

for sure it depends on the context

mpenet08:09:01

and there are some low hanging fruits to always reach for, for decent performance without trading readability

mpenet08:09:41

but I wouldn't go interop heavy or rely on clj internals in the general cases

mpenet08:09:01

which is quite often what you must do when you want to squeeze for cycles

javahippie08:09:10

It’s the tradeoff, like everywhere. We try to aim for a readable, high level orchestration, then it doesn’t hurt if the specialized code is harder to understand. Almost like a DSL for your problem… :thinking_face:

pez08:09:01

Morning. Nice little nuggets there, @slipset. I’ll have to ponder them a bit.

slipset08:09:09

Notice here that this function accepts arguments in two different forms.

slipset08:09:26

Also, this function is generic for create/update/delete so it has to cater for all of them.

slipset08:09:11

I’d argue that most of the time when you call set you know if you’re doing a create, update, or a delete.

slipset08:09:54

And the convenience you get from being able to call set("foo", "bar") or set({"foo": "bar"}) is neglible.

pez09:09:30

Could it be that it was hard to update the call sites when they changed their mind about the signature?

simongray09:09:41

I think the Clojure core team is often a bit too dogmatic about this kinda stuff. Surely you can rewrite internal logic or refactor code in such a way that it doesn’t bother anyone. Isn’t that the point of having abstractions?

mpenet12:09:12

won't deadcode in cljs be compiled away in :advanced mode or something?

mpenet12:09:28

not that it's a good thing to leave dead code in there

borkdude12:09:05

@mpenet not that specific example

borkdude12:09:03

Looking closer into it, the newline function doesn't seem to be used anywhere either, so it's a very minor issue. The code just confused me since I thought flush was a real thing in CLJS, but it isn't, so the *flush-on-newline* dynamic var is nonsense as well.

lread13:09:22

I find "the golden rule is to change nothing - unless we're adding something or fixing a bug" very interesting. I favour maintainability by trying to make code understandable to myself and others. I've been comfortable making changes for maintainability because I feel somewhat protected by my unit tests. But... these "guard rails", as Rich has argued, might offer a false sense of security. If you change something you do risk breaking something. An interesting perspective.

❤️ 4
slipset13:09:08

Indeed. And changing something means there is something else you’re not doing.

borkdude13:09:11

It was David Nolen saying, and I generally agree with this sentiment.

slipset13:09:34

AKA opportunity cost.

slipset13:09:02

And there is the cost you incur on others, like reading the patch, QA, and what not.

lread13:09:33

Yep, true enough!

slipset13:09:13

Not to mention the risk of introducing bugs/breakage.

borkdude13:09:18

I personally think that's a gap in your test suite but yeah, different perspectives.

borkdude13:09:00

I've made an optimization in SCI which turned out to cause a bug but I was happier to have discovered this than not having done the optimization at all since I now have a stronger test suite

borkdude13:09:11

I think that's better than having to live with the fear that every change can ruin your users

borkdude13:09:34

But still, I generally agree with the golden rule

lread13:09:15

Something I will perhaps more keep in mind when weighing cost vs benefit.