4 ms·

Why are we stuck treating programs as structureless character sequences? The converse question is “why aren’t we all doing visual programming?” I think the an

Why are we stuck treating programs as structureless character sequences? The converse question is “why aren’t we all doing visual programming?” I think the answer is that plain text actually works out better for most purposes. It’s tool-agnostic, it’s reasonably easy to manage in source control, it’s reasonably easy to repair by hand when things get broken, it’s reasonably easy to maintain as tools get upgraded. Yes, it sucks in many ways. Spaces in filenames messing up shell scripts is my own pet peeve. On balance I think it’s good that you can write programs in a generic raw text editor, with things like syntax highlighting, formatting and completion being very-nice-to-have added extras. If you couldn’t so much as double-click to select an identifier without tool assistance, that would be pretty annoying when it (inevitably) sometimes goes wrong.

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.
Firadeoclus 4y ago
A "generic raw text editor" is a tool. The vast majority of text editors people use are actually quite complex, way beyond the complexity that would be needed to implement a "generic structured data editor". And the latter could make many very-nice-to-have features simpler to implement so it would very likely end up with less complexity than a full-featured "text editor". The main problem to be solved is that structured data editors (and structured data query tools) are not ubiquitous, even though structured data formats are. Which really is a shame, considering the amount of time and effort sunk into issues (TFA, tabs vs. spaces, unmatched delimiters and other structural typos, syntax extensibility, etc.) that wouldn't even have to exist if we weren't dealing with raw text.

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.

Firadeoclus 4y ago

A "generic raw text editor" is a tool. The vast majority of text editors people use are actually quite complex, way beyond the complexity that would be needed to implement a "generic structured data editor". And the latter could make many very-nice-to-have features simpler to implement so it would very likely end up with less complexity than a full-featured "text editor". The main problem to be solved is that structured data editors (and structured data query tools) are not ubiquitous, even though structured data formats are. Which really is a shame, considering the amount of time and effort sunk into issues (TFA, tabs vs. spaces, unmatched delimiters and other structural typos, syntax extensibility, etc.) that wouldn't even have to exist if we weren't dealing with raw text.