jeapostrophe

I agree that it is very exhausting

Yea, I think it will be totally useless to switch at that level and instead it will be about reviewing the work more effectively. I think I would believe in the more "autonomous Claude" systems in that world.

I agree. This is what has worked for the past few weeks and I want to share. Maybe I will regret my life choices. If I'm still doing it next year, that will be something different to say. But I want to try to help and share before I really know. <3

Ask Claude ;) Right now it is hard-coded to run `claude --resume <uuid>` but there's a natural abstraction to use a different script to start the Claude session.

If you're being sarcastic, I love you anyways.

Whether multi-tasking is good or bad, I think that if you're "waiting for Claude" at all, you're going to be multi-tasking or staring into space. I try to stare into space when I'm pumping gas, but I don't want to do that when I'm "working" at my laptop... in part because I know I'd be more likely to check my email or HN.

LOTs of key bindings.

Amen. Making the checking painless and easy to do is a major boon. There's a spectrum of "checking is easy": the compiler telling you the code doesn't compile is the easiest, but doesn't capture "is this the program I want". Some checks like that are inherently not mechanically checkable and some sort of written "testing protocol" is necessary.

My personal experience matches this. When I'm "succeeding", I am at the 5-to-7 minute cycle time and when I (or Claude) are failing, there's constant attention and no ability to switch away.

My human programming experience is encouraging me to keep going on the debugging, like I did when it was my code that I invested a lot of time and energy into.

Now that the code is cheap, I am trying to "learn" to throw away everything, go back to a stable checkpoint, and try a different approach that is more likely to succeed. (Probably having the new plan incorporate the insights I gained the first round.)

It is hard to do that when you coded for a week (or even a weekend) but it should be much easier when you got it faster with Claude. I think people (me at least) need to learn new norms.

I've gone through a bunch of different processes learning how to use Claude.

Giving it large tasks that take 40 minutes basically always fails for me. Giving it small tasks that take 30s to a minute feels like it is my typist and not a worker. I find that I am happiest and most effective at the 5 to 7 minute cycle timeframe.

I disagree. My workflow is built around reviewing what it produces and trying to build a process where it is effective to do that. I definitely can't and don't watch edits as they go by because it is too fast, but I want to easily review every line of code. If you're not "reviewing afterwards", then when would you be reviewing?

As far as planning the next steps, that's definitely a valuable thing and often times I find myself spending many cycles working on a plan and then executing it, reviewing code as I go. I tend to have a plan-cycle and a code-cycle going on at the same time in different projects. They are reactive/reviewing in different ways.

My tool supports doing many, but I find it hard to use it for much more than 3 or 4 concurrent projects. I've tried more than that open and I fail. I find that 3 project with 2 or 3 concurrent tasks at the same time works best for me. But I think I'm learning.

Extra CSS can be added when running Scribble:

http://docs.racket-lang.org/scribble/config-style.html?q=css

The request-post-data/raw function is in the docs: http://docs.racket-lang.org/web-server/http.html?q=post-data...

The issues you mention are all alleviated by the stateless continuations which do not store state on the server and allow various ways of closing off the session from simply having the URL.

The documentation discusses the features of the Web framework, many of which have to do with its unique aspects. As you can see in this post, all normal Web programming is possible and easy, but there's very little special to say about it, because it's just a normal program.

Let's put that on a bumper sticker :)

Certainly, but most math proofs aren't "rigorous proofs" by any stretch.

Syntactic validity is not a property of a program, but a property of a piece of text that makes it a program. In any case, the point is that type systems purport to identify some amount of "goodness" in a program. I agree that "The compiler will produce something" is a property, although I doubt it is a property any static type proponent would defend as particularly important.

If you really believe this, you should try to translate any contemporary (published) mathematical proof into a real logic, like Coq. It is hard and people earn PhDs doing this because most proofs are so intuition heavy in the first place.

We should not throw out mathematics, but we should recognize that most mathematical proofs are not based on logic, but human intuition in the first place. Human intuition and wisdom are valuable and lay the foundation for all that we do and there's no reason to ignore them when we're programming and insist that all valid programs have to follow some particular set of rules.

I suggest reading about progressive types:

http://blog.brownplt.org/2012/09/01/progressive-types.html

That's not a counter-example. I'm not saying that Java doesn't allow syntax that might look like "number + string", just that it does not actually add them, like C does where: 3 + "4" means something very surprising.

It's true. The theorems are a statement about the logics. Most of the time when you design a logic, you get to "choose" which case you'll get. Most people choose "true but not provable" because that's a little useful. It would be very bad to choose "provable but not true", because then you could never trust any conclusions of the proof system. - the author

This is Jay. Arc macros are like define-syntax-rule macros in Racket. dsr is great for lots of things, but sometimes you need more power.

In any case, this post is really about what's going on in the pattern matching and macro template underbelly, and not really a recommendation for how to program macros.

As a Racket author, I can tell you that we provided them with a hack to enable mutation on arbitrary conses, so they can upgrade whenever they wish, and I don't know whether they have or not.

This is the author.

I agree very much with both of you. I assemble all the tiles into texture atlases (and earlier post discusses the technique) and then use a fairly simple shader to render. If you look in the gb/graphics directory [1], then you can see the GLSL code. It was originally coded for OpenGL 3.3 with geometry shaders but I switched to OpenGL 3.00 as a stepping stone to ES 2.

The whole model is based on the concept of "SNES Unbound": I want to have effectively infinite numbers of sprites with many layers and any Mode 7 effects with arbitrary scaling and rotations. This is a very small level of expectation of a modern GPU, so I can get about 1,000 FPS on my laptop with millions of sprites, because I only use a single OpenGL draw call per layer.

Anyways, I'd be happy to comment or chat more with you. Maybe I should post some screenshots of the editor.

Jay

1. https://github.com/get-bonus/get-bonus/tree/master/gb/graphi...