It's overly simplified to the point of being meaningless. A .js file is a document that presents information to me when I open it using a text editor. So is a .html file, for that matter. Something different happens when they're opened in a browser and, for that reason, they both seem to be programs as well.
you can ignore the fact that they look like text. look past that
program and document just are different things. (I gave a simplified definition). if they both are represented using text when creating, it doesn't make them the same. because some text is a programming language and can create program, and some text use markup language and can create document.
it's like humans and worms are carbon life, if you only look at that you can't tell difference between humans and worms. you need to look what kinds of cells are in them or even better what they do
It seems like you want to intentionally not understand this?
> It seems like you want to intentionally not understand this?
It seems like you are offering a poor response to a difference of opinion.
> if they both are represented using text when creating, it doesn't make them the same.
I think you misunderstood my point. You gave definitions that were overly simplistic, thinking they were accurate. I was just pointing out how inaccurate it is to say "program does thing. document presents info." Rather, more accurately, I'm pointing out that a file being one thing does not preclude it from being another (seeing as I generally agree that programs do things and documents present information).
You are taking the position that a document and a program are mutually exclusive and that's just not true. HTML files are executed as programs by a browser and displayed as a document by a text editor. JS files, too. I could go on. Of course, this opinion is not borne from willful ignorance of your opinion, but instead from my understanding of English.
> it's like humans and worms are carbon life, if you only look at that you can't tell difference between humans and worms. you need to look what kinds of cells are in them or even better what they do
You're arguing my point for me, with this paragraph. In the given analogy, "carbon life" is analogous to "program":
It's like, HTML and JS files are programs. If you can't tell the difference between HTML and JS files, you need to look at what text is in them or, even better, what they do.
Yes, thanks. That's pretty much what I'm saying. HTML and JS files are programs, much like how worms and humans are carbon-based organisms. They're otherwise wildly different and do different things. That genuinely seems obvious (to me) with no room for controversy. I'm not sure what reason there is for disagreement.
> HTML files are executed as programs by a browser and displayed as a document by a text editor. JS files, too. I could go on
This reveals fundamental misunderstanding what is HTML and JS. "program" being different from "document" doesn't preclude some documents to have embedded programs within. however it doesn't turn a document into a program and doesn't mean markup language becomes programming language. there is still clear separation between hypertext markup and executable JS code
You write your comment as though I'm suggesting the HTML file is executed because it contains a script element. I'm not; an HTML file with no script tag, say just the text "Hello world!"[0], is executed by a browser as a program. Because if that HTML file instead contained something like <select><option>Hello world!</option></select>, it would know to render some kind of list to choose from.
If I put that HTML inside of a <form> element, I could even get it to send the selections to a server of my choosing using the "action" attribute on said form (I may need to further instruct the browser to render a <button> or <input type="submit> inside the form or do some other fancy shenanigans). Put more useful options in the select and maybe some other input elements with some useful <label> elements and I might just have myself a graphical interface which people can use to submit information to me. But that's not right because it's just "present[ing] info", which just happens to be useful labels and inputs to in a form that will send the user-provided information to an external program; just a regular document, nothing special or "instructive" or "do[ing] things" about it. I hope I'm not laying it on too thick.
Seriously, though, if I didn't just describe a program that's executed by a browser then we have such fundamentally different ideas of what a "program" is that I might as well just concede that you're right, by whatever definition of the word you must be using.
[0] Every "Hello world!" program tutorial, which only instructs how to print that text to the screen before exiting, in every programming language ever is generally (and, IMO, reasonably) claimed to be a program, however rudimentary.
> it would know to render some kind of list to choose from.
but this is not executing a program. this interpreting markup to render some data in some format. HTML is the same programming language as XML or Markdown or JPG or MIDI or WAV... so, not really a programming language. it's input for a program written using some programming language
sometimes presenting data and programming are conflated, for example postscript, but this is not HTML
> Put more useful options in the select and maybe some other input elements with some useful <label> elements and I might just have myself a graphical interface which people can use to submit information to me. But
Handling form submissions, handling displaying select boxes etc, is all result of executing program that is browser itself. The input for that program is hypertext markup by webmaster.
(Running embedded JS however is executing a program by webmaster.)
I think trying to present markup as programming is very artificial and does not correspond to real world.
> but this is not executing a program. this interpreting markup to render some data in some format.
Yes, it's interpreting markup to render some data in some format but that does not preclude such interpretation from being the execution of a program.
> sometimes presenting data and programming are conflated
My point is that executing a program is not mutually exclusive with presenting data. I am not conflating these terms but rather the opposite; I am pointing out that they are separate concepts which do not necessarily conflict with each other.
> Handling form submissions, handling displaying select boxes etc, is all result of executing program that is browser itself. The input for that program is hypertext markup
Right, that "hypertext markup" is a program for the browser (another program) to execute. That seems like an accurate use of English. If this is where we draw the line then JS must not be a programming language because it's just some kind of "script text" that is the input for some other real program.
> Running embedded JS however is executing a program by webmaster.
I understand this is your perspective but you haven't drawn a clear line separating this from the execution of an HTML program. Running plain HTML in a browser, consisting strictly of the necessary components of a valid HTML document, is also executing a program (webmaster isn't necessary).
program does things. document presents info.