HackerLangs
TopNewTrendsCommentsPastAskShowJobs

jaen

310 karmajoined 16 ปีที่แล้ว

comments

jaen
·3 วันที่ผ่านมา·discuss
Misleading article. Probably partially AI written? Presents nonsense such as eg. the diamond inheritance example as valid-seeming argumentation.

Quite a few points are plain wrong and outdated and under-researched, eg. Python has uv, ruff and Pyrefly, and with that combination, has roughly the same agent ergonomics as Go and lower token count due to higher abstraction level.
jaen
·10 วันที่ผ่านมา·discuss
What's the advantage of this over Jotai / atomic state / computed signals, which seems to require 10× less code with mostly the same benefits?
jaen
·16 วันที่ผ่านมา·discuss
Ugh, please don't read strawmen into other's arguments and try to follow the HN guidelines.

Also, how about making proper arguments yourself? The vast majority of the training data isn't generated by company-paid AI experts either.

Notably, books, even though they don't form a large part of the training data, significantly improve performance on some tasks (same way as expert-generated data).

Why do you think the AI labs are so eager about scanning (and then destroying) every book on the planet?

If you removed all copyrighted works from the training corpus, the model would be notably weaker.
jaen
·16 วันที่ผ่านมา·discuss
Indeed, that's exactly why I replied - you omitted one side from the discussion.
jaen
·16 วันที่ผ่านมา·discuss
...and the rest of the training data (ie. the entire corpus of copyrighted works) was not written by experts expecting compensation? Double standards.
jaen
·19 วันที่ผ่านมา·discuss
Ideally, yes. Depends on the context. Same way you don't use unit algebra when doing trivial everyday math. At some level of complexity, it becomes worthwhile.
jaen
·19 วันที่ผ่านมา·discuss
Unfortunately currently only supported by Chrome/Chromium:

https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
jaen
·20 วันที่ผ่านมา·discuss
This is like a type theory question - do you like it untyped or typed?

In physics, values have units too. Analogously, you could say - why incorporate units into the algebra in physics (as is often done)? Why not just add scalars etc. and not bother carrying around the units everywhere?

Well, because doing anything else is mostly nonsensical - it does not make sense to add meters and seconds together. Using unit algebra is the most basic sanity check as to whether your formula makes any sense.

Sometimes it makes sense to convert/cast between representations, but that should be explicit - distinguishing eg. objects and operations is more readable and more safe, and only comes with a bit of notational overhead. Nothing is free, but I think the benefits far outweigh the downsides.
jaen
·22 วันที่ผ่านมา·discuss
Could you actually explain/exemplify any of the gotchas and what's been made better (or is this just handwaving)?
jaen
·22 วันที่ผ่านมา·discuss
> -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure).

How do you expect this to work then? If the provider is bad, blaming LINQ for it makes no sense...

You either have a high level of abstraction and possible performance pitfalls - or a low level of abstraction, and also performance pitfalls since the code is less modular, more coupled and harder to read.

LINQ can in many cases improve performance significantly in large applications when used properly, since it avoids N+1 query problems due to implementation hiding/modularity, and allows composing parts of queries across different vertical subsystems of the application (vs. each subsystem doing its own query and then joining them with more boilerplate).

Nothing in Java compares to this. jOOQ and Hibernate (and the rest in the ORM ecosystem) are pale shadows, exactly due to lacking language features (such as reified expression trees), and even then, they only work with databases.
jaen
·29 วันที่ผ่านมา·discuss
I think this is a good example of complex lifetimes involving reference cycles that can not be safely modeled by eg. Rust.

Is the next step formal methods (theorem proving) or is there a less complex lifetime system still out there that could model this?
jaen
·เดือนที่แล้ว·discuss
You can generally configure the power button to require a 5s press or to suspend the computer in the motherboard's firmware UI (UEFI/BIOS).
jaen
·เดือนที่แล้ว·discuss
Changelog: https://webassembly.github.io/spec/core/appendix/changes.htm...
jaen
·เดือนที่แล้ว·discuss
Changing orientation affects which parts of the display processor are used. In general, the low power states on GPUs are very capricious.

eg. from personal experience, on older Nvidia cards (1080 Ti), just adding +1Hz to the refresh rate (or using a slightly higher resolution, or 10-bit color, or no DSC etc. etc.) caused it to never enter low power mode, changing power consumption permanently from 10W -> 50W.

AMD GPUs on even the most modern Linux kernels don't enter low power states properly. If you do change the power profile to do it more often, browsers become a laggy mess.
jaen
·เดือนที่แล้ว·discuss
The game originally used a "voxel" engine [1], but the final release switched to affine texture mapping (with a heightmap-based terrain, still).

The voxel-style engines tend to feature a longer draw distance (due to it being cheaper to render, as you can easily use various hacks to eg. halve texture accesses far away).

For a detailed look into the rendering of Magic Carpet, start from Slide 8 of [2].

[1]: https://tcrf.net/Prerelease:Magic_Carpet_(DOS)#1993 [2]: https://web.archive.org/web/20180330004301/http://www.glennc...
jaen
·เดือนที่แล้ว·discuss
There's still speculation though - if eg. most values are of 1 or 2-byte length, you can speculate that any control-valued byte is actually control. You can even do a compensation pass to try to fix some amount of mis-speculations, and then bomb out if that fails.

With that, it's mostly byte-parallel (though data-dependent as I mentioned).
jaen
·เดือนที่แล้ว·discuss
Right, I think we have a slightly different definition of SIMD: You mean byte-parallel, I mean "doable with SIMD instructions". I also didn't imply the performance would be better than other methods...

Even though decoding the lengths must be serial (since's there's no unambiguous way to differentiate a tag and data byte), it's still doable within the wider SIMD registers, so there's some theoretical efficiency gain to be had (depending on the shape of the data).

On a general note, the continuation bit and prefix byte forms are equivalent, you just broadcast the prefix byte and compare against an increasing vector to convert it to a mask. Yeah, there's probably more fiddly SIMD if there are multiple prefixes in the register, but doable (it's just not byte-parallel, you eg. unroll the serial decode loop 8 times or whatever your maximum output byte width is, and mask out).

Simplified:

  // Just maps a byte to its position in the register
  __m128i idx = _mm_setr_epi8(0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15);
  // Broadcast the prefix
  __m128i nn = _mm_set1_epi8((char)prefix_byte);
  // Get applicable locations: prefix_byte contains the length, if byte_pos < len, the corresponding byte will be set
  __m128i m = _mm_cmpgt_epi8(nn, idx);
  // If you *really* want a high-bit mask:
  m = _mm_and_si128(m, _mm_set1_epi8((char)0x80));
jaen
·เดือนที่แล้ว·discuss
This doesn't seem particularly hard to SIMD, especially when the CPU architecture has "compress/expand" horizontal instructions. The first byte fully encodes the length, which is not harder than the continuation bits of (U)LEB128. It's a basically a common length-prefixed encoding with an extra subtract added in, so someone has probably figured out an efficient algorithm.

It might be slightly more instructions than some other serial VL (variable-length) integer codec choices, but overall I don't think it's more difficult.

The very efficient SIMD VL codecs tend to stripe (separate) the control and data bits, so they're in a different design space anyway.
jaen
·เดือนที่แล้ว·discuss
I think it should be possible to do P2P / relay-less communication using WebRTC? eg. https://github.com/jchorl/sendfiles

Hopefully P2P WebTransport takes off soon... https://w3c.github.io/p2p-webtransport/
jaen
·เดือนที่แล้ว·discuss
Your intuition is not right, I have plenty of experience with REPL-driven development, even having used all the tools you have mentioned in your post. (and Clojure Spec is exactly the runtime specification part I was referring to in my comment...)

Logically, it's more the other way around - REPLs are in that sense a compensation for static types, since nothing forbids having a REPL and static types (see: eg. Julia. OCaml, Haskell, Scala etc. have REPLs too, but they are closed-world).

There's a fundamental trade-off though, with the open- vs closed-world assumption - if your types and (generic) methods are open world, then certain kinds of errors are just not analyzable. (this is a more general mathematical truth, also occurring in eg. description logics and the Semantic Web)

As you hinted, REPLs also don't work well for eg. large pipelines farmed out to clusters of machines, or anything that requires a high degree of static assurance, eg. control software - you either must statically analyze for all errors for it to even be legal, or the cost of having to "live fix" an error is much larger than preventing it in the first place (or just impractical for clusters).

Sure, a degree of live patching and experimenting is desirable (namedrop JPL as Lispers do), but that's a somewhat orthogonal concern.

A Lisp-style REPL combines introspection and live patching for both code and data. This can be achieved in many heterogenous ways besides a REPL, though. It's just not a nice, curated and holistic experience. But agents don't really care about that. LLMs don't get magic feelings. They can easily work around minor annoyances and a lack of ergonomics (assuming it doesn't burn context).

(Since LLMs tend to leave junk behind and slowly corrupt everything over time, a persistent image is also not necessarily a good thing. Reproducibility is also harder.)

The Unix philosophy "everything is a file" can ultimately also be viewed as image-based programming. [1] The system is the image.

As long as you have a way to address (via files, namespaced symbols, UUIDs, URLs, numbers etc.) the code, the execution state (ie. the stack frames) and memory (ie. the heap of objects), it has the same effect.

The problem with most software is that its internals are not addressable. I don't think one has to use eg. Lisp to fix that though. I do acknowledge that most static languages fail here.

[1]: "Unix, Plan 9 and the Lurking Smalltalk" https://www.humprog.org/~stephen/research/papers/kell19unix-...