Talk:State (computer science)

Merge with Program state?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result was merge Program state into this article. -- Chetvorno^TALK 08:53, 31 August 2012 (UTC)

---

Merge with the Program state article? Thoughts? 85.250.203.27 (talk) 09:49, 11 December 2008 (UTC)

I propose to merge State (computer science) and Program state. The reason is that both articles fail to differentiated themselves from each other.

In case you see good reasons to keep the articles separate, then please

1. discuss these reasons here,
2. modify both articles in such a way that precise and different definitions are given,
3. modify both articles in such a way that both articles explicitly mention each other and show the difference between both terms,
4. remove the merge templates from both articles.

Thanks, --Abdull (talk) 10:58, 14 March 2010 (UTC)

• Agree with the merge proposal. --71.214.221.153 (talk) 17:10, 18 April 2010 (UTC)

• Support the merge proposal. I am hopeful that the combined article will be of higher quality than either of the source articles. --Kvng (talk) 15:19, 23 September 2010 (UTC)

• DO NOT Support the merge proposal. There are small but distinct differences, as indicated in the State, last paragraph. States have a much wider application that just n the context of Program States. E.g. information systems or communication protocols also have states. —Preceding unsigned comment added by 57.67.164.37 (talk) 10:19, 20 October 2010 (UTC)
• Comment The Program state article has potential to evolve into a separate article if it is expanded to explain how state is implemented in the virtual machines of programming languages, and how programs make use of it. In its current form, I Support the merge with Program state as a section of the more general State (computer science). Diego Moya (talk) 12:40, 26 December 2010 (UTC)

• Support the merge proposal. This "State( computer science )" article is referenced from many articles, including the comprehensive article at Finite-state machine, and from several article under Web services/SOA/RESTful web services. As such it serves a role as a generalized source of a description of "state" as used in the domain of computer science. As an example, "program state" would be a simple way to describe what state is in this domain. However, a more careful description of program state seems likely to run into problems describing "programs", which then starts repeating stuff from Finite-state machine. I think the current article on program state is not distinct enough to warrent a separate article, and such an article is likely to be only a summary of other articles, which also probably belongs here. If I'm wrong and someone cares enough to write a large and detailed subsection, it can always be split back out. Srjefferys (talk) 21:24, 10 January 2011 (UTC)

• As each program state is a state, but each state is not necessarily a program state, I am against a merge. A final state machine has also states, but is not necessarily part of a program. Sae1962 (talk) 15:16, 18 February 2011 (UTC)
  • No, we're not saying they are the same thing. There are 2 kinds of "states" in computer science: Program state and sequential circuit state, which should both be covered in this article, State (computer science). I support merging Program state into this article. --Chetvorno^TALK 13:50, 25 August 2012 (UTC)

It seems to me that the objections raised by 57.67.164.37 and Sae1962 above have been addressed in the current condition of the State (computer science) article. Unless anyone has any further objections I am going to perform the merger. --Chetvorno^TALK 11:27, 28 August 2012 (UTC)

• Support the merge proposal, though I believe State (computer science) to be the more general and hope Program state is merged into it and not the other way around. 50.53.15.51 (talk) 14:31, 28 August 2012 (UTC)

Yes, merge Program state into State (computer science) --Chetvorno^TALK 14:57, 29 August 2012 (UTC)

Performed merger --Chetvorno^TALK 08:53, 31 August 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Broaden the definition

The present definition of 'state' was taken from a book on the design of digital systems. It is too narrow: it mostly applies when designing systems, hardly when studying existing ones, and it is limited to particular kinds of systems. The term 'state' is applied much more broadly, even in computer science. Rp (talk) 07:33, 16 August 2012 (UTC)

I've rewritten the opening paragraph to address this. Rp (talk) 21:19, 1 March 2017 (UTC)

Improve the explanation?

I want to know about running state and waiting state ,such type of states.

I want to know what the virtues of stateless systems may be, as they are NOT obvious. They appear to be necessitated (?) by asynchronous systems, which begs the question "What are the merits of asynchronous communication"? Maximizing vastly redundant data transmission would appear to be one possible goal, admirably achieved. Until the web, all compuiter systems were stateful (and useful). The web is neither. Can anyone explain why the web is such a "dumb" interface? Was the intention to emulate "dumbest terminal imaginable" functionality, as this is what has occurred? —Preceding unsigned comment added by 61.68.14.137 (talk) 18:32, 3 September 2008 (UTC)

I agree that it would be appropriate to answer these questions in this article:

The discussion of simple states (e.g. 'on' vs. 'off', 'running' vs. 'waiting' vs. 'inactive', etc.) can be used to introduce the subject or give an example. The definition of state given now makes technical sense but doesn't really reflect how we usually think of state, and there is a technical reason for that.

Stateful vs. stateless system descriptions: the point of statelessness is not to eliminate state from the system, but to make the system's behavior (interaction with its environment) independent from hidden state: no side effects, any information that may influence the outcome of an operation must be specified explicitly as input, and any effect must be explicit output. This makes systems easier to design and test, even more so when there is concurrency. However, this article may not be the most suitable one for discussing this at length. Rp (talk) 17:02, 29 September 2014 (UTC)

Yes, there is also the article Stateless protocol which might be appropriate for some of it. I don't mind the additions, but the very important basic concept of state as the stored data set available to a program or logic circuit needs to be clear as the primary definition for nontechnical readers. --Chetvorno^TALK 17:23, 29 September 2014 (UTC)

I wouldn't define state as a stored data set available to a program. A program's state may not be represented by a data set and may not be available to that program or any other program. It's the other way around: a data set available to a program can be used to represent some of the program's state. Rp (talk) 22:00, 25 February 2017 (UTC)

The current definition is supported by 3 sources. Where are your sources that say the current definition is wrong? --Chetvorno^TALK 22:22, 25 February 2017 (UTC)

Good question, but actually, only one source was given, and it does not support the definition that was given, so I have taken the liberty to change the definition, and I moved the citation to the subsequent statement that it does support. Rp (talk) 10:32, 26 February 2017 (UTC)