Hacker News: ds300

New comment by ds300 in "Move tests to closed source repo"

ds300 — Fri, 27 Feb 2026 14:30:21 +0000

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

Patchfork: A new TypeScript util for immutable state

ds300 — Thu, 28 Aug 2025 09:44:49 +0000

Article URL: https://github.com/ds300/patchfork

Comments URL: https://news.ycombinator.com/item?id=45050262

Points: 1

# Comments: 0

New comment by ds300 in "Blocking Kiwifarms"

ds300 — Sun, 04 Sep 2022 07:43:31 +0000

Are you keeping a spreadsheet with venn diagrams?

New comment by ds300 in "Transition to React Native"

ds300 — Sun, 16 May 2021 08:17:20 +0000

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.

Show HN: Patch-package: Fix broken node modules instantly

ds300 — Tue, 02 Mar 2021 09:02:35 +0000

Article URL: https://github.com/ds300/patch-package

Comments URL: https://news.ycombinator.com/item?id=26313327

Points: 2

# Comments: 0

New comment by ds300 in "Ask HN: Who wants to be hired? (September 2020)"

ds300 — Fri, 11 Sep 2020 09:20:53 +0000

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

New comment by ds300 in "Rx glitches aren't actually a problem"

ds300 — Thu, 17 Dec 2015 16:09:35 +0000

> 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

New comment by ds300 in "Ask HN: Who wants to be hired? (October 2015)"

ds300 — Thu, 01 Oct 2015 16:15:29 +0000

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

Functional Reactive State

ds300 — Fri, 18 Sep 2015 10:42:31 +0000

Article URL: https://github.com/ds300/havelock

Comments URL: https://news.ycombinator.com/item?id=10238410

Points: 1

# Comments: 0

Show HN: Havelock – Holistic State Management for JavaScript

ds300 — Tue, 11 Aug 2015 08:48:49 +0000

Article URL: https://github.com/ds300/havelock

Comments URL: https://news.ycombinator.com/item?id=10039751

Points: 1

# Comments: 0

New comment by ds300 in "Om Next – David Nolen [video]"

ds300 — Wed, 08 Jul 2015 08:27:51 +0000

That README changed my life.

New comment by ds300 in "Clojure 1.7 is now available"

ds300 — Wed, 01 Jul 2015 08:55:04 +0000

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

This is wrong. You've missed the point.

    (map inc [1 2])

is actually roughly equivalent to

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

which, due to the use of `reduce`, is eager. To get laziness back:

    (sequence (map inc) [1 2])

Transducers are not reducing functions, they return reducing functions when applied to reducing functions. `((map inc) conj)` is a version of `conj` that calls `inc` on all the rhs args before `conj`ing them into the lhs arg.

New comment by ds300 in "Pixie: A sweet Clojure-ish language"

ds300 — Mon, 09 Mar 2015 12:51:29 +0000

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.

New comment by ds300 in "Comparison of the Go and Erlang concurrency models (2011)"

ds300 — Thu, 04 Dec 2014 10:01:21 +0000

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

New comment by ds300 in "If I ever design a first course in compilers, I'll do it backwards"

ds300 — Thu, 07 Aug 2014 15:11:40 +0000

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.