Comments URL: https://news.ycombinator.com/item?id=47952758

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47719755

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47547951

Points: 5

# Comments: 1

I think we are in a similar situation with code generation now, then only difference in my mind is that LLMs come with a massive platform risk. Who's to say that one day anthropic decides my company is too much of a competitor to use their tool (like they've already done with openai) or what if they decide that instead of pulling their product from my use they just make it generate worse code, or even insert malicious payloads. A dependence on these tools is wildly more risky than dependency on a word processor or a spreadsheet program. It reminds me of the arguments around net neutrality and I cannot fathom how people building on top of, and with, these tools do not see the mountain of risks around them.

Here's how I think of it: If I were a painter, I would paint, explore and experiment in my free time because its what I want to do. Maybe, as a painter, my vision is to improve the state of the art of some kind of dye or brush or canvas and that is my vision. But! That does not mean that I cannot be commissioned to work on a mural or put on a retainer for a museum or something else. The only difference is that in the latter you are being explicitly payed by a patron to produce something they want. And furthermore I need that work, I work for myself but still need projects to bring in money to do the work I care about.

I view my software dev as the same thing. I have a vision of where I want to be, what I want to do, and how I want to contribute to advance the state of the art of the things I care about. I do not care, and am unconcerned about the corporate needs of the thing I care about, its for me and for people like me. My $JOB is just one part of that larger goal and the path I walk towards that goal. Its an important part, sure, and I show up and give a good faith effort and my expert opinion, but its not the part that enriches me as much as my personal stuff. The distinction is that the $JOB is not separate, its a necessary and important part of my plan to execute on my vision.

Once you have vision I think you'll find its much easier to find similar people who want to work on the same things you want to work on. And I think you'll find it much easier to tolerate capitalist minutiae because you will reduce the things you need from $JOB.

I see how the use of AI is useful, but I feel that the practitioners of AI-as-coding-agent are running away from the real work. How can you tell me about the system you say you have created if you don't have the patience to make it or think about it deeply in the first place?

For example, I would create a game fight scenario where the player has infinite health and the enemy just attacks super fast at some settable rate. That way you could monitor whats happening in extreme abnormal conditions with the hypothesis that if the game works in extreme conditions then it will work in normal conditions.

Another example. If you have random encounters like in old school JRPGs then I would create a scenario where a fight happens per step of the player, the fight loads, then the enemy immediately dies, rinse wash and repeat. That should allow you to asses how the game performs after 100s of fights quickly.

The idea here is to create tests that improve your signal to noise ratio. So you create a scenario that will create a large signal so that then you can more easily diagnose the performance issues.

  fibonacci :: (MonadLogger m, MonadState (Int, Int, Int) m) => m Int
  fibonacci ...

  class (MonadLogger m, MonadState s m) => MyMonads s m

  fibonacci :: MyMonads (Int, Int, Int) m => m Int
  fibonacci ...

So I would argue that the real message of that chapter is demonstrating, step-by-step the methods used to find the memory leaks: info-table profiling and biographical/retainer profiling and ticky-ticky profiling.

But that doesn't mean that laziness doesn't come up! For example, its impossible to demonstrate using (or defining) unboxed or unlifted types without discussing laziness. The same goes for using GHC.Exts and explaining the difference between Data.Map and Data.Map.Strict.

My goal is to have a handbook that consolidates and demystifies optimizing GHC Haskell because I think this resource is sorely missing in the Haskell community. So that includes reading and understanding Core, Stg, and Cmm as well as understanding the tools that already exist for GHC Haskell but are under documented in addition to the real advanced features, like altering the RunTimeRep your data types to control their behavior at runtime. Needless to say there is a lot to do :)

Comments URL: https://news.ycombinator.com/item?id=33984080

Points: 12

# Comments: 0