Fork me on GitHub

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

✌️ 4
👍 4
❤️ 4

And yet how many people turn away because the more “mainstream” editors are not there yet? When Calva for VSCode stabilizes it will be a game changer IMO. I just wish I could help somehow (other than bugging them to apply for funding!)

eccentric J03:04:17

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

eccentric J03:04:49

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 :)

Daniel Hines13:04:01

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:

Daniel Hines13:04:22

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.

Ivan Koz14:04:29

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

Ivan Koz14:04:23

Just curious, not an expert myself.

Daniel Hines14:04:36

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.

Daniel Hines14:04:26

But the author of Datascript has a different take:

Ivan Koz14:04:53

lemme read that

Daniel Hines14:04:17

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.

Ivan Koz14:04:43

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

Daniel Hines14:04:53

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

❤️ 4
Vincent Cantin19:04:27

@d4hines I love to hear that, I was a game developer before 🙂 But I think that gamedev is ahead of software dev in some ways and it’s the opposite in some other ways.

Vincent Cantin19:04:20

I used to count CPU cycles when I was optimizing graphical routines. Software developers would never do that.

Vincent Cantin19:04:05

Software developers would reuse most of their code from 3rd parties … many game devs have hard time doing that.


true, software developers (myself included) are often not even the end users of the software they write, in any shape or form. I'm sure we have more context with game development

Ivan Koz14:04:24

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

Ivan Koz14:04:38

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!

Ivan Koz14:04:36

@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


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?

Daniel Hines16:04:15

Not sure. I somewhat doubt it. But, if there really is benefit to be had in the approach, I would bet we have the upper hand. Macros seem a lot easier than compilers.


Game devs like Entity Component I believe


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


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


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

Drew Verlee20:04:28

Watching, 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 ...

😆 4
eccentric J21:04:18 this article explains how they used CES to create a game in ClojureScript

👍 4
eccentric J21:04:25

Someone in this community sent me this link a few months back, can’t remember who though 😭