Live data from Hacker News

Ask HN: Code should be stored in a database. Who has tried this?

news.ycombinator.com

11–20 of 51 posts

Re: Ask HN: Code should be stored in a database. Who has tried this?

#12
post #8

Earlier quoted context omitted.

Smalltalk stores: memory snapshot "image" AND "change log" text file AND "sources" text file. https://cuis-smalltalk.github.io/TheCuisBook/Code-Management... If the "sources" file is missing the byte code will be decompiled to show class and method definitions, but the original names will be unknown.

It is only an implementation detail. It is a matter of change of a few methods only to store sources directly in methods. I tried that once.

It's all only "an implementation detail".

Some of them are documented and expected.

Re: Ask HN: Code should be stored in a database. Who has tried this?

#14
I don't think this is unique to code, but a limitation of filesystems in general. You could make the same argument for photos: I want them sorted by date, by tag, by person in the image, by location.

I can do this in Lightroom or my "Photo" app, but then you are always reliant on some third-party tool. It would be nice if there was some native way for files to not have to commit to a single hierarchy, but able to switch views on the fly (without it being insanely slow for larger amount of files).

Re: Ask HN: Code should be stored in a database. Who has tried this?

#15
1. The biggest advantage of storing on the filesystem is that Files are the core primitive on UNIX based operating systems, and is core-enough on Windows. Giving that up would require tremendously good reasons.

2. Everyone organizes projects into folders differently, but in most languages the only reason why you organize things into folders is to make it easier for humans to find things. The computer doesn't care where the files are stored. So, you're proposing: Give up a feature that exists solely to make it easier for humans to find things; its extremely difficult to envision a world where this results in a more ergonomic world.

3. The hierarchy is only one way of thinking about how you can browse a filesystem. There is nothing stopping editors from indexing files in different ways, allowing you to browse by, for example, files tagged with some comment at the top, or files which contain classes versus interfaces. In fact, more comprehensive IDEs like JetBrains already do this for some languages. You don't have to change the storage substrate to get 100% of the benefits you propose, with the extremely small cost of some indexing process when a project is first opened.

4. There are twenty billion programming languages out there, like four of them do what you're suggesting, yet no one uses any of them for anything meaningful. There is nothing, period, stopping any new language from doing something like this. Golang could have been designed like this; but it wasn't.

Re: Ask HN: Code should be stored in a database. Who has tried this?

#18
> To me it seems obvious that code should be stored in a database rather than a hierarchical, text-based format.

So, granted a filesystem does exhibit CRUD, and hierarchical relations, it's already a relational database.

I take this as you are arguing about the utility of a text based format?

Re: Ask HN: Code should be stored in a database. Who has tried this?

#19
post #15

1. The biggest advantage of storing on the filesystem is that Files are the core primitive on UNIX based operating systems, and is core-enough on Windows. Giving that up would require tremendously good reasons. 2. Everyone organizes projects into folders differently, but in most languages the only reason why you organize things into folders is to make it easier for humans to find things. The computer doesn't care whe…

> Golang could have been designed like this; but it wasn't.

Funny choice to use as an example. Go was designed by the same people who designed Plan 9. If no other language out there used files, Go would have still chosen to use files.

Re: Ask HN: Code should be stored in a database. Who has tried this?

#20
The code is meant for humans, and in my view, the database is not really for humans. There are plenty of tools in IDEs that transform code into a 'database,' and in 20 years I've never really needed to use them on a daily basis. Except for getting familiar with legacy code, and even then to create a mental map, the database seems like overkill to me. That said, I should note that I've primarily worked on startup or business codebases, not FAANG or equivalent ones.

Edit : Reformulation because I was voted down : Why change the storage format if the IDE already manage it ? And I add, For storing in database, you have to think about the granularity of your data. and it rapdily become the line, if not the character. Working daily with code stored in database, (salesforce), where the granularity is the class, is really anigthmare from a Content Version point of view.

Post reply on HN