5 ms·

which possibly is a good thing the Judy project seems inactive to me: https://sourceforge.net/p/judy/bugs/ https://sourceforge.net/p/judy/bugs/ this short HN

by froh 4y ago

which possibly is a good thing the Judy project seems inactive to me: https://sourceforge.net/p/judy/bugs/ https://sourceforge.net/p/judy/bugs/ this short HN thread resonates with the intuition of jude1 being stalled, it's last optimistic comment points to an orphaned comment in the big list above https://news.ycombinator.com/item?id=32188204 https://news.ycombinator.com/item?id=32188204

jpgvm 4y ago
It's certainly not active but perhaps could be revived now that the patents have expired (filed in 2001 so expired last year). On the surface it's just a very optimized 256-ary radix trie. I think it would take some software archeology to determine if there was more to it than that and if it's assumptions still hold on todays processors.
nullc 4y ago
Does it need to be active? It's done and it works. It's not written in an highly unstable language. The safety of every bridge you drive over was probably partially validated using fortran numerical code from the 1980s.
- froh 4y ago
  https://github.com/Reference-LAPACK/lapack/commits/master https://github.com/Reference-LAPACK/lapack/commits/master said fortran code happily gets minor and major updates
  - nullc 4y ago
    I wasn't actually referring to LAPACK but other FEM code. :)
    - froh 4y ago
      Point being: a project needs updates to remain useful in contemporary contexts. code that happily built -Wall, pedantic, error... in April 2002 may fail miserably in today's tool chain. plus it may not benefit from contemporary advances in silicon architecture, etc.
jasonwatkinspdx 4y ago
Judy arrays have never been particularly compelling, but for some reason gained huge mindshare among programmers on Slashdot. Today it'd make much more sense to implement ART, which is dramatically simpler.
- vanderZwan 4y ago
  As someone with a degree in contemporary arts who switched to programming I humbly disagree with this statement. Jokes aside, it took me quite a bit of trial and error to figure out that you are (probably) referring to Adaptive Radix Trees. Because "art tree" doesn't exactly give useful results.

by froh 4y ago

jpgvm 4y ago

It's certainly not active but perhaps could be revived now that the patents have expired (filed in 2001 so expired last year). On the surface it's just a very optimized 256-ary radix trie. I think it would take some software archeology to determine if there was more to it than that and if it's assumptions still hold on todays processors.

nullc 4y ago

Does it need to be active? It's done and it works. It's not written in an highly unstable language. The safety of every bridge you drive over was probably partially validated using fortran numerical code from the 1980s.

froh 4y ago
https://github.com/Reference-LAPACK/lapack/commits/master https://github.com/Reference-LAPACK/lapack/commits/master said fortran code happily gets minor and major updates
- nullc 4y ago
  I wasn't actually referring to LAPACK but other FEM code. :)
  - froh 4y ago
    Point being: a project needs updates to remain useful in contemporary contexts. code that happily built -Wall, pedantic, error... in April 2002 may fail miserably in today's tool chain. plus it may not benefit from contemporary advances in silicon architecture, etc.

jasonwatkinspdx 4y ago

Judy arrays have never been particularly compelling, but for some reason gained huge mindshare among programmers on Slashdot. Today it'd make much more sense to implement ART, which is dramatically simpler.

vanderZwan 4y ago
As someone with a degree in contemporary arts who switched to programming I humbly disagree with this statement. Jokes aside, it took me quite a bit of trial and error to figure out that you are (probably) referring to Adaptive Radix Trees. Because "art tree" doesn't exactly give useful results.