10 ms·

Maybe we should spend a few thousand years coming up with a compact, information-dense manner of expressing thoughts. We could call these individual units some

Maybe we should spend a few thousand years coming up with a compact, information-dense manner of expressing thoughts. We could call these individual units something like "glyphers" or something, and we could combine them into more meaningful expressions. Text is a graphical, visual representation. While there are sometimes alternate ways of expressing things, this idea that text is not visual is weird. "Non-textual" representations is better, because we already have a rich, complex capability in good ole symbols.

ghostwriter 8y ago
> Maybe we should spend a few thousand years coming up with a compact, information-dense manner of expressing thoughts. This is called "mathematical notation".
- lenticular 8y ago
  I wonder if something along the lines of commutative diagrams would be ideal.
- Retra 8y ago
  It's called "writing", and mathematical notation is just a subset of that.
m_mueller 8y ago
while text is 2D, together with rich formatting options, program code is only 1D. have a look at the 'subtext' programming language concept that combines tables and graphs together with text based procedures, finally getting away from the constraints of program code that is designed around teletypes. https://en.wikipedia.org/wiki/Subtext_(programming_language) https://en.wikipedia.org/wiki/Subtext_(programming_language)
- taeric 8y ago
  This seems wrong. A view of your program is 1d. Conceptualizing a program is often n-dimensional. This is a large part of the difficulty. And is why some visualizations work. They effectively act as dimensional reductions, and draw on known visual metaphors.
  - uryga 8y ago
    > A view of your program is 1d. Conceptualizing a program is often n-dimensional. that sounds like a cool way of seeing things, could you explain what dimensions you're referring to?
    - taeric 8y ago
      Depends on the program. Anything you use to "index" into data is effectively a dimension. This is obvious with arrays, since you can have multidimensional arrays. However, even structs can just be seen as arrays with symbolic indexes. Usually bound by a given cardinality. That make sense?
      - uryga 8y ago
        yeah, thanks!
  - m_mueller 8y ago
    That was exactly the point I was trying to make. If you have a 2D problem and you want to represent it in today's commonly used code you either 1) flatten it down to 1D (e.g. a table becomes a JSON array of objects) 2) move it into a higher dimensional structure like a database. Now you have two problems. If your programming paradigm supports higher dimensions to tackle your problems, it just gives you a higher level platform to start tackling your problems. Before you could maybe deal with 4 dimensions at the same time at most, now you can deal with up to 5 or even 6 - we don't yet know what new solutions to problems smart people could come up with when being given such tools. Just as an example, how often do you see binary logic problems in the form of complex if-then-else procedural structures - what if you could represent two decision factors in a tabular form and let the IDE work out the missing cases for you? That's one of the ideas behind subtext. Point is I think we agree - if you think I'm fundamentally wrong I'd like to know more exactly where.
    - taeric 8y ago
      I guess I just don't agree that those are your only two options. Consider, a nested JSON structure is essentially N-dimensional. Even something as simple as a list of people is effectively multidimensional. You have the dimension of the list, and then you have the dimension of the the structure representing the people. Which, itself, my have multiple dimensions. Consider, a large part of the literature of machine learning is talking about taking a hypercubes and consequences of most distance/volume measures. (Quickly searching, https://datascience.stackexchange.com/questions/27388/what-does-it-mean-when-we-say-most-of-the-points-in-a-hypercube-are-at-the-bound https://datascience.stackexchange.com/questions/27388/what-d... talks about this.)
- nikki93 8y ago
  Code is always written with "indentation" and other things that demonstrate that the 2d canvas distribution of the glyphs you're expressing actually does matter for the human element. You're almost writing ASCII art. The ( ) and [ ] are even in there to evoke other visual types. It's ultimately 1D for the computer (a string); but so is an image (which according to you would encode 2D media) and any other media expressible in a countable number of bytes.
coldtea 8y ago
>this idea that text is not visual is weird. Everything we can see is visual in that regard. That's what not "visual" in visual programming (or visual diagram etc) means.
nikofeyn 8y ago
i sure there is probably a term for this type of argument, but this seems hopelessly dismissive on the basis of some pedantic definition of visual in this context. visual programming basically already means non-textual programming. it is about searching for new syntax and paradigms of programming that break out of the idea that one needs to inform the computer with a series of lines of text. text-based programming was born out of convenience and heavily influenced by the underlying implementations. it isn't the result of any detailed study or investigation of how to best represent ideas and concepts or how to properly describe a computation.
- mimixco 8y ago
  That's not really accurate. Visual programming systems have been around for a long time and there have been many studies of programmer productivity in various languages. Those studies have shown that programmers prefer (and perform better with) the languages where they have to type the least. Dragging things around the screen or filing-in dialog boxes (property programming) is appealing to non-programmers but, in practice, seasoned developers nearly always choose text. Visual programming hasn't taken off because it isn't as good as text for the majority of use cases. This is borne out by more than 50 years of people writing computer programs.
  - nikofeyn 8y ago
    what isn't accurate? there has been extremely little research done in the way of visual programming in comparison to text-based programming. > Visual programming hasn't taken off because it isn't as good as text for the majority of use cases. This is borne out by more than 50 years of people writing computer programs. ...writing computer programs with text. this bias is massive because nearly no one writes visual programs. a lot of that is due to availability of visual environments, some of which are quite expensive (e.g., labview). most of it is due to bias. if every single computer science and computer engineering major starts of their education with being taught "this (i.e., text) is how you program and interact with computers" then that sets up a massive bias that is nigh impossible to overcome. any study that does not address this bias is flawed. hence, we have people, who have never even programmed in a visual language, proclaiming visual programming doesn't work. i constantly hear text-based programmers say "oh, visual programming is good for niche things or trivial examples, but it doesn't scale", but yet i have developed large, complex applications with visual programming environments. you know why? because i treat it as real software. i modularize. i take data abstraction seriously. i accept the dataflow paradigm as the key paradigm and build things off of that. and that leads me to another point. the dataflow paradigm does not map well to text-based languages at all, but it is a very powerful paradigm. visual programming languages are very good at the dataflow paradigm, and so from that alone, they seem to be required if we are to efficiently program dataflow-based systems.
theoh 8y ago
> this idea that text is not visual is weird. It's worth noting, though, that text is a serial or linear way of encoding information through symbols. In that respect it inherits its structure from spoken language. The significant visual aspect of text is the forms of the glyphs. Typographers definitely do interesting visual things with text, but this hardly ever happens in programming language syntax. On a similar note, I get annoyed when Eugenia Cheng claims that the diagrams of category theory are "visual"[1]. They are graphs of nodes and edges, which means that they convey topological information, i.e. they are not images of anything in particular. Category theorists deliberately use only a tiny, restricted set of the possibilities of drawing diagrams. If you try to get a visual artist or designer interested in the diagrams in a category theory book, they are almost certain to tell you that nothing "visual" worth mentioning is happening in those figures. Visual culture is distinguished by its richness on expressive dimensions that text and category theory diagrams just don't have. [1] "Visual representation has always been a strong component of my work in category theory, which is a very visually driven subject: we turn abstract ideas into diagrams and pictures, and then take those pictures seriously and reason with them."
- the_af 8y ago
  > Visual culture is distinguished by its richness on expressive dimensions that text and category theory diagrams just don't have. I think I understand what you mean, but I'd say this unbounded "richness" is precisely what you must avoid in a programming language. In a programming language you want constraints, not freedom. Your visual language must convey specific, unambiguous information and not be open to interpretation or confusion. A program is inherently closer to a formula than to art. As a complete and irrelevant aside: I wouldn't assume visual artists will consider category theory diagrams artistically uninteresting. Artists are an unpredictable bunch, capable of finding beauty in the most unlikely things ;)
  - theoh 8y ago
    I'm an artist myself, so I said "almost certainly" to qualify what I believe is an almost universal opinion. I don't think category theory diagrams on the wall of a gallery would fly as visual art, though I can imagine an artist (of a more conceptual variety) referencing category theory. I'm not saying there's no possible intersection between category theory and art—just that whatever that intersection is, it's not really about the visual, because we know how constrained the language and appearance of the diagrams is. Name-dropping category theory via including a diagram in artistic work doesn't mean that the diagram itself is visually relevant. It would essentially be functioning as a sign rather than an image. (Feynman diagrams are a totally different story.) As far as richness goes: I don't think programming languages have to be austere. "Richness" might be a divisive term to use for it. I just mean high degree of expressiveness. Also, I guess, a high degree of elaboration. A rich type system is not necessarily a dangerously self-indulgent, inconsistent, dangerous one—it might instead be the end result of a rigorous process of elaboration according to strict criteria.

ghostwriter 8y ago

> Maybe we should spend a few thousand years coming up with a compact, information-dense manner of expressing thoughts. This is called "mathematical notation".

lenticular 8y ago
I wonder if something along the lines of commutative diagrams would be ideal.
Retra 8y ago
It's called "writing", and mathematical notation is just a subset of that.

m_mueller 8y ago

while text is 2D, together with rich formatting options, program code is only 1D. have a look at the 'subtext' programming language concept that combines tables and graphs together with text based procedures, finally getting away from the constraints of program code that is designed around teletypes. https://en.wikipedia.org/wiki/Subtext_(programming_language) https://en.wikipedia.org/wiki/Subtext_(programming_language)

taeric 8y ago
This seems wrong. A view of your program is 1d. Conceptualizing a program is often n-dimensional. This is a large part of the difficulty. And is why some visualizations work. They effectively act as dimensional reductions, and draw on known visual metaphors.
- uryga 8y ago
  > A view of your program is 1d. Conceptualizing a program is often n-dimensional. that sounds like a cool way of seeing things, could you explain what dimensions you're referring to?
  - taeric 8y ago
    Depends on the program. Anything you use to "index" into data is effectively a dimension. This is obvious with arrays, since you can have multidimensional arrays. However, even structs can just be seen as arrays with symbolic indexes. Usually bound by a given cardinality. That make sense?
    - uryga 8y ago
      yeah, thanks!
- m_mueller 8y ago
  That was exactly the point I was trying to make. If you have a 2D problem and you want to represent it in today's commonly used code you either 1) flatten it down to 1D (e.g. a table becomes a JSON array of objects) 2) move it into a higher dimensional structure like a database. Now you have two problems. If your programming paradigm supports higher dimensions to tackle your problems, it just gives you a higher level platform to start tackling your problems. Before you could maybe deal with 4 dimensions at the same time at most, now you can deal with up to 5 or even 6 - we don't yet know what new solutions to problems smart people could come up with when being given such tools. Just as an example, how often do you see binary logic problems in the form of complex if-then-else procedural structures - what if you could represent two decision factors in a tabular form and let the IDE work out the missing cases for you? That's one of the ideas behind subtext. Point is I think we agree - if you think I'm fundamentally wrong I'd like to know more exactly where.
  - taeric 8y ago
    I guess I just don't agree that those are your only two options. Consider, a nested JSON structure is essentially N-dimensional. Even something as simple as a list of people is effectively multidimensional. You have the dimension of the list, and then you have the dimension of the the structure representing the people. Which, itself, my have multiple dimensions. Consider, a large part of the literature of machine learning is talking about taking a hypercubes and consequences of most distance/volume measures. (Quickly searching, https://datascience.stackexchange.com/questions/27388/what-does-it-mean-when-we-say-most-of-the-points-in-a-hypercube-are-at-the-bound https://datascience.stackexchange.com/questions/27388/what-d... talks about this.)
nikki93 8y ago
Code is always written with "indentation" and other things that demonstrate that the 2d canvas distribution of the glyphs you're expressing actually does matter for the human element. You're almost writing ASCII art. The ( ) and [ ] are even in there to evoke other visual types. It's ultimately 1D for the computer (a string); but so is an image (which according to you would encode 2D media) and any other media expressible in a countable number of bytes.

coldtea 8y ago

>this idea that text is not visual is weird. Everything we can see is visual in that regard. That's what not "visual" in visual programming (or visual diagram etc) means.

nikofeyn 8y ago

i sure there is probably a term for this type of argument, but this seems hopelessly dismissive on the basis of some pedantic definition of visual in this context. visual programming basically already means non-textual programming. it is about searching for new syntax and paradigms of programming that break out of the idea that one needs to inform the computer with a series of lines of text. text-based programming was born out of convenience and heavily influenced by the underlying implementations. it isn't the result of any detailed study or investigation of how to best represent ideas and concepts or how to properly describe a computation.

mimixco 8y ago
That's not really accurate. Visual programming systems have been around for a long time and there have been many studies of programmer productivity in various languages. Those studies have shown that programmers prefer (and perform better with) the languages where they have to type the least. Dragging things around the screen or filing-in dialog boxes (property programming) is appealing to non-programmers but, in practice, seasoned developers nearly always choose text. Visual programming hasn't taken off because it isn't as good as text for the majority of use cases. This is borne out by more than 50 years of people writing computer programs.
- nikofeyn 8y ago
  what isn't accurate? there has been extremely little research done in the way of visual programming in comparison to text-based programming. > Visual programming hasn't taken off because it isn't as good as text for the majority of use cases. This is borne out by more than 50 years of people writing computer programs. ...writing computer programs with text. this bias is massive because nearly no one writes visual programs. a lot of that is due to availability of visual environments, some of which are quite expensive (e.g., labview). most of it is due to bias. if every single computer science and computer engineering major starts of their education with being taught "this (i.e., text) is how you program and interact with computers" then that sets up a massive bias that is nigh impossible to overcome. any study that does not address this bias is flawed. hence, we have people, who have never even programmed in a visual language, proclaiming visual programming doesn't work. i constantly hear text-based programmers say "oh, visual programming is good for niche things or trivial examples, but it doesn't scale", but yet i have developed large, complex applications with visual programming environments. you know why? because i treat it as real software. i modularize. i take data abstraction seriously. i accept the dataflow paradigm as the key paradigm and build things off of that. and that leads me to another point. the dataflow paradigm does not map well to text-based languages at all, but it is a very powerful paradigm. visual programming languages are very good at the dataflow paradigm, and so from that alone, they seem to be required if we are to efficiently program dataflow-based systems.

theoh 8y ago

> this idea that text is not visual is weird. It's worth noting, though, that text is a serial or linear way of encoding information through symbols. In that respect it inherits its structure from spoken language. The significant visual aspect of text is the forms of the glyphs. Typographers definitely do interesting visual things with text, but this hardly ever happens in programming language syntax. On a similar note, I get annoyed when Eugenia Cheng claims that the diagrams of category theory are "visual"[1]. They are graphs of nodes and edges, which means that they convey topological information, i.e. they are not images of anything in particular. Category theorists deliberately use only a tiny, restricted set of the possibilities of drawing diagrams. If you try to get a visual artist or designer interested in the diagrams in a category theory book, they are almost certain to tell you that nothing "visual" worth mentioning is happening in those figures. Visual culture is distinguished by its richness on expressive dimensions that text and category theory diagrams just don't have. [1] "Visual representation has always been a strong component of my work in category theory, which is a very visually driven subject: we turn abstract ideas into diagrams and pictures, and then take those pictures seriously and reason with them."

the_af 8y ago
> Visual culture is distinguished by its richness on expressive dimensions that text and category theory diagrams just don't have. I think I understand what you mean, but I'd say this unbounded "richness" is precisely what you must avoid in a programming language. In a programming language you want constraints, not freedom. Your visual language must convey specific, unambiguous information and not be open to interpretation or confusion. A program is inherently closer to a formula than to art. As a complete and irrelevant aside: I wouldn't assume visual artists will consider category theory diagrams artistically uninteresting. Artists are an unpredictable bunch, capable of finding beauty in the most unlikely things ;)
- theoh 8y ago
  I'm an artist myself, so I said "almost certainly" to qualify what I believe is an almost universal opinion. I don't think category theory diagrams on the wall of a gallery would fly as visual art, though I can imagine an artist (of a more conceptual variety) referencing category theory. I'm not saying there's no possible intersection between category theory and art—just that whatever that intersection is, it's not really about the visual, because we know how constrained the language and appearance of the diagrams is. Name-dropping category theory via including a diagram in artistic work doesn't mean that the diagram itself is visually relevant. It would essentially be functioning as a sign rather than an image. (Feynman diagrams are a totally different story.) As far as richness goes: I don't think programming languages have to be austere. "Richness" might be a divisive term to use for it. I just mean high degree of expressiveness. Also, I guess, a high degree of elaboration. A rich type system is not necessarily a dangerously self-indulgent, inconsistent, dangerous one—it might instead be the end result of a rigorous process of elaboration according to strict criteria.