HN user

ashkankiani

353 karma
Posts2
Comments105
View on HN
setBigTimeout 2 years ago

You are a bad programmer if you think silently doing the wrong thing is not a bug. The right thing to do with unexpected input as the setTimeout library author is to raise an exception.

I had this exact idea and I've described it to colleagues before. Fun to see parallel evolution. It feels like a simple concept that should already exist, so I'm surprised it's not more commonly attempted. But you're missing a few of the features that I came up with that build on the initial idea. I haven't gotten around to implementing it yet, but it's on my todo list for this year/next year.

I was planning to build it with ultralig.ht, but I'm not 100% sure if it's ready for it. But since most of the content I'm interested in for research is textual/reader mode, and the rest can be viewed with yt-dlp, I think it can render them and it seems the lightest weight. Otherwise it's webkit or servo that I could think of for this.

Good to know there's interest in this.

LLMs make mediocre engineers into slightly less mediocre engineers, and non-engineers into below mediocre engineers. They do nothing above the median. I've tried dozens of times to use them productively.

Outside of very very short isolated template creation for some kind of basic script or poorly translating code from one language to another, they have wasted more time for me than they saved.

The area they seem to help people, including me, the most in is giving me code for something I don't have any familiarity with that seems plausible. If it's an area I've never worked in before, it could maybe be useful. Hence why the less breadth of knowledge in programming you have, the more useful it is. The problem is that you don't understand the code it produces so you have to entirely be reliant on it, and that doesn't work long term.

LLMs are not and will not be ready to replace programmers within the next few years, I guarantee it. I would bet $10k on it.

Love the expanded C API support! Also those performance improvements are massive! Pushing through filters and the streaming optimization for fetchone() is great! This makes it more viable to use duckdb in smaller queries from python.

I'm pretty excited for variables too! I really wanted them for when I'm using the CLI. Same with query/query_table! I appreciate the push for features that make people's lives easier while also still improving performance.

Everyone who I've introduced duckdb to (at work or outside of work) eventually is blown away (some still have lingering SQL stigma)

Make a cap on the value of house. What do people need $100 million stupid ugly houses for anyway. None of these billionaires have good taste anyway.

Adding a way to query the path at the current node would let you skip out on doing stuff like keeping track of `in_section`.

I wonder if the `enter|exit ...` syntax might be too limiting but for a lot of stuff it seems nice and easy to reason about. Easier than tree-sitter's own queries.

I think if you really wanted performance and whatnot, you might end up compiling the queries to another target and just reuse them.

I could see myself writing a lua DSL around compiling these kinds of queries `enter/exit` stanzas or an SQL one too.

It's pretty cool that I can read "anablibg" and know that means "enabling." The brain is pretty neat. I wonder if LLMs would get it too. They probably would.

As someone who stopped getting involved in blockchain "tech" 12 years ago because of the prevalence of scams and bad actors and lack of interesting tech beyond the merkle tree, what's great about it?

FWIW I am genuinely asking. I don't know anything about the current tech. There's something about "zero knowledge proofs" but I don't understand how much of that is used in practice for real blockchain things vs just being research.

As far as I know, the throughput of blockchain transactions at scale is miserably slow and expensive and their usual solution is some kind of side channel that skips the full validation.

Distributed computation on the blockchain isn't really used for anything other than converting between currencies and minting new ones mostly AFAIK as well.

What is the great tech that we got from the blockchain revolution?

I wrote a similar snapshot system for our deterministic trading engine. It's hard to imagine a system that doesn't do that unless you actually enforce every single event in your log to be reversible/non-destructive/non-aliasing. Even then, you still want snapshots to jump to a point in time. The only annoying thing is the case where you want to step back one, meaning a naive implementation would jump back to the last snapshot and play forward.

An 80% solution is to keep the last N states in memory. Snapshots compress well within a small time frame, so whenever we "paused" the playback, we could stash deltas from the pause point to reconstruct stuff (I sadly never got around to implementing this part before I left since it wasn't high enough priority).

I want to apologize. I just lashed out from my past bad experience. You don't really deserve it, and you're right, it could just open up a discussion about writing an alternative for egui. Sorry about that.

How is "Now one for egui, please" not a request? Are you suggesting that was just a wish you're putting out into the universe hoping someone fulfills it? "please" is a word you use as a request, typically. Entitlement w.r.t open source just kills me.

Why we picked AGPL 2 years ago

If the output of your program is an copy of minio then it is also covered by AGPL is what that means. I think it's just covering the case where you are redistributing minio in a way such as decompressing and producing the output.

I still don't think it's that confusing. Unlimited running of it is already covered without exception. The next line only refers to the output of the covered work.

If the output of your web server is redistributing minio then you are under AGPL

Eyechat 2 years ago

It has to capture everything first to figure out where the eyes are...

I don't love the game of "someone posted a random article with some numbers that they found from a 5 minute Google search, but now I have to do the much harder & longer work of verifying if it's legitimate or misleading"

The point was that for cases where Unreal 5 isn't suitable for your needs, what's the best alternative:

- Using Unity and potentially all the baggage that comes with it

- Making your own engine

Therefore the crux of the argument was to prove that making your engine wasn't as complicated as people are making it out to be.

From my perspective, the question he posed in the tweet is a valid consideration. What actually is the value added by using Unity beyond the initial section of having your engine bootstrapped?

I sure wouldn't have my own engine spun up that fast

I'm thinking I should do as Casey has done before and put my money where my mouth is and show how long it takes me to make a 2D game engine in that same amount of time just by following HMH, but also with the ability to use existing libraries. I bet it'll be less than a week. And fwiw, I'm a software engineer at a high frequency trading firm with 12 years of self taught experience. I'm not a game developer, just an amateur who learned some things on the side. If I end up doing this, I'll reply to this comment with a link to the VODs.

And let's not forget, his target in the tweet was game developers. If they can't make a 2D game engine in 2 weeks (to be extra generous) full time work with their experience and literally just following HMH as a guide, then that's kind of surprising.

Roughly 600 episodes translates to roughly 600 work hours. That's 15 weeks. And now it's a full 3D game engine. Because he's not doing it contiguously and instead doing it once a week or so (there are breaks sometimes), it's continued over many years. So by episode 40, he's done about 1 normal work-weeks worth of work (and in truth, constantly starting and stopping affects the productivity, as does doing it live and explaining yourself. Imagine your productivity hit while doing pair programming, basically).

In that time, he's already got a hot reloading 2D engine https://www.youtube.com/watch?v=YBCOijN2fNA . And he's not exactly implementing it for speed of getting something done, but for educational purposes, by doing things like explicitly not using libraries, implementing PNG decompression, math functions, and doing software rendering first, and then switching to hardware acceleration even though he knew he would eventually do hardware acceleration anyway.

His point stands up completely. You can follow handmade hero and have your own 2D game engine up and running in roughly 1 week's time.

Furthermore, it's pretty disgusting to call an educational project that's had hundreds of hours poured into it "spending a billion years writing his game engine, and then whining about all these 'bloated' tools." Do you know how many people his educational videos have helped? The amount of patience and dedication it takes to answer all of these beginner questions and explain things way below his level of experience in terms of difficulty qualifies him for sainthood in my opinion.

sway and wlroots have some of the worst error handling I've ever seen in C code. The number of null pointer bugs and assertion bugs is just mind-boggling. I don't really understand how hard it is to just gracefully handle errors. Literally no one would prefer to crash their entire desktop environment rather than have it silently skip over errors and output them to a log.

I recently used i3 again because my office computer has an NVIDIA GPU and sway doesn't support NVIDIA (yes I'm aware of the new GBM API, it's not ready yet and I don't care anymore anyway). It made me realize how much more gracefully i3 handles a lot of things, and also a few things it really doesn't (but that's more the fault of X11, not i3).

It's disappointing that the defacto library for Wayland is wlroots given those bugs.

The author is now a new favorite person of mine. I've been working on my own language, and I have an incredible overlap with the features that Wuff has, specifically the coroutines, refinement types, the "facts" (which I had been inspired to implement from ATS with its proof threading), the io_buffer slice type, and the effects system. It's kind of shocking how much stuff there is on overlap, but it does give a good indication to me that this is a "good idea."

I'm especially pleased with his approach to practicality re: compile times.

I'm also glad it's Apache2 licensed because I'm going to be reading through its source for inspiration at a future point for reference for my own implementations.

I also see a strong likelihood that I will use it extensively for a few projects I had been working on in embedded for the ESP32 on my mobile device prototype and for non-embedded projects with my PL and otherwise (like for my Neovim UI frontend). I'm so glad this was posted.