lo5

Pi with rpiv-ask-user-question, pi-subagents (if you don't want to use tmux), pi-web-access (if you have a subscription to some search backend), plus agent-browser CLI. I don't miss anything in Claude Code.

I use Pi with only a couple of extensions and using less and less of CC and Codex everyday. It feels light and nimble. Codemode from yesterday's release made it even better. I wish I could use my Claude subscription via Pi.

Lead grades vary across the manufacturers. A Faber-Castell or Staedtler 4B is closer to a Japanese 2B. The four Blackwings are closer to Japanese 4B, 2B, B, HB.

The Blackwing Matte is close to a FC 9000 6B.

Wooden pencils are available in softer cores that have a very different feel from mechanical pencil leads. A 0.7mm 2B or 4B lead will break easily, so they're polymer-infused, and will feel very different (slippery?) compared a regular 4B graphite + clay core.

2mm mechanical pencils are more versatile that way, but also generally heavier, unless it's something like a Faber-Castell TK9400 or Kitaboshi Otona no Enpitsu.

I use pencil/paper extensively for notes/planning while I'm in front of the computer. I prefer softer grades because of speed and low effort. I avoided buying the Blackwing for a long time because of the hype surrounding it, but eventually caved in. Their Blackwing Matte is an excellent pencil, similar to the others I like - Musgrave News 600, General's Layout 555, Golden Sword, Eyeball Cedar Calligraphy, Mitsubishi Kohitsu Shosha, and those Triangle pencils sold at Daiso.

I'm not sure where the Blackwings are made. Definitely not the Kitaboshi factory. Probably Eyeball in Tokyo?

it depends on the codebase.

if there's adequate test coverage, and the tests emit informative failures, coding agents can be used as constraint-solvers to iterate and make changes, provided you stage your prompts properly, much like staging PRs.

claude code is really good at this.

Agreed. Vrioon is my favorite -an exceptional album. The frequency range on those compositions is insane. Needs subs to truly appreciate it.

Nitro has no events or callbacks. To display a page, you call a function, and the return value of the function is a tuple of inputs entered by the user. You then deal with those inputs, and display another page, and so on. There’s no ceremony. Like the readme shows, a seven page app is just seven statements one after the other. This paradigm makes it possible to write incredibly compact code.

As an example, here is a macOS calculator clone in ~50 lines of Python: https://twitter.com/crunchingdata/status/1563300652918325249...

Looks similar to Nitro https://nitro.h2o.ai/ and Wave https://wave.h2o.ai/ - both open source. Nitro already works with WebAssembly via Pyodide. (Author here)

Phonetic number systems like this are commonly used by memory athletes, like the Major System[1]

The usable range can be expanded further using color, smell, taste, and so on.

https://artofmemory.com/wiki/Major_System/

I love this!

I've achieved something very similar, but for Python[1].

I believe this approach will become the dominant paradigm in the future, precisely because of what of what you can't see - no API and no client/server separation - eliminates a whole bunch of accidental complexity.

My first startup a decade ago used a similar approach to build a exploratory visual analytics environment - lisps rock at this.

It's neat that Hyperfiddle subsumes data access, too. I have a similar compiler-driven approach that will ship later this year for desktop/mobile apps.

[1] https://github.com/h2oai/nitro

I understand that, but it's not much of an abstraction:

  const
   pyodide = await loadPyodide(),
   input = document.getElementById('#input').textContent,
   output = await pyodide.runPythonAsync(input);
  document.getElementById('#output').textContent = output;

I can see there are other tags (py-env, etc.) that provide some yaml to fetch additional assets, but again, nothing significant that warrants the hype.

Maybe I'm missing something?

Does PyScript offer anything of significance over and above what Pyodide already offers, other than several py-* tags?

In my experience, it's trivial accomplish this with Pyodide.

Here's a web worker that hosts Pyodide and loads packages, PyPI wheels, external modules, etc. and launches type=text/python script tags in-browser:

https://github.com/h2oai/nitro/blob/main/web/public/nitride....

About ~100 lines of code.

Related, I work on Nitro[1], which already offers a polished set of widgets, and a very simple way to author web apps using Python. I'll be releasing Pyodide support this week.

I also contribute to Wave[2], which provides a wide variety of widgets that can be snapped together quickly to build realtime dashboards/apps.

Both help non-front-end folks build web apps, and require no knowledge of HTML/JS/CSS.

[1] https://github.com/h2oai/nitro

[2] https://github.com/h2oai/wave

One of the problems with Slack/Discord desktop clients is that the message area (center column) tends to be far too wide on HD monitors (1200px+), making it difficult to read[1] anything that hasn't been manually line-wrapped.

[1] https://baymard.com/blog/line-length-readability

Related: Cormac McCarthy’s tips on how to write a great science paper[1]

> Limit each paragraph to a single message. A single sentence can be a paragraph. [...] > Keep sentences short, simply constructed and direct. [...]

[1] https://www.nature.com/articles/d41586-019-02918-5

I miss RAD tools too. Visual Basic was hugely popular two decades ago. The ease of building GUIs was unparalleled. That experience carried over to some extent with Windows Forms, WPF, Adobe Flex, etc., but not quite the same.

A decent blend of RAD and visual programming is the Max/MSP that ships with Ableton Live. It's fairly straightforward to build little audio/MIDI devices, then switch to visual programming for the implementation (objects/patchcords/control in Max terms).

> Doing GUIs only in code is tedious and boring.

Totally. But given that most GUI software these days involves client/server, I'm not sure if there's a simpler solution.

I work on Nitro[1] these days, and it's an attempt to make GUI development simpler and less tedious, primarily by trying to abstract away client/server programming and opting for a simpler way to program UIs without dealing with callbacks or event-handlers.

[1] https://github.com/h2oai/nitro

I was assuming you were referring to a declarative approach in your previous message.

The Ag Grid approach makes sense if data and vis need to be wired together programmatically.

Here's a ~4K line implementation of a useful GoG subset that you might find useful:

https://github.com/h2oai/lightning/blob/master/src/lightning...

It's used in H2O: https://github.com/h2oai/h2o-3

Yes. Tableau would have to separate rendering from data select/filter/aggregation, especially because integrating with customer databases live is a key use case. Hence the built-in buffet of connectors/drivers.

It looks like with later versions they switched to kind of a hybrid approach (part-remote, part-local) with Hyper to reduce latency for interactivity.

> there is no sharing of the underlying data set for multiple projections across the same large data set

But that would require some kind of open standard for portability, no?

This is definitely possible, and gives you a high degree of control over the visual design of visualizations.

I built an experimental system to do just that - design the layout and all data visualizations in a single Sketch/Figma document, export to SVG, then map data to the SVG elements in the browser. It's all 100% declarative.

Here's an over-the-top example: https://youtu.be/S9cmi89fvT8

There are no limits to what you can achieve with this approach, but obviously needs Sketch/Figma skills (or a colleague who does).

edit: typo

This has nothing to do with the GoG.

This applies to any charting library that forces you to provide both spec and unaggregated data to memory/cpu constrained clients (e.g. Javascript in the browser). This is done for implementation-simplicity (Vega, for example), but obviously doesn't scale to larger datasets.

I've implemented a system where the data part of the spec is munged in-database, and aggregated data is provided to the browser, along with hints for axes, scales, legends, etc. It requires a part of the GoG interpreter to be resident on the server-side.

His masterpiece Semiology of Graphics is a treasure trove of novel visualizations.

> With complex marks it is ambiguous what is a data point and what is a series.

I sort of agree with you. I've implemented the Grammar of Graphics from the ground up four times professionally (!), twice in collaboration with Leland, all in different products.

The main reason why it might be finicky to work with directly is that the point vs. series vs. series-of-series distinction can run arbitrarily deep, so there's some mental gymnastics involved on the part of the library's user how to refactor the data and present it correctly so that the library can do its thing.

Tableau, which is also a GoG system, sort of deals with this by having slots for "Dimensions", "Pages", "Color", etc. as proxies for multi-level aggregation ("group/slice/dice" in BI terms). So even though it's not immediately apparent to new users how to present data correctly to the rendering system to get the kind of vis they want, at least it's pretty low-friction UX to shuffle variables between those slots till satisfied.

With programmatic use, that shuffling-around gets cumbersome because now you have write code to munge data into submission.

Tableau introduced the "Show Me" feature precisely for this reason - most new users would rather get stuff done quickly than figure out how the GoG can best solve their vis problem.

The overview links to the book. See: https://ggplot2.tidyverse.org/

> ggplot2 is a system for declaratively creating graphics, based on The Grammar of Graphics.

Even more detailed is the original book by Leland Wilkinson, on which ggplot2 is based: https://link.springer.com/book/10.1007/0-387-28695-0.

The original implementations go back to SYSTAT and SPSS GPL (Graphics Production Language).

GPL especially, with its statement-based approach, has arguably better ergonomics for interactively and iteratively producing plots compared to function-based approaches.

H2O Wave has a similar (probably tinier) Grammar of Graphics API: https://wave.h2o.ai/docs/plotting

Leland Wilkinson (GoG inventor) and I designed it together a couple of years back.

The function for creating marks (a layer) tries to be as "flat" as possible, in the sense that it should be possible to render most common kinds of plots without having to pass nested/hierarchical options: https://wave.h2o.ai/docs/api/ui#mark