Aardappel

It's not a DAG though, it is purely a tree (no shared children). There are no cell addresses.

You can kinda sorta use it as a spreadsheet, but it is pretty limited currently, see example here http://strlen.com/treesheets/docs/images/screenshots/screens... or also in the tutorial.

This is an app I started in 2008, and at the time getting the speed of native was important to me. I work with very large "sheets"

I also wanted to get to something which could be useable for me as quickly as possible, which at the time for me meant a native app. I also wanted local file storage etc.

Agreed that in 2021 you could probably make this work as a webapp, though I think it would still be a challenging engineering exercise to make it fast.

The bottom download link points you to GitHub, where you can get exes straight from CI, if you trust that more.

I've looked into getting https from my site, but there's always a high cost associated, if you want a certificate that's widely accepted (which doesn't seem to hold for the free ones). And I think my host isn't even compatible with free ones.

If the web wants HTTPS everywhere, this somehow needs to be made simpler/cheaper for non-commercial entities.

It's one of my 10 or so side projects. Sadly while TreeSheets is pretty popular with users, it doesn't attract a lot of programmers to contribute (probably my ancient looking code!).. more of them would help.

It's become a little more extensible recently with the addition of a scripting language.

But yeah, PRs welcome!

I actually wrote TreeSheets after I became a heavy user of mindmaps, and found the information density and organizational abilities to be very lacking. As well as rendering/editing speed for larger maps (in freemind).

Mindmaps look very 2D, but essentially its just a left and a right tree, with no other horizontal organizational methods. TreeSheets truely lets you create any 2D hierarchy you can dream of.

TreeSheets is written with wxWidgets, which sadly has very disfunctional or even missing mobile ports. Likely you'd want to redo the whole UI anyway for this to function on a phone screen.

Then there's the matter of file storage.. it would need to hook up to some kind of cloud account etc.

In all, the amount of effort to bring this to mobile might possibly be the same as writing it from scratch.

Though.. PRs welcome! :)

I am not aware that it is outdated. If you found inaccuracies, please open an issue, or better a yet a PR for the file https://github.com/aardappel/treesheets/blob/master/TS/docs/...

Yes, it is a custom binary format, for speed and compactness. It does however export to many formats, xml, html, text, csv etc. There's even an example JSON exporter for the scripting language. More could be added.

There's not really a standard tree file format that would allow storage that can interop with other formats. Yes, there's of course JSON and XML, but you'd end up with a file with so many custom fields it is not interoperable. And these formats are extremely inefficient compared to the current binary format.

The binary format is also able to store images inline.

It's an app that has been worked on on/off for 13 years, so certainly not intended be "proof of concept".. but yeah, it's a 1 person OSS side project, not a commercial app with UX designers on staff.

If you have specific ideas about what is so limiting, please file a github issue.

Author of TreeSheets here, AMA.

(author of treesheets here) not sure who username strlen is, but it's not me :)

But yes, TreeSheets was initially designed just to be perfect for my needs. It has existed since 2008 though, so it has plenty of general usability tweaks for others since.

The computational sub-language is indeed very weak. It can at least do `sum` though, which is 99% of my uses of spreadsheets :)

I did see it! Let me know if you have feedback to improve it.

If you want a statically typed language with Python-alike syntax but Nim is too "noisy" for you, then Lobster (http://strlen.com/lobster/) is likely spot-on.

There are actually quite a lot of languages that do something in the realm of owning/borrowing, see my link above for a partial list (which includes Nim).

Nim's views (and also their ORC system) is closer to Rust/Swift/C++ than it is to Lobster, in the sense that it is all very explicitly programmer driven with explicit type annotations.

Lobster's system is fully automatic and almost entirely transparent to the user.

Congrats to V on implementing the compile time memory management technique from http://aardappel.github.io/lobster/memory_management.html, like you mentioned on Discord.

Would be nice if you would credit it, though.

- You can see some of the graphics features here, under "Engine": http://strlen.com/lobster/ (and new features are being added as needed).

- Yes, there's support for "Dear IMGUI" (see e.g. https://twitter.com/wvo/status/1092948776388485121) and there's also a simple GUI system written entirely in Lobster specifically for game menus/UI and such.

- Speed is still being improved, but in its compile-to-C++ mode it should be a lot closer in performance to C than Python :) It also has a "JIT" mode that goes thru libtcc, but is 3x slower. It's very fast as a game scripting language, but it does not compete with C/C++/Rust as an "engine" language just yet, you are still expected to write the absolutely most performance sensitive functions in C++ (as is the case with a lot of built-in functionality). The language has the potential to compete directly with C++ at some point, but getting there will be a lot of work.

I made this thing, just noticed it was posted.. AMA.

Want to see what happens falls too much in love with DRY? He invents an "automatic refactoring system" that automatically DRY-ifies a whole program: http://strlen.com/restructor/ (not that great an idea in hind-sight, as the page explains).

Interesting to see all the comments here that make it seem obvious that "fanatic DRY" is bad. Historically, there was a wave of OO love where a lot of people went crazy with wrapping every program element in deep layered class hierarchies. DRY (and OAOO, YAGNI etc) was maybe a backlash to that, and some go too far with it. Now we all seem in love with "leave the redundancy in the code", which is another backlash. What's the next backlash? Maybe we'll finally focus on how to balance these factors rather than seeing some extreme as the silver bullet?

Hah, thanks :) Do note, all the work maintaining this project in the last 10+ years is Lee Salzman, not me: http://sauerbraten.org/lee/

It's what I was eating when I designed the original deformable octree structure :)

Maybe the title for articles like this should be "farmland ownership conforms to power law as expected, exponent = K"

Then the discussion can focus on whether is K is surprisingly high or low compared to similar statistics (general land ownership, farm revenue, etc), not endless confused comments that seem to be coming to terms with something being a power law distribution at all.

Here's my trick (maintaining a 15K star github project that gets a lot of issues filed): stay friendly and supportive, but encourage them to create a PR to fix the issue themselves (usually with me giving some hints how to).

It instantly filters out the low effort "I want you to work for me for free" people.

My aim is to turn as people as possible into contributors. You'd be surprised how often, especially with a few hints, go "hmm.. I guess a PR wouldn't be too hard and it be nice to contribute". And quite a few of these end up being repeat contributors, since a second PR is way easier than the first.

It also sends a signal: there's a gazillion things that could be improved about this project. Unless there is a contributor that is willing to make a PR, it is likely not going to happen.

And I spend a larger percentage of my time doing code review, which (as the BDFL) is more effective use of my time anyway.

The current implementation is such that every heap allocated object does have a refc field, but it is simply unused for lifetimes managed at compile time. It would be possible to do further analysis to able to separate out objects which guaranteed never participate in runtime refc updates, and the omit that field. That would be similar to be able to emit to a language like Rust and select an Rc type or not. There are other places where the current algorithm may rely on Lobster specifics (such as closed world compilation and flow-sensitive typing).

Mutation is not protected from having multiple owners/borrowers like in Rust. Lobster does not have shared-memory concurrency (only distributed), nor interior pointers, nor pointers to stack objects (always copied), so its situation is a whole lot simpler. It does "lock" local variables for mutation after borrowing.

I don't think there's any need for anything MMU in what I am doing. Most is compile time. At runtime only the remaining refc ops happen. What did you have in mind?

Hah, I guess there was a paid version of Amiga E that was on those BBS-es :) The free version was limited to emitting 32K executables (which was a lot of code back then).

Not really a "smaller Rust", but certainly a language that does Rust-y things (lifetime analysis) without getting in the users way (it's all automatic) is http://strlen.com/lobster/

It does "compile time reference counting" (http://aardappel.github.io/lobster/memory_management.html) which moves almost all memory management to compile time. The end result is a language which you can program while mostly ignoring ownership, and still get the benefits.

The article also mentions the desire for "control-flow-capturing closures" as in Kotlin, which Lobster has too (non-local returns).

The serialization system he describes is very similar in design to FlatBuffers: https://google.github.io/flatbuffers/

Another statically typed language that "looks like Python": http://strlen.com/lobster/

Except it doesn't have very good refactoring tools. Sometimes you need to change just one small thing about some sub-graph of your factory, but circumstances require you to re-do most of it to implement that change. This is just busy-work, and not "fun", to me at least.

I know later in the game more options open up, but that doesn't help me get there.

I wish for a Factorio-style game where I can just drag (groups of) machines and conveyors around, and I just pay cost for however much just changed.

You'd also need a way to patch the custom (de-)serializer into your "dispatch", which currently there isn't.. as unlike MsgPack, FlexBuffers doesn't actually unpack anything.

So this feature would look like a new function IsCustom1() or AsCustom1() etc, where the latter would give you a pointer to the bytes to do your own thing.. so not much difference with Blobs.

Also note that because FlexBuffers is O(1) access to elements, inline data (most scalars) is all the same size, whereas variable sized data is stored over an offset. So again, would not be very different from blobs.

If you use it for networked communications, by default use the verifier on the C++ side, would be my tip.