Ask HN: What codebase would you like to see rewritten, updated, or modernized?
8 comments
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/
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/
> 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.
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.
Interesting, thanks for the link.
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”.
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”.
Inkscape. I love it, but a bit of touchup work would be really nice. I would especially love boxes and connectors to be even more seamless, so I can replace all the digital whiteboard apps with it.
homebrew. I dream of something quick and simple to use as uv is now for python ecosystem
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
https://github.com/jdx/mise
Compiz. It has never been surpassed as a desktop environment.
[1] https://news.ycombinator.com/item?id=44455787