The bar for me is whether the language describes an executable program that has state and control flow.
You could perhaps be generous and describe the DOM as a (write-only) state and the parser as a control flow. I don’t, personally.
HTML is just a data container format to me. Belongs with the likes of XML, JSON, JPG, PNG, GIF, MP3, MOV, etc.
The umbrella term I’d use for all of these is “coding”. That’s the skill of understanding structured languages and format specifications, and understanding how you can and can’t piece things together to make something coherent. This is a critical requisite skill to programming. But programming is more.
Programming is the art of juggling of state and control flow in clever ways to trick funny rocks into computing something you don’t know. It doesn’t need to be general purpose, but I would argue it indeed needs to have a purpose. It has to be something more than just a pile of declarations you know from the outset. Otherwise it’s just structured data.
The umbrella term I’d use for all of these is “coding”.
Saying “it’s not programming it’s coding” is like engineer “it’s not dirt it’s soil” levels of pedantry that are silly to expect people outside your profession to know.
Sure. Which is why I would only make this distinction in a place where I can reasonably expect people to know better. Like, perhaps, a niche community on an experimental social media platform dedicated to programming.
Stateless functions still deal with state, they just don’t hold onto it. Without state to mutate, a so-called stateless function doesn’t do anything.
In declarative languages, your state is the sum of everything you’ve declared. You don’t query results out of thin air. Computational results logically conclude from everything you set up.
HTML ““has state””, as in it has a DOM, but it doesn’t do anything with it. You don’t mutate the DOM after it’s built, or query the DOM to compute results that weren’t trivially evident from the state you declared.
You can do those things with JavaScript. But all that proves is JavaScript is a programming language, and HTML is just a data format it can interact with.
Programming is the art of juggling of state and control flow
Sure, stateless functions deal with and impact state in some way. If that’s what you meant by your previous comment, that’s fine, but that’s honestly not what would typically be meant by “juggling” state.
The part about declarative languages has nothing to do with state. Declarative languages do not give the programmer control over flow, the other part of your definition.
Learn Lisp, and you will never again be so certain about the difference between a programming language and a data format.
No, my question does not imply a pure functional language at all. Pure functions exist in languages which are not purely functional. Most of the functions I write are pure functions. I could have a workflow where I work with another programmer who handles the minimal stateful pieces, and I would only write stateless functions - would that make me not a programmer?
(There are also purely functional languages, by the way. I just didn’t remotely imply there were, or make any claims about them, at any point in this thread, prior to this parenthetical.)
The part about declarative languages has nothing to do with state, or functional languages. Declarative languages are a whole different thing. Of course declarative languages handle state. The comment I was replying to said “Programming is the art of juggling of state and control flow”. Declarative languages don’t involve juggling control flow.
The bar for me is whether the language describes an executable program that has state and control flow.
You could perhaps be generous and describe the DOM as a (write-only) state and the parser as a control flow. I don’t, personally.
HTML is just a data container format to me. Belongs with the likes of XML, JSON, JPG, PNG, GIF, MP3, MOV, etc.
The umbrella term I’d use for all of these is “coding”. That’s the skill of understanding structured languages and format specifications, and understanding how you can and can’t piece things together to make something coherent. This is a critical requisite skill to programming. But programming is more.
Programming is the art of juggling of state and control flow in clever ways to trick funny rocks into computing something you don’t know. It doesn’t need to be general purpose, but I would argue it indeed needs to have a purpose. It has to be something more than just a pile of declarations you know from the outset. Otherwise it’s just structured data.
Saying “it’s not programming it’s coding” is like engineer “it’s not dirt it’s soil” levels of pedantry that are silly to expect people outside your profession to know.
Hey, maybe you are engineers after all lol
Sure. Which is why I would only make this distinction in a place where I can reasonably expect people to know better. Like, perhaps, a niche community on an experimental social media platform dedicated to programming.
That’d be nice, but it’s obvious who is and isn’t a programmer in this one.
So, writing stateless functions, or working in declarative languages doesn’t count?
Stateless functions still deal with state, they just don’t hold onto it. Without state to mutate, a so-called stateless function doesn’t do anything.
In declarative languages, your state is the sum of everything you’ve declared. You don’t query results out of thin air. Computational results logically conclude from everything you set up.
HTML ““has state””, as in it has a DOM, but it doesn’t do anything with it. You don’t mutate the DOM after it’s built, or query the DOM to compute results that weren’t trivially evident from the state you declared.
You can do those things with JavaScript. But all that proves is JavaScript is a programming language, and HTML is just a data format it can interact with.
Sure, stateless functions deal with and impact state in some way. If that’s what you meant by your previous comment, that’s fine, but that’s honestly not what would typically be meant by “juggling” state.
The part about declarative languages has nothing to do with state. Declarative languages do not give the programmer control over flow, the other part of your definition.
Learn Lisp, and you will never again be so certain about the difference between a programming language and a data format.
There’s no such thing as a pure functional language. All it would accomplish is warming the CPU up. All such languages store data away at some point.
I didn’t say there is…
Your statement implies it. Having stateless or declarative functions that never store or retrieve data would mean they are pure functions.
No, my question does not imply a pure functional language at all. Pure functions exist in languages which are not purely functional. Most of the functions I write are pure functions. I could have a workflow where I work with another programmer who handles the minimal stateful pieces, and I would only write stateless functions - would that make me not a programmer?
(There are also purely functional languages, by the way. I just didn’t remotely imply there were, or make any claims about them, at any point in this thread, prior to this parenthetical.)
The part about declarative languages has nothing to do with state, or functional languages. Declarative languages are a whole different thing. Of course declarative languages handle state. The comment I was replying to said “Programming is the art of juggling of state and control flow”. Declarative languages don’t involve juggling control flow.