jaredly

Giving a real-world complex ambiguous scenario to 14 different Agent LLMs

So the "repo" in this case is a database, where currently the only things stored are denormalized source tree nodes. I could imagine extending the database to support arbitrary assets, probably also addressed by the hash of their contents (same as top-level language definitions are).

Oh hi kevin! So if there's a possibility that the "extra data" would get out of sync with the "source code" (e.g. via a git merge, or someone just editing the source code as plain text), then it unfortunately breaks the guarantees that this system needs :( I guess I could store a sha of each and fail loudly if I detect that one was edited "outside of the IDE" but again I think that would break the assumptions that git makes about diffs &c. I've tried to go down the "text but nicer" route before, and it always comes up short; so now I'm trying "text is not a supported representation" we'll see how far I get.

Hm so it is a state machine, but (my hope is that) all state transitions are simple and direct (and observable!) outcomes of user action. If the transitions get at all complex or unobservable, I'll probably call it a failed experiment.

It might also end up being the case that users keep types "visible" at all times, only turning them off in certain situations. I can also imagine a flag to "only hide inferred types that are primitives" or something similar.

So I think "easy to mentally model" gets harder and harder to achieve as the type system becomes more powerful. If your conclusion is that we keep the type system limited in power, that's valid! but not what I'm exploring.

Another point that I failed to make in the post (thanks for the pushback!) is that type inference algorithms leave you high & dry in the presence of a type error. Then you're left with lots of hidden state (the internal steps the algorithm took before arriving at the error) and the final conclusion, which, if you're lucky, points you to two places in the code where the inferred types are in disagreement.

With my proposed system, all types are annotated all the time (to be shown or hidden via editor flag, or on hover), and the annotations are updated in response to actions taken within the editor. The "algorithm" becomes extremely simple, with almost no intermediate steps.

Of course, proof will be in the pudding, if I can actually achieve a pleasant editing experience :)

Yeah, it is definitely nice to have inferred types surfaced to you, but in these systems they are still re-computed on every textual edit, as opposed to being "sticky" (persisted in the source tree).

Source control does look very different in a projectional language, as git diffs no longer make much sense (viewing a pull-request with the source tree's JSON blob is essentially useless).

Unison is the language that's gone farthest with this, as far as I know; their solution to diffs & merges is to handle everything from within their CLI, bypassing git entirely. I imagine I'll do something similar.

Convergent evolution :) I made the version version of Gravitron in 2006

I haven't optimized it for mobile browsers, but it wouldn't be hard. Was pretty heads down on getting mobile native out the door.

In the game, the only place I check the platform is to see how big I should make the screen (like 3 lines). Everything else is shared! The big news here is that you can use a single codebase (and a nice advanced language like ocaml), and deploy to 4 platforms. The framework I'm using is called "reprocessing", which is a ~port of the "processing" language to OCaml, targetting OpenGL. It abstracts out the different platforms.

much more readable transpiled output, really nice (and getting nicer) FFI to javascript. but it doesn't interface with existing ocaml stuff as well (doesn't use `.cmo/.cma` so it needs to compile everything from source afaict)

lots to look into, thanks!

looks neat!

right. should have "(by convention)" in there. unfortunately not (yet) language enforced.

1) I see om/next attacking the same problems as falcor and relay, and david nolen makes reference to both of them (as sources of inspiration) in the talks he's given.

2) it may only hurt once a day/week once you have an established flow going, but when trying to figure things out & start things up, you restart a lot more than that. hence the barrier to entry

I just listened to this podcast[0], and there's a really great discussion in there about when it's nice to have types, and when it's more trouble than it's really worth.

That's why javascript's flow[1] appeals to me so much, and I'm really interested in core.typed.

[0] http://giantrobots.fm/172 [1] http://flowtype.org

I was going to have a section on Elm, and then the post got too long :) Clojure(script) feels much more mature, and general-purpose. Elm is client-only, not nearly as many libraries, etc.

Would clojure's readability be helped by having a non-lisp pretty-printer? I've been thinking about this a bit - s-exps are great for writing, but fails to take advantage of our advanced visual pattern matching when reading it.

Awesome! Thanks, I've been looking around for good projects to check out and hack on.

thanks! Yeah, I'm really excited about clojurescript, but there is a big barrier to get over. I'm working on it, and hope to report back :)

alt-l opens, alt-h closes currently. h takes you to the parent of the current node.

Hmm, I hadn't thought of removing the node if you never typed anything. Good idea.

=) that's coming.

I can imagine client-side routing, sane data management, and intelligent code base organization all without mutating the data of your state. Granted, JS won't move to immutable data structures, but React encourages you to treat your states as immutable, which leads to lots of benefits.

maybe "details" is the wrong way to phrase it. I'm excited to see /a real world implementation/, either proving that it really is that simple, or showing what other complications arise.

the difference here is that there's no "fake-world" contest. Tarsnap is asking for a real-world hack of their system.

Telegram, on the other hand, is trying to prove that their algorithm is unbreakable. AES is pretty good too. As is noted in other comments, it's generally the system, not the algorithm, that gets broken.

You're definitely not "too late" to make the switch, as long as you're ok with staying in school a few more years. I would say definitely jump over to CS, get to know some professors and their research interests. College can be invaluable for making those connections and experiencing cutting-edge research. source: I'm currently a cs undergrad doing some awesome machine learning research :)