lo5
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'm not sure where the Blackwings are made. Definitely not the Kitaboshi factory. Probably Eyeball in Tokyo?
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.
As an example, here is a macOS calculator clone in ~50 lines of Python: https://twitter.com/crunchingdata/status/1563300652918325249...
The usable range can be expanded further using color, smell, taste, and so on.
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.
const
pyodide = await loadPyodide(),
input = document.getElementById('#input').textContent,
output = await pyodide.runPythonAsync(input);
document.getElementById('#output').textContent = output;
Maybe I'm missing something?
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.
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.
> Limit each paragraph to a single message. A single sentence can be a paragraph. [...] > Keep sentences short, simply constructed and direct. [...]
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.
The Ag Grid approach makes sense if data and vis need to be wired together programmatically.
https://github.com/h2oai/lightning/blob/master/src/lightning...
It's used in H2O: https://github.com/h2oai/h2o-3
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?
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 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.
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.
> ggplot2 is a system for declaratively creating graphics, based on The Grammar of Graphics.
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.
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