HackerTrans
TopNewTrendsCommentsPastAskShowJobs

lo5

no profile record

comments

lo5
·10 bulan yang lalu·discuss
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.
lo5
·3 tahun yang lalu·discuss
Agreed. Vrioon is my favorite -an exceptional album. The frequency range on those compositions is insane. Needs subs to truly appreciate it.
lo5
·3 tahun yang lalu·discuss
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...
lo5
·3 tahun yang lalu·discuss
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)
lo5
·4 tahun yang lalu·discuss
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/
lo5
·4 tahun yang lalu·discuss
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
lo5
·4 tahun yang lalu·discuss
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?
lo5
·4 tahun yang lalu·discuss
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.
lo5
·4 tahun yang lalu·discuss
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
lo5
·4 tahun yang lalu·discuss
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
lo5
·4 tahun yang lalu·discuss
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
lo5
·4 tahun yang lalu·discuss
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
lo5
·4 tahun yang lalu·discuss
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.
lo5
·4 tahun yang lalu·discuss
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
lo5
·4 tahun yang lalu·discuss
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?
lo5
·4 tahun yang lalu·discuss
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
lo5
·4 tahun yang lalu·discuss
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.
lo5
·4 tahun yang lalu·discuss
His masterpiece Semiology of Graphics is a treasure trove of novel visualizations.
lo5
·4 tahun yang lalu·discuss
> 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.
lo5
·4 tahun yang lalu·discuss
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.