I think it's actually due to "pelican on a plane" isn't the same as "pelican on an airplane" (Sonnet5 @ Flamingo x Plane), some consistent and warranted semantic/linguistic confusion!
HN user
ramses0
Another slew of utility lies in `:help searchoffset`, often like the following: https://til.codeinthehole.com/posts/about-vims-semicolon-sea...
/x/e-3
/x/+1
/x/;/yz
...it allows near arbitrary cursor placement (eg: this blog articles "squiggle" situation) to be able to find the beginning of the squiggle, or the end of the squiggle (or temporarily using "X" and "Z" for start/end, and "clearing" it with `V...:s/[XY]/./g`...and BUTTONS! Pebble's capabilities are excellent b/c the UX of a ~1.5" screen is wildly different than that of an iPhone. Up/Down/Forward/Backwards and the occasional long-press is an excellent match for on-the-go interaction.
I absolutely hated brushing the iWatch screen and triggering random crap and there was no other way to interact with it! Garmin's w/ 5 buttons and transflective (sunlight-readable) displays have been the closest alternative, and they have a pretty cool "touch-screen alt mode" which you can access via press+hold on two of the diagonal buttons to enable/disable (or automatically starts if you open up the "maps" app for dragging it around).
Long battery, sunlight readable, buttons.
Mitch Hedberg... "I want to get a job at the Kitchen Appliance Naming Institute: Refrigerator, Toaster, Blender.. you just say say what it does, then you add '-er' What's this thing do? It keeps shit fresh. Well that's a fresher. I'm goin on break."
...and the Ally ISN'T EVEN AN XBOX!!!!
"""AI Overview: No, the Asus ROG Ally is not actually an Xbox. It is a handheld Windows computer made by Asus, even though it features Xbox branding and uses an Xbox-style controller layout"""
George Bernard Shaw, Man and Superman (1903): "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
http://www.catb.org/~esr/writings/taoup/html/end-user.html
"""Master Foo turned to the end-user. “Tell me”, he inquired, “why do you seek the Way?”
“I am discontent with the software I see around me”, the end user replied. “It neither performs reliably nor pleases the eye and hand. Having heard that the Unix way, though difficult, is superior, I seek to cast aside all snares and delusions”."""
SCADA. Mechanism Design. ANSI/ISA-18.2-2016. NASA "Power of Ten" Safe Coding. "The Pit of Success". Poka Yoke. Kaizen/Seiton. "The Five S's". Fuben-eki ("The Benefits of Inconvenience").
It makes sense even more. If you never enter "insert" mode, you still have powerful navigation and overview capabilities. `*`, `#`, n/p, :set fdm=indent + zM/zR, gf/gx, :bp, the venerable `}/{` pairing, and simply `C-n/C-p` while composing prompts can be useful.
AI + Prompting can get you there, but it's still fairly laggy. Honestly, VSCode (aka: Cursor) w/ the vim plugin, and `F2-rename` has been the sweet spot for me. Reviewing diffs with `git diff | view -` and browsing them with vim is another useful.
:wq
There was an old blog post comparing pianos to text editors.
A "simpler" piano would only have white keys, but to a piano expert the piano appears invisible (and powerful) after the initial learning curve.
I think an important attribute of mastery is related to consistency over time. Microsoft Word '95 vs 2007 (the ribbon) is a great example.
Mostly MS's keyboard shortcuts have been consistent (Alt-F4, Ctrl-B, Alt-F-S), but their UI has been inconsistent (making mastery harder).
In any case: "tools for experts may seem initially awkward to non-experts"
...and: "initially non-awkward tools may hamper capabilities as the operator skill increases"
Meta: in addition to upvotes and downvotes, we almost need a slop/not-slop slider.
This one barely scrapes by at what feels like 30-40% "slop": "honestly", "the one thing", etc...
...but I did learn something about "Brand" types, and have personally tried to do more of "parse don't validate" in my own code.
Recently I did this similar trick for `exec( ValidExecutable(...) )` [python], where it required tagging/washing through a private function/variable to "get" the private bit.
All the scanners tend to light up when they see "exec" at all (eg: `exec( "pandoc" )` for PDF generation), but I needed to hard code a few "expected" pandoc locations so the imaginary hackers couldn't shadow "pandoc" on a path location they controlled.
That’s amazing! I am just imagining a room full of programmers with slightly divergent crontab start times all playing a "moo" sound effect, seemingly at random... not a bad ambient information radiator, actually!
So I made a comment a while back about lilypond: https://news.ycombinator.com/item?id=46148831
A salient extract:
...but why is it so complicated? A novice interpretation of "music" is "a bunch of notes!" ... my amateur interpretation of "music" is "layers of notes".
You can either spam 100 notes in a row, or you effectively end up with:
melody = [ a, b, [c+d], e, ... ]
bassline = [ b, _, b, _, ... ]
music = melody + bassline
score = [
"a bunch of helper text",
+ melody,
+ bassline,
+ page_size, etc...
]
...so Lilypond basically made "Tex4Music", and the format serves a few dual purposes...[snip]That's a really great reframing: "predictability"
...I think we've been exponential (or s-curve) w.r.t. repeatable predictability that _smaller_ prompts are yielding. eg: `regform.php: register( first, last, address, email )` would have had a 30% "one-shot" outcome 1-2 years ago, but closer to 90% "one-shot" outcome this year.
Smaller prompts == wider outcomes... potentially wider (larger?) prompts == smaller outcomes?
As we're "committing" code (blacksmith-type), presumably it's b/c we've reached a plateau of "probably works right" and includes some level of testability and fitness-for-purpose, ie: we've rolled the dice enough times and are committing the current "yahtzee" board to the repo.
16 years ago I've been advocating effectively that "acceptance tests are more valuable than the code under test" (b/c given sufficient acceptance tests, it's "trivial" to reproduce the code correctly... but given the code and no tests it's at least an order of magnitude harder to prove correctness)
http://www.robertames.com/blog.cgi/entries/to-upgrade-or-not...
It's again the dual hourglass shape of consensus between creation and acceptance, and LLM's (when used well) are helping to compress the two sides together around an "exact" agreeable crystallization.
"I want you to calculate pi" (wide hourglass) <=> ...etc... <=> [(precise code/assembly) <=> (precise validation)] <=> ...etc... <=> "pi should start with 3.14", "pirr should equal area", ...etc...
...but throughout time, we as developers have been the human interpreters / vessels via "english-to-buggy-code", and now we have this whole new set of (semi-unpredictable) tools. Think of woodworking (hackers), with hand-tools and eventually moving to power tools w/ jigs. Some things are lost, but others are gained! Maybe we're needing to come up with "jigs" (or "harnesses?" ;-) to strap around our new LLM power-tools?
Closing thought... I've done some sketchup modeling, eg: mocking my kitchen to consider a remodel. "Models must represent to a precision useful for their purpose". Counters, sink, fridge... cool! But then, should I include the toe-kick cutout, or cabinets == flat boxes? Should I include the counter overhang? What about representing the cabinet doors? Should I include the cabinet knobs? Should I actually measure the true openings down to the 16th inch? Validate that they're 90deg rather than 88deg square? On the counter overhang, should I include the rounding? What if it was routed, is the shape of the overhang important?
Basically, reality has infinite detail and our "captured models" of the problem domain are always working at a level of detail that is "fit for purpose". Design a nuclear power plant? LLM == "probably not". Design a local CD ripper GUI for yourself? "the level of detail and correctness is probably fit for purpose"
Yeah, but IP address is "obviously" correlated with a distinct/persistent tranche of users. It's surprising that volume c_time is both more persistent as well as more unique than IP.
```Based on a binomial/Poisson distribution and a baseline of 21 million U.S. device sales per release, a fingerprint relying on "seconds since setup" fails to uniquely identify individuals. In the high-density Early Adopter phase, you will share your exact setup second with an average of 1.01 other people (a total matching pool of ~2 people). Six months into the cycle, you will still share that second with an average of 0.68 other people.```
In the U.S., device setup time (to the second) very conservatively gets you clubbed into a single group of 100 individuals as an "advanced persistent threat" tracker. Even compressing activations to "80/20 during business hours" the math kindof maxes out at a pool of ~5 people, and assuming worst case "20x" of that still means you're still pretty darned identifiable.
If you get ~6-8 more bits of entropy (eg: Device Type + Capacity is easily 2-3 bits, and Time Zone is probably another 2-3 bits) you're cooked!
"A compiler is free to optimize...", on sufficiently basic prompting "make me a user address collection form that writes to a database table called 'registered_users'..."
...I agree it's not deterministic (neither are all your variations of C compilers, neither is Firefox v Safari v Chrome), but it probably Does Something(tm), and I might not want to peel back the covers and see how it used React, or Vue, VanillaJS, QT, or GTK.
It's upsetting that we are _committing the generated code_ rather than being able to use better and better optimizing compilers against the original prompt of: "make me a user registration form with database connection"
...I'm very with you on "it's not an accurate analogy", but I'm pointing out that there have been sea-changes already w.r.t. strict adherence to the generated code, or inclusion of left-pad v react libraries.
...and there have been corresponding productivity gains (debatable? ;-) when we've worked at these higher levels of abstraction.
I'm personally still in the "blacksmith" stage of working with AI output (put it back in the fire and beat on it a bunch more times), and shudder in horror at the thought of maintaining (or paying to maintain) megabytes of hours of token generation that looks like source code.
I'm hopeful that we'll eventually strip out some of the mud between the CPU and putting pixels on the screen (with the help of LLM's?), and that we'll still be able to understand and reason about the real "DAG" of what our programs are trying to do (eg: declarative guis, kindof like we have declarative sql), but there will always be a muddy middle part where the computer/complier/LLM is doing something in between that _is_ sufficiently reliable for us to ignore those bits most of the time.
Don't tell me you're reading all assembly generated by your local golang or javac compiler? And that you've read every line of code down the dependency tree for your node_modules?
I'm just upset that we are throwing away the original prompts for generated code in such a cavalier fashion.
I'm looking for a better video of it (from one of the engineers), but look at the NASA robot hand. https://www.youtube.com/watch?v=vfDXzkFHnz0
https://www.google.com/search?q=nasa+robonaut+video+hand+why...
The gist of it is that all tools on the spacecraft (eg: space-drill, space-coffee-maker, space-airlock) are all designed to fit a gloved human astronaut hand. Waaaaay more complicated to make a robo-hand than a robo-suction cup or robo-claw, but then you are matching the environment, and guarantee tool compatibility against all extant tasks!
We already have specialized robots on earth... paper slicer, lawn mower, bazooka, whatever. They're all machines that are specialized for the task at hand, we're not making a humanoid robot that gets down on all fours and individually plucks blades of glass.
The car factories already have specialized robots... they're not mimicking a human hand holding a can of spray paint, shaking it up, and painting the car that way... it's a 6-axis arm, or a whole "grab the car and flip it while spraying paint" system.
It's not about inventing purpose-specific robots, it's about handling that long-tail of "stuff with tools that a human is designed to be able to use." Go over there, push that button. Go move that box from table1 to table2. Etc.
For well defined tasks in the factory domain, make a "real robot". For ad-hoc tasks in the interim... strap an LLM to a camera, battery, robo-legs and arms, cross your fingers, and hope for the best?
...maybe some sort of "Software Bazaar", where the users of the software can edit their own software and make local modifications that they need to it, probably with NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
https://en.wikipedia.org/wiki/GNU_General_Public_License
It'd also be really nice that if you received some such software that you'd have the right to run the program as you wish, study how the program works and change it to make it do what you wish, and the freedom to redistribute either the original, or your modifications to the software?
https://en.wikipedia.org/wiki/The_Free_Software_Definition#T...
...we can dream though, can't we?
Thought of you this afternoon, "after you click the record button can you make a 'boop, boop, boop, clack!' like a lead-in from a from a clapboard (using web audio synthesis apis)?"
...was quite surprising the result!
https://www.passwordstore.org/
git + somesite.com.gpg
https://github.com/FiloSottile/passage (or: forked using AGE instead of GPG)
And/Or: `*.par` files.
I'm stupefied by the accuracy of the SP/LP/EP rendering differences. Apart from how "accurate" everything is, that one pushed it way past the uncanny valley and into "oh yeah, that's pretty much exactly what it looked like!"
How much have you mucked with `pi`? I love the "zero overhead" aspect of the short agent/system prompt, but I can just imagine the waiting and potential dead-end's it'd get itself into if I just let it rip on a random task.
Housekeeper. House Cleaner.
The first organizes things and may do the laundry or put away groceries or something. I wouldn't know for certain, as my income doesn't yet reach to those heady heights.
The second vacuums, mops, cleans bathrooms, etc.
That's a frying pan => fire situation. I started my home automation journey in the same way, and being HK-centric is pretty decent. HA with 100% local-control devices that _bridges_ to HK is what I'm looking at next.
Often, the HK-only devices are terrible wrt WiFi stability, and I need to pay more attention to how matter/thread is working lately.
I know some people complain about zigbee/zwave but they've been way better on average than HK over wifi.
Huge +1 here! Work out scenario planning of Meshtastic/Meshcore with one of the GPT's and they top out at like ~100k users and like 10msg/sec or something ludicrously low.
At something like $100/node and 5000 nodes in a major metro (eg: Dallas) it's like a $500k investment and you're maxed out at low data rates and saturated topology.
That's 5k nodes in a (generous) 5 million population and ~500 square mile area. More like 9M people and 9000 square miles. (I checked, and that's "extended metroplex", but reasonable: Decatur to Cleburne, Weatherford to Kaufman).
At 5k nodes saturating an area, it's basically a rich persons toy very well suitable to remote or low-density areas, but NEVER for 1:1 saturation deployment in any sort of high density area.