nvlled

You are referring to this comment right? https://news.ycombinator.com/item?id=49938732

> that I had every LLM check it to confirm it's a bug

I'm primarily objecting the way he phrased it, as opposed to just saying "I've tested and confirmed and reproduced the bugs". Instead, it sounds uncertain and detached, like he asked the LLMs if it's indeed a bug without further verification.

Note the distinction:

- using the LLM to find (possible) bugs and a human confirms it by testing, reviewing, etc.

- using the LLM to find and confirm the bug without the human confirming it

Nice to see a fellow ebook hoarder here. I always get that magpie impulse to download any book that looks or sounds interesting, even though I may never read them.

Here's mine: https://gist.github.com/nvlled/45b60884523cb48029686c50d0719...

It ended up kind of weird, but it was fun writing it. The organizer should suggest what programs to use for word counting, since different programs slightly give different counts. I used vim to write but used google docs to check word count and spellings.

  Location: SE Asia
  Remote: Yes, preferably
  Willing to relocate: Depends
  Technologies: C#, Golang, Typescript/Javascript, PHP, Python, Zig, Git, SQL
  Résumé/CV: On request
  Email: nwnoiiFnujsw:p}|  (hint: shift the ASCII char by its negated index)

I'm primarily looking for contract work (short-term or long-term) for any brown field projects that needs general maintenance work such as refactoring, optimizing, fixing or identifying a root cause of a bug or vulnerability. I can fill the niche areas where LLMs are prohibited, have failed or would otherwise do it terribly/expensively.

In addition to the technologies listed above, I can also work with any unfamiliar, obscure or poorly documented codebase/tech-stack, provided the time to study or train is accounted for and is part of the compensation.

Not to ruin the joke, but he knows and can remember the student's face so I don't think that student can get away with it.

Huh, that's strange, where did all comments to this post go? I remember seeing three, then a few more the day after. Were they bots? They seemed legit recommendations, like the Pricing Money book.

Dungeon Meshi is a good well-rounded recommendation even for those who aren't particularly into anime. I'd personally add to that list:

- Clevatess

- Kusuriya no Hitorigoto

- Tongari Boushi no Atelier

- Sousou no Frieren

- Yuusha-kei ni Shosu

- Shoushimin Series

- Chi. Chikyuu no Undou ni Tsuite

With my recommendation criteria being: good (or decent budget) art/animation, good story and characters, and nothing too "weird" in it for the general population.

Off-topic rant for dandadan:

One of the main character Takakura is initially portrayed as being obsessed with aliens and UFOs, to the point it affects his social life. But the morning after their actual encounter with paranormal, the dude literally can't think about anything but pussy. I couldn't get past what a grifting poseur the protagonist was and I dropped the anime after that. Petty reason, but I'll probably change my mind and retry again in the future. Or not.

> I never said s-expressions have no downsides

You didn't say it directly, but it's implied from what all you said in this thread, just as no one in this thread said "outright unreadable". Up until now, there's no acknowledgement of the downsides and you refuse to even understand the dissenting point of view. If you truly do acknowledge the downsides, you would (try to) understand why people "hate" it. But no, "people are too incoherent to not like the beautiful perfection of s-expressions" as the lines in between would say.

This is your comment but with "zero syntax":

  I just don't like them

  That is what I dont get I have used many different languages. and often is not the syntax that I dont like . I may dislike the semantics. the runtime. the tooling. but syntax. really how. It.s like. I hate Greek alphabet. even though this is a weird comparison . alphabet is a flat bag of arbitrary symbols with no structural role. so disliking it sounds incoherent by construction. I just cant ever get over .sexpressions hate. in such a way like. What are you even talking about. Theres practically zero syntax in Lisp.

I can only think of the word disingenuous when I can see someone outright refusing the possible downsides of s-expressions (you probably meant zero syntax since it's still possible to have syntatic s-expressions.).

I would say, with a striped-shirt and not a glove in my hand, that the person you were fighting with gets the score, and wins by technicality. I suggest you take the bench first and review your comments and reflect with a wet towel on your head.

> Right, it's exactly like C, and we kinda all know how that worked out in practice already...

Production operating systems have been written in C, along the with the countless tooling, libraries and game engines (which you said are a poor fit for manual memory management) that modern systems depend on. I say it worked out it pretty well.

And zig did learn from the hard lessons from the industry and fixes a lot of problems with C. It also has a lot of affordances that makes it more than suitable for general purpose use.

> Arenas are not good for that because the arena as a whole has to outlive all of those poorly defined scopes & lifetimes, which is hard to do.

I don't what else to tell you, arenas outliving temporary allocations is exactly what it is made for, they go poof as soon as the arena owner is done. That's not hard, it makes it easier if anything. To give concrete examples, arenas are used on HTTP requests that are clean up in one go as soon as the request is done. They are also used on (possibly deep) recursive functions that are cleaned up as soon as the root function returns. Of course, you don't store arena-allocated memory elsewhere that outlives the arena, that would be dumb.

That's why you have to be consciously aware of the ownership and lifetimes that a piece of memory has. Ownership and lifetimes are just one part of the API contract of a function or module. You break it, that's on you. Having a compiler help with ownership model would be nice, but it's a not substitute for having a good mental model of your programs. It's not that different from the tradeoff of a having a less strict type system. Not every sanity check can or has to be performed at compile time. Zig also has debug allocators that catches a lot of memory mismanagement during testing. Hard to debug double-frees, use-after-frees and other things are a symptom of poor cavalier YOLO programming.

That all said, I do agree that manual memory management is really hard to do if you are used to just sweeping gigabytes of memory under rug, hoping the GC vacuum cleaner slurps it afterwards. It takes a mindset and a set of practice. But once you internalized it, it becomes second nature.

(Not to sound like a zig fanboy, I do think it's still rough around the edge and there are a lot of things I don't like. But manual memory management is not that big of a problem).

I disagree with a lot of what you said, but I don't feel authorative enough to say you're wrong.

> Which is really not that many places, it's a fast but rather niche optimization. There's not a whole lot of scenarios where lots of temporary memory is needed for one well defined scope.

Arena allocators are not niche optimizations, or not something picked first for optimization. Contrary to what you said, arenas are useful for temporary allocations with poorly defined intermediate scope or lifetime (think functions directly or indirectly called by the arena owner). If the scope is local and well-defined, a regular allocator or even a fixed buffer would do just fine.

> Zig's lack of ownership

Zig doesn't have explicit annotations for it, but the concept of ownership and lifetime doesn't go away. It's not enforced by the compiler, which is an intentional tradeoff to let the programmer have more control and freedom. When you use languages with manual memory management, it's expected that you are capable of designing sensible programs in such a way that ownership and lifetimes are tractable and are part of the program design, rather than something to workaround to please the compiler.

Ever heard of tribalism and echo chambers? Wrongness being a function of number of dissidents is a terrible heuristic, in contrast to determining the lies and falsehood based on the soundness of the argument or logic.

Also, when a population group is large enough (e.g. entire world), it's quite likely a crazily-held belief is shared by other people, or people who would at least nod in agreement.

The article you linked goes to great lengths about Orwell's alleged scotophobia. I don't see how particularly hating scotts supports "intentially treating those cultures as identical". If that was true, then Orwell would equally hate all scots and englishmen.

Also, what's the downside of treating different cultures identical, aside from potentially offending people? As opposed to other kind of racism, where other people are treated as lesser subhumans that ultimately led to slavery. Why are both casually referred to racism when the other has more far-reaching consequences.

> half sarcasm, half real-talk.

If you could pause a bit from being awed by your own perceived insightfulness, you would think a just bit harder and realize that LLMs can generate hundreds of thousands of code that no human could every verify within a finite amount of time. Human-written software is human verifiable, AI-assisted human-written software is still human verifiable to some extent, but purely AI-written software can no longer be verified by humans.

So that's name of that game, I've been trying to remember that game I played briefly as a kid, which in my hazy memory seemed quite fun. Thanks, will give it a try when it goes on sale.

Just the visualizer:

> Also note that the python visualizer tool has been basically written by vibe-coding.

Also that readme is still fairly technical, no any kind of advocacy or heavy pro-AI sentiments of any kind.

I've seen that before. Re-reading it, I don't really get the same "vibe" as antirez's level of AI advocacy. You also conveniently omitted the last paragraph of the tweet:

> Will there be more or less game developer jobs? That is an open question. It could go the way of farming, where labor saving technology allow a tiny fraction of the previous workforce to satisfy everyone, or it could be like social media, where creative entrepreneurship has flourished at many different scales. Regardless, “don’t use power tools because they take people’s jobs” is not a winning strategy.

But yeah, it (almost) sounds like an ad for AI, but I like to believe it's still a measured somewhat neutral stance. The difference is that Carmack doesn't consistently post things like this unprompted, unlike antirez.

I don't see Carmack or Torvalds doing this, so it's all good (for now).

Why? I'm so confused why would you expect a build tool to depend on a x11 client library, besides the fact that both starts with the letter x. Does it also upset you that xamarin and xaml has nothing to do with xlib, xmake, or to each other?

Lua supports even functions and objects as keys:

  function f1() end
  function f2() end
  local m1 = {}
  local m2 = {}
  local obj = {
      [f1] = 1,
      [f2] = 2,
      [m1] = 3,
      [m2] = 4,
  }
  print(obj[f1], obj[f2], obj[m1], obj[m2], obj[{}])

Functions as keys is handy when implementing a quick pub/sub.

A side thought, how would a natural number sequence of hypotenuses that satisfies the equation a^2 + b^2 = c^2 look like? Or what interesting properties would it have if any.

The difference is in the ownership and lifetime of the state used by the function. A pure function uses state that it owns or is not outlived by the mutable state it uses. Closures on the other hand uses that it doesn't own or is outlived by the state during the invocation.

The important detail here is that closures automatically moves the variable that lives in the stack frame into the heap. You can't do that with a regular function. In languages with manual memory management like C, if you try to store and use a pointer to a invalidated stack frame, you will either get a crash if you are lucky, or get a crazy bug that shouldn't happen within reason.

Your supporting and concluding statements are directed at a scarecrow though. The person you are replying to isn't contending that closures and objects are different, they are specifically saying that closures and (regular) functions has an important distinction, which I agree.

Although I would say the person you are replying to did have poor imprecise wording on their part.

> https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm...

It should be noted that most of those issues are created by opening a link that bun creates when it crashes, they are not yet reviewed/confirmed and most likely a lot of them are dulplicates of the same issue.

Kind of uneconomical that they have different designs for left-hand and right-hand. They could have just placed the trackball or a nipple in the middle of the keys, and mouse function keys on any side. The hand still need to move and travel anyway with the current design to reach for the mouse keys.

But you were originally talking about exceptions. As I said, destructors and exceptions are distinct concepts, you can't just suddenly interchange those two terms as that would invalidate my whole disagreement, unless you wanted to shift the goal posts a bit to the side.

> But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block

Why bring up destructors, I was talking about exceptions. Destructors and exceptions are orthogonal concepts, one can be implemented independently of the other. I'm specifically referring to try-catch blocks like those in java.

Compare this:

  try { foo(); }
  catch { bar(); } 

to this:

  defer bar();
  foo();

In the first one, bar() may or may not run depending if there's an exception. In the second one, bar is guaranteed to run. Thus, it means defer does not conditionally interrupt the flow of execution.

> The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function.

What? You don't need to read the entire function, you only to scan or check for defers scoped in a block, or in some cases, just the top of a function or block. Wanting to just read the end of a function is unreliable anyway with the existence of early returns (which defer fixes by the way).

You could have made a more compelling (but not necessarily a valid) case by citing zig's try-catch, which makes me think that you are just arguing in abstract without actually having tried writing code that uses defer, or any zig code for that matter.

It's not the same, defer does not conditionally interrupt the flow of execution, it will always run at the end of a block. If I see a defer, I am absolutely certain that whatever is deferred will run. The same is not true for exceptions. If I am not mistaken defer just moves the code at the end of the block, no jumping is involved.

Kotlin uses var/val too[0] which is what Java is trying to copy. I have never written any kotlin code before, so I don't know if this would be a problem in practice. On the plus side, var and val both have the same length, so the variable declaractions are properly aligned. The names are also intuitive as far as I can tell.In theory, I'd probably be okay with it.

[0] https://kotlinlang.org/docs/basic-syntax.html#variables