This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # beginners (82)
- # calva (13)
- # cider (12)
- # clara (4)
- # cljdoc (22)
- # clojure (89)
- # clojure-dev (23)
- # clojure-europe (16)
- # clojure-italy (39)
- # clojure-nl (8)
- # clojure-spec (28)
- # clojure-uk (36)
- # clojurescript (40)
- # cursive (10)
- # data-science (1)
- # datomic (27)
- # devcards (4)
- # emacs (1)
- # fulcro (25)
- # jobs (1)
- # jobs-discuss (3)
- # kaocha (5)
- # luminus (1)
- # nrepl (68)
- # off-topic (64)
- # pedestal (23)
- # planck (1)
- # quil (4)
- # re-frame (6)
- # reitit (5)
- # remote-jobs (4)
- # shadow-cljs (16)
- # spacemacs (11)
- # testing (1)
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
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!)
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?
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/
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 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.
I used to count CPU cycles when I was optimizing graphical routines. Software developers would never do that.
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
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
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.
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.
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.
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.
When you only need a few columns, and perform mostly scan operations, loop on the entire row set, a columnar structure is faster.
Ya. In practice, it makes Entity Component systems similar to traits or mixins. Or since we use Clojure, protocols!
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
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.
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