79 ms·

> Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who m

> Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the von Neumann execution of the program, or whatever else? These models are incidental. The thing that matters is whatever humans read and interpret and mentally model. And for the moment that's source code.

dleslie 4y ago
Indeed, in a way the author is saying that the meaning is independent of the text; which, in literary circles, was once hotly debated. I land on the textual side of the line; the medium is as important to the meaning as the abstract concepts that might be components of it. Multiple tellings of the same story carry different meaning, sometimes subtly, when they are each one of oral, text, photo, painting, or film. I believe the same is true of programming. A solution in C is fundamentally distinct from a solution in ladder logic, or Haskell; even if they solve the same problem.
cultofmetatron 4y ago
to add to that, this programming is a model is how we got smalltalk. a collection of interesting ideas from which its peripheral ideas got pillaged into other languages while leaving the core idea to just smalltalk.
ablob 4y ago
How is it harmful? > A program is whatever the human beings who maintain that program operate against This does neither invalidate the statement that "Program is not a text", nor that "[it is] a model". > And for the moment that's source code. How is wanting to change that harmful? Source code can have flaws like ambiguity (see C++'s need for typename). Deeming a call for improvement on the existing representation of a program harmful is a fine way to stop any progress at all. We would still be putting in raw numbers into memory with that attitude. On another note: I think what matters is what the computer actually does. Whatever I, as a human, read and interpret has no meaning at all if the computer decides to "read and interpret" it differently. And the only limit with representing what the computer actually does should be your imagination.
- preseinger 4y ago
  > I think what matters is what the computer actually does. Whatever I, as a human, read and interpret has no meaning at all if the computer decides to "read and interpret" it differently. And the only limit with representing what the computer actually does should be your imagination. Well, I understand this perspective, but I judge it to be backwards. The computer should be understood as secondary to the human. Mechanical sympathy is necessary for useful software but the goal of software must not be mechanical.
hzhou321 4y ago
Yes, I agree! In fact, the break through we needed is to view programming as a human cognitive operation and embrace the text, and treat manipulating text as a main component of coding. For example, I want to code foreach item in list_A do_something(item) This text is the native code in the programmer's mind, and we should allow programmer to just do so. Then, in a second layer, the programmer should code up the transformer and translate that to the actual programming language, adding incidental complexity such as specific syntax and internal language representations, so that the lower level compiler can verify and consume and feedback. The transformer part is super hard if we rely on automatic tools, which is just another version of a compiler. It is super tedious if we rely on human manual work, which is just how today programmers do. But if we view the transformer part as part of programming, where programmer employs tools to mold their program, then it makes sense. The programmer will be able to program the tools to avoid the tedious part but still with full flexibility to mold anyway they desire. It is still programming, but in a meta frame where text is the target.
- hzhou321 4y ago
  For those who are interested, checkout MyDef - https://github.com/hzhou/MyDef https://github.com/hzhou/MyDef
- preseinger 4y ago
  Agreed. Programs are not equations, they're recipes.
david927 4y ago
I couldn't disagree more. You don't buy a drill, you buy a way to get a hole in, say, wood. That's the core product. The core product of 'programming' is a software solution. So far, the best way to approach it is text. But... text is an incredibly poor model! It's almost literally an accounting system of "Jake spent fifty dollars." It's text which is "actively harmful," and we see it all around us in the absence of maintainable systems. Yes, currently, it's the best way we've found; just as horse and buggy was the best current form of travel 150 years ago. But it takes very little imagination to expect we'll find better.
- preseinger 4y ago
  Programs are ideas that need to be understood, modeled, and manipulated by humans. Text is the best available way to incept ideas into the minds of humans.
  - glass_of_water 4y ago
    If that were true, text books wouldn't contain any diagrams. So I think it's fairly uncontroversial to say that there are cases when text is not the best way to incept ideas. So why should we be confined to just text when writing code? Should we not be free to choose the best tool for the job?
    - dotopotoro 4y ago
      You should check out IDEs :) IDE takes plain old text as input, and lets the coder to interact with the model of the program. 1. Various graphical hints in text (highlighting keywords, selections, …) 2. Visualisation tools (draw database and class diagrams) 3. Navigation capabilities (go to implementation, definition etc) 4. Refactoring capabilities (“rename, “extract variable”, …) In my view, IDE is already “book with diagrams”. (“Diagrams” can still be improved, but concept is really there)
      - panstromek 4y ago
        True, but IDEs are currently severely limited by nature of textual sources (e.g. macros are notoriously tricky to deal with). It's much easier to start from a good model for IDE and derive textual reprentation and input method from that.
unixbane 4y ago
Programming is an exercise in manipulating semantic objects which is why stuff like blueprints in unreal engine are so easy to use. It will just get better and text will become an obsolete vestige, regardless of whatever idea you have of this being "harmful". I really don't think a character encoding with 30 ways to control the terminal (and now extended to encode emojis) is the be all end all way of writing and editing programs. Consider that if text had an advantage, it would be that you could cut some string in half as some sort of manipulation that saves time. What do I cut in half? Change >= to = ? There's basically no advantage of text. I don't want half of an if statement, that's what text allows me to do, it's a pointless feature that makes inputting programs harder. The basic element on the screen should be the if statement itself. There is no advantage to a 1D language. Text is a 1D language. If you have if (x) { if (y) { } } You are just reading it as a 2D language, but it's not. It could be if (x) { if (y) { }} } and mean something else. (Yes I'm sure you can catch this one, but not all in general). The only way to be sure is read it from start until end, which nobody does. This is a security issue too, which I discovered when I was 12 years old reading perl scripts from milworm. By formatting text you are already conceding that 2D is better.
- thrown_22 4y ago
  So what happens when you have a 10 deep nested if tree? Your answer would be to not do it because it doesn't fit nicely in a 2d page. My answer would be to put it in a 1d line and not bake semantics into presentation. But you can't pretend that the space of programs isn't infinite dimensional when the space we work in is only 3d. Regardless of how clever you are using a medium with a dimensionality higher than 1 for semantics will always result in expressions you can't express. This is why we've stuck with text. It's 1d, but we can make it 2d to help understand what is going on visually in the simple cases humans can understand intuitively. Yet it is complex enough to represent any possible object.
  - unixbane 4y ago
    Just switch back and forth between box representation and graph. It's still far better than text. Text fails far faster. Have you ever used IDA? It shows a graph view of assembly based on jump flow instead of a linear assembly listing. Of course you can't magically understand all programs just with a simple algorithm to format them a certain way, but it's still immediately obvious that this is better. Most code is immediately understandable just using a C#/Java decompiler or gofmt without the programmer needing to format it. I just see variable names and formatting as spam and red herrings. Anyway you can't audit code by taking the programmer's word that he formatted it a certain way, so this whole "text for writing a poem of comprehension" idea is moot and outdated at least 30 years ago anyway.
samatman 4y ago
That's a tenable way to view a program until you hit a compiler bug. Mostly, you don't hit a compiler bug. When you think you've hit a compiler bug, it's not a compiler bug. There's an easy workaround: write a compiler. It will have bugs. There are other non-trivial ways that a program isn't its source, but in fact, systems which treat the source code as the ground truth are an important foundation. Many Smalltalk users would paint themselves into a corner by modifying an image to the point where there was no way to restart it, because its important properties were no longer captured in source code.
- igouy 4y ago
  > Many Smalltalk users would paint themselves into a corner by… ?! Most Smalltalk users were transitioning enterprise systems from green screen terminals to guis. > … no way to restart it… It's important properties were captured in the .changes log file — so workable modifications can be made again in a new image. https://eng.libretexts.org/Bookshelves/Computer_Science/Programming_Languages/Book%3A_Pharo_by_Example_5.0_(Ducasse_Zagidulin_Hess_and_Chloupis)/08%3A_Sharing_Code_and_Source_Control/8.04%3A_In_Pharo_You_Cant_Lose_Code https://eng.libretexts.org/Bookshelves/Computer_Science/Prog...

dleslie 4y ago

Indeed, in a way the author is saying that the meaning is independent of the text; which, in literary circles, was once hotly debated. I land on the textual side of the line; the medium is as important to the meaning as the abstract concepts that might be components of it. Multiple tellings of the same story carry different meaning, sometimes subtly, when they are each one of oral, text, photo, painting, or film. I believe the same is true of programming. A solution in C is fundamentally distinct from a solution in ladder logic, or Haskell; even if they solve the same problem.

cultofmetatron 4y ago

to add to that, this programming is a model is how we got smalltalk. a collection of interesting ideas from which its peripheral ideas got pillaged into other languages while leaving the core idea to just smalltalk.

ablob 4y ago

How is it harmful? > A program is whatever the human beings who maintain that program operate against This does neither invalidate the statement that "Program is not a text", nor that "[it is] a model". > And for the moment that's source code. How is wanting to change that harmful? Source code can have flaws like ambiguity (see C++'s need for typename). Deeming a call for improvement on the existing representation of a program harmful is a fine way to stop any progress at all. We would still be putting in raw numbers into memory with that attitude. On another note: I think what matters is what the computer actually does. Whatever I, as a human, read and interpret has no meaning at all if the computer decides to "read and interpret" it differently. And the only limit with representing what the computer actually does should be your imagination.

preseinger 4y ago
> I think what matters is what the computer actually does. Whatever I, as a human, read and interpret has no meaning at all if the computer decides to "read and interpret" it differently. And the only limit with representing what the computer actually does should be your imagination. Well, I understand this perspective, but I judge it to be backwards. The computer should be understood as secondary to the human. Mechanical sympathy is necessary for useful software but the goal of software must not be mechanical.

hzhou321 4y ago

Yes, I agree! In fact, the break through we needed is to view programming as a human cognitive operation and embrace the text, and treat manipulating text as a main component of coding. For example, I want to code foreach item in list_A do_something(item) This text is the native code in the programmer's mind, and we should allow programmer to just do so. Then, in a second layer, the programmer should code up the transformer and translate that to the actual programming language, adding incidental complexity such as specific syntax and internal language representations, so that the lower level compiler can verify and consume and feedback. The transformer part is super hard if we rely on automatic tools, which is just another version of a compiler. It is super tedious if we rely on human manual work, which is just how today programmers do. But if we view the transformer part as part of programming, where programmer employs tools to mold their program, then it makes sense. The programmer will be able to program the tools to avoid the tedious part but still with full flexibility to mold anyway they desire. It is still programming, but in a meta frame where text is the target.

hzhou321 4y ago
For those who are interested, checkout MyDef - https://github.com/hzhou/MyDef https://github.com/hzhou/MyDef
preseinger 4y ago
Agreed. Programs are not equations, they're recipes.

david927 4y ago

I couldn't disagree more. You don't buy a drill, you buy a way to get a hole in, say, wood. That's the core product. The core product of 'programming' is a software solution. So far, the best way to approach it is text. But... text is an incredibly poor model! It's almost literally an accounting system of "Jake spent fifty dollars." It's text which is "actively harmful," and we see it all around us in the absence of maintainable systems. Yes, currently, it's the best way we've found; just as horse and buggy was the best current form of travel 150 years ago. But it takes very little imagination to expect we'll find better.

preseinger 4y ago
Programs are ideas that need to be understood, modeled, and manipulated by humans. Text is the best available way to incept ideas into the minds of humans.
- glass_of_water 4y ago
  If that were true, text books wouldn't contain any diagrams. So I think it's fairly uncontroversial to say that there are cases when text is not the best way to incept ideas. So why should we be confined to just text when writing code? Should we not be free to choose the best tool for the job?
  - dotopotoro 4y ago
    You should check out IDEs :) IDE takes plain old text as input, and lets the coder to interact with the model of the program. 1. Various graphical hints in text (highlighting keywords, selections, …) 2. Visualisation tools (draw database and class diagrams) 3. Navigation capabilities (go to implementation, definition etc) 4. Refactoring capabilities (“rename, “extract variable”, …) In my view, IDE is already “book with diagrams”. (“Diagrams” can still be improved, but concept is really there)
    - panstromek 4y ago
      True, but IDEs are currently severely limited by nature of textual sources (e.g. macros are notoriously tricky to deal with). It's much easier to start from a good model for IDE and derive textual reprentation and input method from that.

unixbane 4y ago

Programming is an exercise in manipulating semantic objects which is why stuff like blueprints in unreal engine are so easy to use. It will just get better and text will become an obsolete vestige, regardless of whatever idea you have of this being "harmful". I really don't think a character encoding with 30 ways to control the terminal (and now extended to encode emojis) is the be all end all way of writing and editing programs. Consider that if text had an advantage, it would be that you could cut some string in half as some sort of manipulation that saves time. What do I cut in half? Change >= to = ? There's basically no advantage of text. I don't want half of an if statement, that's what text allows me to do, it's a pointless feature that makes inputting programs harder. The basic element on the screen should be the if statement itself. There is no advantage to a 1D language. Text is a 1D language. If you have if (x) { if (y) { } } You are just reading it as a 2D language, but it's not. It could be if (x) { if (y) { }} } and mean something else. (Yes I'm sure you can catch this one, but not all in general). The only way to be sure is read it from start until end, which nobody does. This is a security issue too, which I discovered when I was 12 years old reading perl scripts from milworm. By formatting text you are already conceding that 2D is better.

thrown_22 4y ago
So what happens when you have a 10 deep nested if tree? Your answer would be to not do it because it doesn't fit nicely in a 2d page. My answer would be to put it in a 1d line and not bake semantics into presentation. But you can't pretend that the space of programs isn't infinite dimensional when the space we work in is only 3d. Regardless of how clever you are using a medium with a dimensionality higher than 1 for semantics will always result in expressions you can't express. This is why we've stuck with text. It's 1d, but we can make it 2d to help understand what is going on visually in the simple cases humans can understand intuitively. Yet it is complex enough to represent any possible object.
- unixbane 4y ago
  Just switch back and forth between box representation and graph. It's still far better than text. Text fails far faster. Have you ever used IDA? It shows a graph view of assembly based on jump flow instead of a linear assembly listing. Of course you can't magically understand all programs just with a simple algorithm to format them a certain way, but it's still immediately obvious that this is better. Most code is immediately understandable just using a C#/Java decompiler or gofmt without the programmer needing to format it. I just see variable names and formatting as spam and red herrings. Anyway you can't audit code by taking the programmer's word that he formatted it a certain way, so this whole "text for writing a poem of comprehension" idea is moot and outdated at least 30 years ago anyway.

samatman 4y ago

That's a tenable way to view a program until you hit a compiler bug. Mostly, you don't hit a compiler bug. When you think you've hit a compiler bug, it's not a compiler bug. There's an easy workaround: write a compiler. It will have bugs. There are other non-trivial ways that a program isn't its source, but in fact, systems which treat the source code as the ground truth are an important foundation. Many Smalltalk users would paint themselves into a corner by modifying an image to the point where there was no way to restart it, because its important properties were no longer captured in source code.

igouy 4y ago
> Many Smalltalk users would paint themselves into a corner by… ?! Most Smalltalk users were transitioning enterprise systems from green screen terminals to guis. > … no way to restart it… It's important properties were captured in the .changes log file — so workable modifications can be made again in a new image. https://eng.libretexts.org/Bookshelves/Computer_Science/Programming_Languages/Book%3A_Pharo_by_Example_5.0_(Ducasse_Zagidulin_Hess_and_Chloupis)/08%3A_Sharing_Code_and_Source_Control/8.04%3A_In_Pharo_You_Cant_Lose_Code https://eng.libretexts.org/Bookshelves/Computer_Science/Prog...