3 ms·
The original question was around spaces in identifier names; let me describe how I imagined that would go and you can pick holes in it: - on disk, use (bracket
by iainmerrick 4y ago
The original question was around spaces in identifier names; let me describe how I imagined that would go and you can pick holes in it:
- on disk, use (brackets around identifiers) so they parse
- but you don't want to have to keep typing those, so...
- have a smart IDE that manages identifier brackets for you
- display identifiers in special colours, fonts, etc
Maybe this is a slippery slope argument, but I think when you do that, you've taken a step towards visual programming, where the code is a special data structure and you can only feasibly interact with it via special tooling. I'm with the camp who think that gives you SmallTalk images or UML and it just doesn't work out.
An alternative would be not to put brackets around long identifiers, just have a smarter context-sensitive parser; but I think that's also a bad direction to go in. Putting lots of complexity into the parser (C++, Perl) is a bad idea and keeping the parser simple and regular is a good idea (Go, Python).
EDIT TO ADD:
The problem is that a tree of directories and files is clearly not a very good abstraction for structuring programs
Hmm, I disagree! It's not perfect, but I think it actually works pretty well. Files and folders map nicely onto modules and packages, and those are a reasonably effective way of organising the code for a big project.
- ihatepython 4y agoInstead of using spaces in identifier names, how about using %20 in its place? For example, the identifier "home address" becomes "home%20address"
- pavlov 4y agoI haven’t thought about this deeply at all, but could there be a level of indirection similar to what the file system does with inodes vs. paths? It would of course require IDE support to resolve the identifier names for display. I know there are some recent systems that use content addressing for code. Each function or piece of program data is identified by its hash only, so they can be modified without breaking dependencies (editing a function creates a new version). This is basically the same idea as my inode-like suggestion but with deeper ramifications due to immutability.