Don't need to put the code in a database to do that. You can do that entirely with specially formatted comments and a projectional editor.
Ask HN: Code should be stored in a database. Who has tried this?
11–20 of 51 posts
Re: Ask HN: Code should be stored in a database. Who has tried this?
#12Earlier 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.
Some of them are documented and expected.
Re: Ask HN: Code should be stored in a database. Who has tried this?
#13Re: Ask HN: Code should be stored in a database. Who has tried this?
#14I 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?
#152. 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?
#16Re: Ask HN: Code should be stored in a database. Who has tried this?
#17I'm sorry i don't read binary files.
Re: Ask HN: Code should be stored in a database. Who has tried this?
#18So, 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?
#191. 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…
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?
#20Edit : 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.