Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Experiment on Code Structure

pboyd.io

Post reply on HN
Print view View original

51–60 of 62 posts

Re: An Experiment on Code Structure

#51

Post by kyberias »

lazulicurio wrote: post #37
kyberias wrote: post #11

Earlier quoted context omitted.

Multiple files also seems like a problem for IDEs to solve, not programmers.

That brings to mind an interesting idea for an IDE: having one big virtual file that you edit, which gets split into multiple physical files on disk (based on module/class/whatever). Although, thinking about it, there are some languages that would make such automatic restructuring rather difficult.

Yes! Why can't OOP language editors (IDE) simply represent the source code of classes, interfaces and other type definitions as they are without even revealing anything about the files they reside in? The technical detail of source code being stored in files is mundane.

Re: An Experiment on Code Structure

#52

Post by userbinator »

lazulicurio wrote: post #37
kyberias wrote: post #11

Earlier quoted context omitted.

Multiple files also seems like a problem for IDEs to solve, not programmers.

That brings to mind an interesting idea for an IDE: having one big virtual file that you edit, which gets split into multiple physical files on disk (based on module/class/whatever). Although, thinking about it, there are some languages that would make such automatic restructuring rather difficult.

That brings to mind an interesting idea for an IDE: having one big virtual file that you edit, which gets split into multiple physical files on disk

If you're going to work with it as one big file, then what's the point of multiple physical files anyway? Just store it as one big file then.

Re: An Experiment on Code Structure

#53

Post by ScottFree »

userbinator wrote: post #52
lazulicurio wrote: post #37

Earlier quoted context omitted.

That brings to mind an interesting idea for an IDE: having one big virtual file that you edit, which gets split into multiple physical files on disk (based on module/class/whatever). Although, thinking about it, there are some languages that would make such automatic restructuring rather difficult.

That brings to mind an interesting idea for an IDE: having one big virtual file that you edit, which gets split into multiple physical files on disk If you're going to work with it as one big file, then what's the point of multiple physical files anyway? Just store it as one big file then.

Why store it as a (text) file at all? Why not store the code in a database? Or as binary? Then you can store metadata pertaining to the code and not just the code itself. Unreal blueprints are an interesting way of structuring code and providing a componetized api. It would be interesting if they were more closely integrated with the code itself. Then you could manipulate data flows, code and even do debugging from inside the same interface.

Yes, this is all pie in the sky stuff, but it's interesting to think about.

Re: An Experiment on Code Structure

#54

Post by marcus_holmes »

skohan wrote: post #48
marcus_holmes wrote: post #27

Earlier quoted context omitted.

I love this. Currently working on a file storage system that gets away from folders, and that's hard because everyone has folders hard-wired into their brains because history. Functions shouldn't live in files, for a start. Files are an artefact of storing code in a file-based storage system, and have nothing to do with code architecture. Creating a code editor that stopped working with files and only worked with fun…

File systems aren't without their advantages. One huge advantage is that text files are extremely un-opinionated about how they're used. If my project exists as a tree of directories with text files inside, there are a ton of tools which can operate on them without any knowledge of my program or even programming language. I can open them in vim or my favorite IDE, dump them to the console with cat, manage versions wi…

interesting. But if you assume functions don't intrinsically live in files, they just do that because we have a file-based storage system, and that functions actually live in, say, scopes, then what does that do to your tools?

Can we have a Vim that understands (e.g) scopes natively rather than files?

Re: An Experiment on Code Structure

#55

Post by marcus_holmes »

harimau777 wrote: post #32
marcus_holmes wrote: post #29

I've become a big fan of not worrying about architecture until the rewrite. The first version is always an exploration of the problem domain, and treating it as that has always made my projects go quicker. This is going to trigger some people, so here's some caveats: - there's always a rewrite. Even with perfect architecture. Usually because nobody understands the problem domain until there's been an exploration of i…

The issue that I see with this is that, even if they say otherwise during the first version, when it comes time for the rewrite the powers that be often (usually?) aren't willing to support it.

The "powers that be" are non-tech-aware. They care about results, not nerds pushing the nerd buttons (I paraphrase).

They literally have no clue about what they're asking for, and just have to hope that the people doing the coding can deliver what they want. There's no backup, no "plan B", no way of delivering this without relying on the devs to deliver. So, who cares what they think?

You can literally say to them "we can continue like this, but because of tech debt it'll take 6 months, or we can rewrite in 3 months". And who's to say you're wrong? I've had more than one project do that.

The truth is that no-one knows how long any of this takes. Not the devs, not the project manager, not the CEO. It's always a rough guesstimate, and the estimates only get better with more information. Smart non-tech managers get this, and deal with it. Stupid non-tech managers try to control it and create deterministic outcomes from the non-deterministic process that is software dev. That always fails.

So, yeah, the "powers that be" need to grok the nature of the thing they're trying to do before saying "you can't do a rewrite even if you think that'll be quicker"

Re: An Experiment on Code Structure

#56

Post by marcus_holmes »

specialist wrote: post #43
marcus_holmes wrote: post #29

I've become a big fan of not worrying about architecture until the rewrite. The first version is always an exploration of the problem domain, and treating it as that has always made my projects go quicker. This is going to trigger some people, so here's some caveats: - there's always a rewrite. Even with perfect architecture. Usually because nobody understands the problem domain until there's been an exploration of i…

"...until the rewrite" Old school me understood we always create three versions: understand the problem, understand the solution, do it right. I'm poorly adapted to today's world where projects don't mature past the first stage. Because of fashion, re-orgs, acquisitions, general purpose chaos.

closely related to the "get it working, get it quick, get it pretty" process of experienced devs doing new stuff.

Re: An Experiment on Code Structure

#57

Post by pdimitar »

ScottFree wrote: post #53
userbinator wrote: post #52

Earlier quoted context omitted.

That brings to mind an interesting idea for an IDE: having one big virtual file that you edit, which gets split into multiple physical files on disk If you're going to work with it as one big file, then what's the point of multiple physical files anyway? Just store it as one big file then.

Why store it as a (text) file at all? Why not store the code in a database? Or as binary? Then you can store metadata pertaining to the code and not just the code itself. Unreal blueprints are an interesting way of structuring code and providing a componetized api. It would be interesting if they were more closely integrated with the code itself. Then you could manipulate data flows, code and even do debugging from i…

I have been toying with the idea to store programming projects in a single sqlite3 database butt never seen enough value to actually pursue it.

As you mentioned though, it's interesting to think about.

Re: An Experiment on Code Structure

#58

Post by TeMPOraL »

marcus_holmes wrote: post #54
skohan wrote: post #48

Earlier quoted context omitted.

File systems aren't without their advantages. One huge advantage is that text files are extremely un-opinionated about how they're used. If my project exists as a tree of directories with text files inside, there are a ton of tools which can operate on them without any knowledge of my program or even programming language. I can open them in vim or my favorite IDE, dump them to the console with cat, manage versions wi…

interesting. But if you assume functions don't intrinsically live in files, they just do that because we have a file-based storage system, and that functions actually live in, say, scopes, then what does that do to your tools? Can we have a Vim that understands (e.g) scopes natively rather than files?

It would have to not just understand scopes, but their sequential relationship. In most languages, scopes don't just exist, they are loaded, in a particular order. There are "top-level" effects that happen from loading a piece of code into compiler/runtime until the end. Maybe this is different in purely functional languages (though I suspect not at compilation level).

Re: An Experiment on Code Structure

#59

Post by skohan »

marcus_holmes wrote: post #54
skohan wrote: post #48

Earlier quoted context omitted.

File systems aren't without their advantages. One huge advantage is that text files are extremely un-opinionated about how they're used. If my project exists as a tree of directories with text files inside, there are a ton of tools which can operate on them without any knowledge of my program or even programming language. I can open them in vim or my favorite IDE, dump them to the console with cat, manage versions wi…

interesting. But if you assume functions don't intrinsically live in files, they just do that because we have a file-based storage system, and that functions actually live in, say, scopes, then what does that do to your tools? Can we have a Vim that understands (e.g) scopes natively rather than files?

> Can we have a Vim that understands (e.g) scopes natively rather than files?

Sure we can have a vim that does that. But as I say, it would require tighter binding between the tooling and the code representation.

Right now vim only has to understand code as lines of text separated by spaces, newlines, and tabs. The semantics of that code are the business of the build system and the compiler. The same goes for git. As a result, tools like git and vim can operate on code of any language which is represented as text. That could be an popular language like Java or Go, or some weird experimental language you dream up yourself.

If, as you suggest, the storage representation of the language were tied to the semantics of the language, rather than some external format, then all the tools need to have a deeper understanding of the language itself in order to operate on that storage.

You could try to make it general: i.e. design an organizational structure based on "scopes" which should apply to all languages, but then what if a language comes along which doesn't fit neatly into the "scopes" paradigm? Now you put yourself into a position where you might be making language design decisions which are based on what's possible with the tooling, rather than what's the best possible choice for the language?

Decoupling the storage method from the semantics of the language obviates these problems.

Re: An Experiment on Code Structure

#60

Post by marcus_holmes »

skohan wrote: post #59
marcus_holmes wrote: post #54

Earlier quoted context omitted.

interesting. But if you assume functions don't intrinsically live in files, they just do that because we have a file-based storage system, and that functions actually live in, say, scopes, then what does that do to your tools? Can we have a Vim that understands (e.g) scopes natively rather than files?

> Can we have a Vim that understands (e.g) scopes natively rather than files? Sure we can have a vim that does that. But as I say, it would require tighter binding between the tooling and the code representation. Right now vim only has to understand code as lines of text separated by spaces, newlines, and tabs. The semantics of that code are the business of the build system and the compiler. The same goes for git. As…

thanks for the answer, that's interesting.

We do have this to a certain extent now, though - file scope is a thing in some languages.

I'll give up my plan to write a neovim plugin for scope management, though ;)

Post reply on HN