ds300

the issue was created by claude using this skill https://github.com/tldraw/tldraw/blob/main/.claude/skills/wr...

trust me this was never a serious proposal

Are you keeping a spreadsheet with venn diagrams?

Artsy.net has had quite a bit of success with a brown field RN app. We adopted RN in our iOS app in 2016 and gradually used it to render more and more screens in the app. In 2020 we decided it would be nice to have an android app, and we spent the last year incrementally refactoring the app infrastructure from Objective-C to TypeScript to support that. Crucially we did the entire thing with a tiny team of 1-3 people and without blocking any product engineers from shipping new features.

We had occasional tooling issues like you describe but all fixable. I'd be happy to go through the same process again.

Location: London, UK

Remote: Yes.

Willing to relocate: Probably not, but perhaps if the right opportunity comes along.

Technologies: Currently focused on TypeScript, GraphQL, React Native and Node. Previously Java, Clojure, Web.

I'm a darn good full stack product engineer with a lot of experience building and refactoring web/mobile client infrastructure. I've got solid UI design skills and a keen sense for UX. I'm good at planning and executing long-term refactors, building core app infrastructure, optimising CI workflows, automating processes. I put business value and happy users above software craftsmanship, but I've spent a lot of time maintaining old codebases and I have a good understanding of how architectural decisions, and even idiomatic patterns, can impact developers' productivity years down the line.

If you're building modern developer tooling that touches the JS ecosystem, we should talk. Bonus points if you get to work with Rust or C++.

CV: https://github.com/ds300

Email: d.j.sheldrick@gmail.com

Glitches as demonstrated via the diamond pattern can be avoided by traversing the graph in topological order.

This is correct for DAGs which only propagate value (as in Javelin[1] and my own library DerivableJS[2]), but for graphs which propagate events (as in Rx), topological sorting would only work for those parts of the graph which are effectively propagating value. Events don't have an inherent dedupe operation, so it is very difficult to even imagine ways in which glitch avoidance could be automatically enforced. It would certainly require semantic program analysis.

Personally I think we should be avoiding the proliferation of events (as encouraged by Rx enthusiasts) for exactly this reason. Their imperative nature makes them very difficult to reason about.

[1] https://github.com/hoplon/javelin

[2] https://github.com/ds300/derivablejs

Location: Brighton, UK

Remote: Yes

Willing to relocate: Yes in western Europe

Technologies: JVM, Clojure, Java, Node, JavaScript, DOM, React.

Résumé/CV: http://github.com/ds300 - no CV, haven't had time yet

Email: djsheldrick at gmail

PhD dropout, 2 years full stack web dev. Good with data + functions, uses objects + methods very sparingly indeed. Designs high quality abstractions. Cares deeply about making and using good tooling. Knows how to make stuff run fast when the need arises. Wants to learn how to do event sourcing in the large. If money was no concern would be writing virtual machines (think JVM not VMWare).

That README changed my life.

(reduce (map inc) [1 2]) ;; same as (map inc [1 2])

This is wrong. You've missed the point.

    (map inc [1 2]) 

    (reduce ((map inc) conj) [] [1 2])

    (sequence (map inc) [1 2])

Who got rid of the JVM? Pixie is not Clojure 2. Clojure still exists and you can use it, but now Pixie also exists and you can also use it. There is no downside unless you think developing languages which don't run on the JVM is a waste of time.

With goroutines the cooperation is handled by the implementation/compiler -- i.e. Yield() calls are automatically inserted by the compiler -- rather than by the programmer manually by hand.

The compiler only inserts yeilds at some call sites. It's not a total solution like real preemptive scheduling, so you still need to be careful.

I was a TA on a compilers course that worked backwards. I'd taken the course myself two years earlier when it was taught by a different lecturer and found it excellent, and most of my cohort agreed.

When reversed, however, most of my students found it extremely hard to wrap their head around the the first part of the course, i.e. code generation from an AST. They didn't have sufficient grounding in recursive data structures and algorithms. While this might be a problem with the degree program rather than the compilers course, I believe that learning to write a recursive descent parser (by hand) provides this grounding and makes the code generation bit much easier to grasp.

Unfortunately the new lecturer had also done away with teaching the students how to write parsers by hand, instead encouraging them to use parser generators. I thought that was tragic. One of the best moments of my programming life was writing a recursive descent parser for a non-trivial grammar in one sitting (about 500 lines of python), hitting run and having it just work first time. It was orgasmic.