DuckDB is awesome.

If you want it's power as a query engine but like to write python instead of SQL, I highly recommend using it as a backend for the Ibis dataframe library

It let's you interchange pythonic dataframe syntax (like Pandas and Polars) with SQL that 'compile' down to SQL in DuckDB dialect

And you can use those queries interchangably in postgres, sqlite, polars, spark, etc

https://ibis-project.org/

Even cooler is that Entity-Component System was literally invented to create this game, in the form of the Dark Object System.

It's one of the most successful patterns in game dev and it's remarkable it came from 90s game dev where "composition over inheritance" was not at all a virtue like it is today

Try the Dark Parade mod campaign. It's so much better than the vanilla missions. Some of the best modding I've ever seen

I found out about that one through mortismal games and loved it, i actually played through that campaign almost entirely on a stream deck!

I don't know though if it would be as good to someone who's played it first before the main game(s)

Looks like I'm in for a treat. Enjoying TDP quite a lot already :)

> the Dark Parade

You probably meant The Black Parade (a mod for Thief I), not to be confused with The Dark Mod (a standalone thief-inspired game based on the Doom3 engine)

This is so cool, what I was hoping/expecting the post to be like

I actually like node based editors but LLMs are the nail in the coffin.

Visual programming just doesn't make sense in a world where "low-code" users can safely be assumed to be using llms

I expect I can drag and drop nodes to solve a problem faster than you can vibe-code a solution. Plus a node-based solution is likely to be more maintainable if your aren't a coder.

Let's see! I'm actually working on a node-based programming LLM paradigm for an app I'm building.

The idea is that you can write the 'nodes' in plain english rather than pre-written blocks, and then the arrows indicate the flow but don't need to absolutely encode everything (closer to a flow chart). The process of writing the flow chart helps define and document the business logic, and the flows are totally clear because everything is encoded into a state machine.

I am unconvinced that natural language is the best way to describe a data transformation problem.

My personal sense is business logic which involves processes with lots of steps rather than data transformation.

I’m unconvinced that code is the best way to describe business logic, so here we are! :)

(Code is probably the best way to encode business logic, but most users can’t read it or edit it, which makes it bad)

Good luck with your project. It is a tough problem you're solving, but hopefully your idea has wings.

Thanks! It's in a very narrow domain (Handset UI flows in Warehouse Management Systems) so i'm hoping that helps, but it's very domain specific and certainly not anything mainstream.

In a world where node based editors and code are also equivalent to LLMs, it's not super clear to me that the future will not be nicely visualized and understandable nodes (generated by the LLM to explain things to me and to get guidence) kept in sync with the codebase.

Yes, it genuinely does make me happy, every week I find several things that make me smarter.

Is the the only social network that is not enshittified or dominated by inane algorithmic slop.

The LLM arguments are boring but exist literally everywhere online discussing technology

I can't wait for companies like this to run out of money

This has quickly become my favorite TUI text editor, even though it seemed like "yet another editor" when I first came across it

As someone who doesn't like modal options I used nano, micro, and ox in that order but Flow is a much nicer product than those 3

If you like helix it can also just us the modal editing and keybinds from it as well

Does it worth using flow over vim, or micro if you're a micro user?

As a helix user I tried it out, but I didn't see particular reason to switch to this.

Yeah it struggles with long tail languages. Zig in particular since even within the small training set there have been many versions with breaking changes

Fil-C is way too new for LLMs to understand it and not just hallucinate back into normal C

Well, that's what the checks are for: So that hallucinations are caught by said checks and can be fed back into the LLM to ruminate on.

If you don't find importance in those checks, you wouldn't choose Fil-C anyway. But, of course, it remains that if do find those checks to be important, you're going to use a serious programming language like F* anyway.

There is really no place for Fil-C, Rust, etc. They are in this odd place where they have too many checks to matter when you don't care about checks, but not enough checks when you do care about checks. Well, at least you could make a case for Fil-C if you are inheriting an existing C codebase and need to start concerning yourself with checks in that codebase which previously didn't have concern for them. Then maybe a half-assed solution is better than nothing. But Rust serves no purpose whatsoever.