Ask HN: What codebase would you like to see rewritten, updated, or modernized?

6 points by globnomulous 10 hours ago

Inspired by this phenomenal write-up of the author's experience in rewriting tmux[1], I'd like to hear from HN: what codebases would benefit from a similar treatment? Or what codbases would you like to see get the 'star' treatment in some way or another -- an upgraded tech stack, modernization, or a rewrite in another language, or in a different idiom/pattern, that you think would be better suited to the job it does?

[1] https://news.ycombinator.com/item?id=44455787

geophph 2 hours ago

The main codebase a team I work with uses.

They’re a data science team mostly but the main “data processing engine” that they solely rely on was written by a dude who split right as he “finished it”. No one knows how it really works. Black box style. Has been “the way” for 5 years. I’m not sure if no one cares, or no one cares to care, but they don’t seem to want to change it. Maybe it works, but also funny how many business critical decisions are made based on the code that everyone has only ever “just trusted”.

colkassad 10 hours ago

GDAL [1]

Don't get me wrong, it's a fantastic and ancient coral reef of a library and tool set but has a lot of inconsistencies in naming conventions and usage (gdal_translate, gdalfinfo). Many geospatial professionals are not savvy enough to leverage it without it being wrapped by someone else like Esri. Windows power users typically install it with something like OSGeo4W [2], whose name I can never remember. Whenever I need it I spin up a Docker image for convenience.

[1] https://github.com/OSGeo/gdal [2] https://trac.osgeo.org/osgeo4w/

  • perrygeo 9 hours ago

    > inconsistencies

    You'll be interested in the changes in 3.11, a single `gdal` entrypoint with a modern CLI. https://gdal.org/en/stable/development/rfc/rfc104_gdal_cli.h...

    Installation is still a beast, mainly because it's one monolithic thing. It's a spatial analysis library, dozens of applications, and hundreds of filetype drivers - all in a single build process. Each driver has its own quirks and the abstraction leaks like a sieve. In retrospect, I think the spatial logic, the drivers, and the apps should have been broken up into loosely-coupled components. But the convenience of an all-in-one megalith was hard to beat.

    • colkassad 7 hours ago

      Interesting, thanks for the link.

horsellama 9 hours ago

homebrew. I dream of something quick and simple to use as uv is now for python ecosystem

  • bnycum 7 hours ago

    I wouldn’t say it’s a full replacement for homebrew, but I am enjoying mise so far after hearing about it earlier this week.

    https://github.com/jdx/mise