3 ms·

> naming things is one of the hard things to do in computer science I've been thinking about that a lot lately. Code is text, it's arranged linearly, code has

> naming things is one of the hard things to do in computer science I've been thinking about that a lot lately. Code is text, it's arranged linearly, code has to be readable, identifiers are thus short strings that try to express short essays about the purpose of the variable or whatever it is, and then ideally there's a longer version of the essay in a comment, but not too long because that would clutter up the code as well (because it's text, arranged linearly). And we have code folding to tidy them up, for what good it does, and ideally an even longer version of the essay in documentation except nobody writes that. What if it wasn't text, and wasn't linear, and we didn't have an expectation that code should be strings of stupid over-terse names and hieroglyphic symbols? So I was thinking vaguely about investigating graphic-based programming, but it's probably worse, IDK. It could automatically assign arbitrary icons* instead of identifiers, and you could write tooltip-like comments to describe them as and when you want to, and everything could be laid out nicely with diagrams and different pages instead of like a text file. I suppose this is all merely cosmetic? The thing with the instance on code being written as strings of text feels very primitive, is all. It causes this problem. * Which doesn't solve the problem, I admit, because now you have to remember what the icons mean, but maybe that's easier?

jstanley 2y ago
I don't think remembering the meaning of icons is easier, because in order to think about it you have to be able to pronounce it inside your head. And code isn't just linear, it can be spread across multiple files in a directory tree, functions can can each other, etc.
- c22 2y ago
  > in order to think about it you have to be able to pronounce it inside your head. I'm not sure this is universal.
  - vidarh 2y ago
    Indeed, some people do not even have an inner voice, the same way some of us don't "see" things in our minds eye. Neither prevents you from thinking about words or visual objects.
pjc50 2y ago
> I was thinking vaguely about investigating graphic-based programming, but it's probably worse, IDK. It could automatically assign arbitrary icons* instead of identifiers, and you could write tooltip-like comments to describe them as and when you want to, and everything could be laid out nicely with diagrams and different pages instead of like a text file. Have you ever read large electronic schematics? That's basically it .. except all the important things have to be identified by text anyway, because it's a massive challenge to the imagination to come up with two hundred different pictograms. Of course, if you really want your identifiers to be pictograms, why not just use kanji for your identifiers? The Japanese language and Unicode provide tens of thousands of ready made pictograms for your convenience! The only nonlinear programming environments that have really worked are the spreadsheet (which is still linear within each cell) and Labview. Possible shoutout to Unity blueprints, but when those get too complicated sphagetti .. people rewrite them in linear text code.
- card_zero 2y ago
  Sigh I guess you're right. This has been a dimly-felt wish of mine for some 25 years, but probably pie in the sky. Edit: I see there are a lot of visual programming languages. https://en.wikipedia.org/wiki/Visual_programming_language https://en.wikipedia.org/wiki/Visual_programming_language
  - 9dev 2y ago
    I don’t think that has to be the answer, though. We can probably all agree that plaintext code is not the best form to represent the schematics of a process, and neither are images. But that seems to be a very limited set of options, and I wonder if there aren’t any other dimensions to express what is essentially persisted chains of reasoning. For an example of alternative modes of input, have a look at the Reactable, a pretty innovative way to compose music. Sadly I think they didn’t disrupt the music industry as they should have, but it’s a pretty good example of a new way to think about making sounds. Edit: forgot the link. Here is: http://reactable.com http://reactable.com
  - WillAdams 2y ago
    Longer than that --- I would argue it goes back to Herman Hesse's _The Glass Bead Game_ (originally published as Magister Ludi) --- but Hesse seems to have gone out of style. That said, I keep trying various ones, and will keep hoping that someday someone will make a graphical tool able to make a GUI program. Nodezator seems promising.
jcranmer 2y ago
Graphical programming is one of those things that's often suggested as an improvement on textual programming, and just about every implementation tends to disappoint. I know, when working on compilers, that nearly every time I go "I think I want to see the CFG as a graph here," I tend to realize no, that's not quite what I wanted. For a complex function, the surprising superpower is just to have an editor that shows the opening brace line of every currently-open brace. Another case in point: when was the last time you saw someone use a flowchart to describe the pseudocode of an algorithm, as opposed to writing, er, pseudocode? Flowcharts used to be the dominant way to do this, decades ago, but they seem to me to have been thoroughly supplanted by pseudocode...
- WillAdams 2y ago
  I think the problem here is that there isn't an agreed-upon answer for the question: >What does an algorithm look like? And any effort to answer it which gets beyond the size of a single diagram/screen/page/poster becomes a problem like to: https://blueprintsfromhell.tumblr.com/ https://blueprintsfromhell.tumblr.com/ https://scriptsofanotherdimension.tumblr.com/ https://scriptsofanotherdimension.tumblr.com/ I like to think of myself as a visual person, and I wish there was a good solution here, and I keep looking for and trying different solutions other folks have made (current two iterations are BlockCAD and OpenSCAD Graph Editor) --- I'd be glad of other suggestions, esp. if able to make graphic user interfaces more complex than the OpenSCAD Customizer.
  - card_zero 2y ago
    Argh! Wire-wrapped backplanes! That wasn't the fantasy at all!
    - WillAdams 2y ago
      Yes, the fantasy is something like to Herman Hesse's _The Glass Bead Game_ which I mentioned elsethread --- what is the closest available tool to that? How do such tools manage the problem of encapsulation/modularity becoming the "wall of text" which one is trying to escape, just a pretty wall w/ all the labels in boxes decorated/connected w/ lines?
AlienRobot 2y ago
The difficult in naming things is that you're trying to encode semantics and an interface contract in a name. If you give up doing that, it's easy. For example, say you have getFoo(). It's clear it gets the foo. But later you introduce getFooAsync(). Suddenly it's no longer clear whether getFoo() is sync or async, because you didn't call it getFooSync(). If instead you used names like getFoo1, getFoo2, getFoo3, etc., the semantics you're providing is that there are multiple "ways" to getFoo without making promises (a contract) about what the function actually does in its name. Although this sounds like bad naming practices (it is), it effectively solves the naming problem. Apply this to CSS, and instead of .red-button or .secondary-button, you get .button1, .button2, .button3, and you just don't have to think about WHY are you creating a button to give it a class and start styling it.
- card_zero 2y ago
  Yep, that sort of thing happens constantly. Things get misleading names because the first three alternatives I came up with were also misleading. So I agree, and indeed I considered a foo bar baz scheme instead of icons, same difference. Then you have to look somewhere else for what the thing does. Self-documenting code doesn't really work, and strict naming schemes are long-winded and worse than ad-libbing it, so it would have to be comments, but then the comments get forgotten and no longer reflect the code. I give up, might take up woodwork instead.

jstanley 2y ago

I don't think remembering the meaning of icons is easier, because in order to think about it you have to be able to pronounce it inside your head. And code isn't just linear, it can be spread across multiple files in a directory tree, functions can can each other, etc.

c22 2y ago
> in order to think about it you have to be able to pronounce it inside your head. I'm not sure this is universal.
- vidarh 2y ago
  Indeed, some people do not even have an inner voice, the same way some of us don't "see" things in our minds eye. Neither prevents you from thinking about words or visual objects.

pjc50 2y ago

> I was thinking vaguely about investigating graphic-based programming, but it's probably worse, IDK. It could automatically assign arbitrary icons* instead of identifiers, and you could write tooltip-like comments to describe them as and when you want to, and everything could be laid out nicely with diagrams and different pages instead of like a text file. Have you ever read large electronic schematics? That's basically it .. except all the important things have to be identified by text anyway, because it's a massive challenge to the imagination to come up with two hundred different pictograms. Of course, if you really want your identifiers to be pictograms, why not just use kanji for your identifiers? The Japanese language and Unicode provide tens of thousands of ready made pictograms for your convenience! The only nonlinear programming environments that have really worked are the spreadsheet (which is still linear within each cell) and Labview. Possible shoutout to Unity blueprints, but when those get too complicated sphagetti .. people rewrite them in linear text code.

card_zero 2y ago
Sigh I guess you're right. This has been a dimly-felt wish of mine for some 25 years, but probably pie in the sky. Edit: I see there are a lot of visual programming languages. https://en.wikipedia.org/wiki/Visual_programming_language https://en.wikipedia.org/wiki/Visual_programming_language
- 9dev 2y ago
  I don’t think that has to be the answer, though. We can probably all agree that plaintext code is not the best form to represent the schematics of a process, and neither are images. But that seems to be a very limited set of options, and I wonder if there aren’t any other dimensions to express what is essentially persisted chains of reasoning. For an example of alternative modes of input, have a look at the Reactable, a pretty innovative way to compose music. Sadly I think they didn’t disrupt the music industry as they should have, but it’s a pretty good example of a new way to think about making sounds. Edit: forgot the link. Here is: http://reactable.com http://reactable.com
- WillAdams 2y ago
  Longer than that --- I would argue it goes back to Herman Hesse's _The Glass Bead Game_ (originally published as Magister Ludi) --- but Hesse seems to have gone out of style. That said, I keep trying various ones, and will keep hoping that someday someone will make a graphical tool able to make a GUI program. Nodezator seems promising.

jcranmer 2y ago

Graphical programming is one of those things that's often suggested as an improvement on textual programming, and just about every implementation tends to disappoint. I know, when working on compilers, that nearly every time I go "I think I want to see the CFG as a graph here," I tend to realize no, that's not quite what I wanted. For a complex function, the surprising superpower is just to have an editor that shows the opening brace line of every currently-open brace. Another case in point: when was the last time you saw someone use a flowchart to describe the pseudocode of an algorithm, as opposed to writing, er, pseudocode? Flowcharts used to be the dominant way to do this, decades ago, but they seem to me to have been thoroughly supplanted by pseudocode...

WillAdams 2y ago
I think the problem here is that there isn't an agreed-upon answer for the question: >What does an algorithm look like? And any effort to answer it which gets beyond the size of a single diagram/screen/page/poster becomes a problem like to: https://blueprintsfromhell.tumblr.com/ https://blueprintsfromhell.tumblr.com/ https://scriptsofanotherdimension.tumblr.com/ https://scriptsofanotherdimension.tumblr.com/ I like to think of myself as a visual person, and I wish there was a good solution here, and I keep looking for and trying different solutions other folks have made (current two iterations are BlockCAD and OpenSCAD Graph Editor) --- I'd be glad of other suggestions, esp. if able to make graphic user interfaces more complex than the OpenSCAD Customizer.
- card_zero 2y ago
  Argh! Wire-wrapped backplanes! That wasn't the fantasy at all!
  - WillAdams 2y ago
    Yes, the fantasy is something like to Herman Hesse's _The Glass Bead Game_ which I mentioned elsethread --- what is the closest available tool to that? How do such tools manage the problem of encapsulation/modularity becoming the "wall of text" which one is trying to escape, just a pretty wall w/ all the labels in boxes decorated/connected w/ lines?

AlienRobot 2y ago

The difficult in naming things is that you're trying to encode semantics and an interface contract in a name. If you give up doing that, it's easy. For example, say you have getFoo(). It's clear it gets the foo. But later you introduce getFooAsync(). Suddenly it's no longer clear whether getFoo() is sync or async, because you didn't call it getFooSync(). If instead you used names like getFoo1, getFoo2, getFoo3, etc., the semantics you're providing is that there are multiple "ways" to getFoo without making promises (a contract) about what the function actually does in its name. Although this sounds like bad naming practices (it is), it effectively solves the naming problem. Apply this to CSS, and instead of .red-button or .secondary-button, you get .button1, .button2, .button3, and you just don't have to think about WHY are you creating a button to give it a class and start styling it.

card_zero 2y ago
Yep, that sort of thing happens constantly. Things get misleading names because the first three alternatives I came up with were also misleading. So I agree, and indeed I considered a foo bar baz scheme instead of icons, same difference. Then you have to look somewhere else for what the thing does. Self-documenting code doesn't really work, and strict naming schemes are long-winded and worse than ad-libbing it, so it would have to be comments, but then the comments get forgotten and no longer reflect the code. I give up, might take up woodwork instead.