Rosenbaum, Ron. 1999. “The Last Luddite Gets Wired.” Slate. https://slate.com/news-and-politics/1999/05/the-last-luddite-gets-wired-4.html (May 11, 2026).
9 Matching Annotations
- Last 7 days
-
slate.com slate.com
- Sep 2025
-
www.youtube.com www.youtube.com
-
the answer is you can know it, but but you know it when you let go of all concepts and you don't try. If you're trying to get there, then you don't see what you already are.
for - A Answer - you know it when you let go of all concepts and you don't try. If you're trying to get there, then you don't see what you already are. - Donald Hoffman
-
- Feb 2021
-
github.com github.com
-
No one has requested it before so it's certainly not something we're planning to add.
-
To give a little more context, structures like this often come up in my work when dealing with NoSQL datastores, especially ones that rely heavily on JSON, like Firebase, where a records unique ID isn't part of the record itself, just a key that points to it. I think most Ruby/Rails projects tend towards use cases where these sort of datastores aren't appropriate/necessary, so it makes sense that this wouldn't come up as quickly as other structures.
-
- Sep 2020
-
github.com github.com
-
Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
-
Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.
Tags
- component/library author can't consider/know ahead of time all of the ways users may want to use it
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- explicit interfaces
- burden
- workarounds
- forking to add a desired missing feature/change
- maintenance burden
- being explicit
- Svelte: how to affect child component styles
- maintenance burden to explicitly define/enumerate/hard-code possible options (explicit interface)
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
- ugly/kludgey
- forced to fork/copy and paste library code because it didn't provide enough customizability/extensibility / didn't foresee some specific prop/behavior that needed to be overridable/configurable (explicit interface)
Annotators
URL
-
-
github.com github.com
-
This has already forced me to forgo Svelte Material because I would like to add some actions to their components but I cannot and it does not make sense for them to cater to my specific use-case by baking random stuff into the library used by everyone.
-
The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under the sun. Rather, they could just mark a recipient for actions on the component (assuming there is a viable target element), and then consumers of the library could extend the component using whatever actions they desire.
Tags
- component/library author can't consider/know ahead of time all of the ways users may want to use it
- reusability
- flexibility
- extensibility
- pass-through arguments/props/options
- why this feature is needed
- Svelte: action (use:)
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
Annotators
URL
-
-
github.com github.com
-
Your LazyLoad image is now inextensible. What if you want to add a class? Perhaps the author of LazyLoad thought of that and sets className onto the <img>. But will the author consider everything? Perhaps if we get {...state} attributes.
-