I’m sad I missed the editor and open source discussion. I love that emacs is built by volunteers over decades and anyone can read the source to cider and modify and tweak and fix and improve it. And I love that basically 50% of the user base uses it and that 50% of the user base pays Colin for an exceptional product

That’s great @seancorfield, I think that’s kind of amazing to consistently get more docs than implementation. It’s been happening a lot in my most recent side project https://github.com/eccentric-j/benfrankenberg.com/blob/master/src/com/benfrankenberg/app/animation.cljs

so I was curious if others have experienced that situation as well and if it was considered good, neutral, or bad

once i figured out a way to collapse my docstrings, i found myself more willing to write longer ones and not feel disrupted by long ones when navigated source in my editor :)

Thoughts on Svelte anyone? I didn’t realize any of these were problems I needed solved for me, and am still not entirely convinced, but it’s an interesting take: https://svelte.dev/blog/svelte-3-rethinking-reactivity

One of the author’s main beefs is that VDOM diffing isn’t true FRP, and it’s needlessly inefficient. I think this is mitigated with persistent data structures. But perhaps static analysis of the code could still yield performance gains even in ClojureScript.

@d4hines do you even know anybody who has vdom diffing performance issues with reagent?

Just curious, not an expert myself.

I think the Svelte guys are thinking about animations, as well as high-throughput realtime applications (say, a dashboard of stockmarket prices or something). Personally, I’ve only ever had problems when I did something nonsensical. Usually tweaking things makes problems go away entirely.

But the author of Datascript has a different take: https://tonsky.me/blog/slow-wrong/

lemme read that

Definitely worth it. Pretty much anything he writes is usually insightful.

I'm not sure that's his take, but it might be. Sometimes it's worth trading off a little performance for gains in other areas.

@d4hines https://youtu.be/yy8jQgmhbAU?t=2066

interesting talk around the same topic tonsky speaking about as i see it

Why are game developers so ahead of us in some things?!

It's just complex field which requires all the parts of CS.

I mean what it even means "ahead"?

game devs hate OO because of its poor performance optimisation properties. That's what I learned watching a Jonathan Blow video long ago. It's the same reason lots of devs like mutability!

@michael.e.loughlin probably by "performance optimization properties" you've meant parallelism and concurrency complexity of mutable oop?

IIRC Blow was referring to Array of Structures vs Structure of Arrays, and each strategy's caching behavior https://en.wikipedia.org/wiki/AOS_and_SOA

I'm sure there are many more reasons game devs dislike OO than just that, though 😉

Is it possible to even use Svelte from CLJS? With it being a compiler?

Game devs like Entity Component I believe

Because of this: https://en.m.wikipedia.org/wiki/AOS_and_SOA

Where OOP normally uses a Array of Structs. Entity Component uses a structure of arrays.

Which I've heard is faster, because the world rendering has to constantly loop over all elements, and it's more performant to do that at the column level.

Since it doesn't require access to all fields, but mostly positions and a few others

https://en.m.wikipedia.org/wiki/Entity_component_system

It's fun to read about.

Basically, each component is a set of data needed to perform some logic. And a system is code which performs the logic using a given component state.

Entities get assigned components as needed.

Lighttable was designed to be similar to a "Component Entity System"

Ya, I think it used that design

What happens is, since systems operate on only subset of the data that each entity has. It is more efficient to store the data for the entities in a SoA layout.

Same as column store vs row stores.

That's fascinating

When you only need a few columns, and perform mostly scan operations, loop on the entire row set, a columnar structure is faster.

Especially if columns have a limited number of types, I guess

Ya. In practice, it makes Entity Component systems similar to traits or mixins. Or since we use Clojure, protocols!

Except that its memory layout is SoA instead of AoS

I wonder if AoS has benefits over SoA for serialization and streaming evaluation though

Well. AoS will be faster any time you need to entire record

right

Which is true in cases where you are reactive. Like SoA works well for games, because they have a render loop.

Basically, constantly looping over everything. Where as most non game app are more evented

You access things in an indexed fashion

Which works better with AoS

A game won't for example move an object that was clicked on.

Until the next render loop

I'm not explaining that one very well.

Basically, I don't know how useful it is when there is no world. Like in a typical backend

But ya. It's cool. It's very data driven as well. Since actions just change the state of entities on their components. But all side effect is managed by the systems when they scan over the entities

Watching https://youtu.be/bi2Zd4ZmIsw?t=278, curious if anyone wants to chat about it. So F-expressions are traditionally considered slow because an intelligent interpretation of the symbols would need to account for run time arguments? e.g (when x true false) would need x to eval first, so certain optimizations couldn't be done? Heliotrope's Lift object offers a way to evaluate and optimize everything except for the runtime related arguments? Also, if anyone has a good resource on understanding the JVM i would be grateful.

just struck me: leiningen has a project.clj file ...

https://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/ this article explains how they used CES to create a game in ClojureScript