Hacker Newsnew | past | comments | ask | show | jobs | submit | lo5's commentslogin

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.


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)


Hey! What's the difference between Nitro and Wave? Wave seems like a great fit for my usage.


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...


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


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.


Maybe what it offers is abstraction. Boilerplate not required for immediate results, just a pyscript tag.


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?


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: