3 ms·

> "The converse question is 'why aren’t we all doing visual programming?'" IMO this is not the right framing because it suggests a dichotomy where we must choo

by pavlov 4y ago

> "The converse question is 'why aren’t we all doing visual programming?'" IMO this is not the right framing because it suggests a dichotomy where we must choose between a CLI or some kind of GUI node spaghetti editor. It's perfectly possible to add structure to data and still edit it on a CLI. After all that's how file systems work. We don't address our data by raw sectors on disk; instead there are layers of data structures on top, and they're designed to be reasonably easy to use via CLI through concepts like directories and files (rather than having to poke raw inodes for example). The problem is that a tree of directories and files is clearly not a very good abstraction for structuring programs, but there hasn't been a lot of experimentation on how we could layer a more suitable data structure on top. Smalltalk had a completely different (and incompatible) approach with its image model. It kind of feels like everyone in the PC space looked at Smalltalk, said "oh that's not going to work either", and then gave up on trying to improve program structure.

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 ago
  Instead of using spaces in identifier names, how about using %20 in its place? For example, the identifier "home address" becomes "home%20address"
- pavlov 4y ago
  I 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.

by pavlov 4y ago

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 ago
Instead of using spaces in identifier names, how about using %20 in its place? For example, the identifier "home address" becomes "home%20address"
pavlov 4y ago
I 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.