Talk:Concurrent programming language

Is Java a concurrent programming language?

Since when is Java a concurrent programming language?! Lost Goblin 11:21, 2005 Feb 12 (UTC)

In some sense it is and in some sense it isn't. It is, because it supports a variant of monitors, because it has a build-in notion of threads, and because there the is something called JavaSpaces. It's isn't because it's just an imperative programming language. Koffieyahoo 5 July 2005 06:40 (UTC)

Why?

Why is it the case that with so much research into concurrent programming, none of the ideas have been used practically? Is it just the inertia of existing programming models and languages, or is the some deeper reason?

Latest Changes

I have a number of questions and remarks about the latest changes by CarlHewitt:

I don't why operating systems and networking are there in the first paragraph. We want to write multi-threaded programs that's all.

Concurrent programming involves more than just threads, e.g., SOAP.--Carl Hewitt 21:42, 11 July 2005 (UTC)[reply]

Yes, that's true. But this doesn't justify the mention of operating systems and networking, which are just a means to an end. -- Koffieyahoo 12:30, 15 July 2005 (UTC)[reply]

I don't believe the shared objects that can change in the first paragraph is correct. There don't seem to be any shared objects in case message-passing is used (unless addresses of other machines are counted as shared objects).

Concurrent message passing typically involves communication with shared resources that can change.--Carl Hewitt 21:42, 11 July 2005 (UTC)[reply]

Why has the sentence been removed that C is not a concurrent language, while a statement that java and C# are concurrent languages has been added (which is quite unneccessary as Java and C# are in the list of langauges)? Seems to me at least the statement on C should be added back, as it helps in understanding what is going on.

Java and C# have language constructructs for locking and threads whereas C simply invokes a shared libary.--Carl Hewitt 21:42, 11 July 2005 (UTC)[reply]

You're just stating what I and the sentence said (read the question!). Hence, the sentence was a counterexmaple to the fact that C is a Concurrent programming language. Counterexamples are also useful to get some idea of what the concepts in the article are about. -- Koffieyahoo 12:30, 15 July 2005 (UTC)[reply]

Shared-state is better than shared-memory, as what is shared cannot always be really called memory, like in the case of the Orca programming language or Linda (JavaSpaces). The first has a concept of shared abtract data types, while the second generally uses the concept of a Set in which all kinds of elements can be inserted.

Shared resources include both shared memory and shared objects with changeable state.--Carl Hewitt 21:42, 11 July 2005 (UTC)[reply]

You now referring to the general statement, not the particular case, please try again. -- Koffieyahoo 12:30, 15 July 2005 (UTC)[reply]

Why do Java and C# use both shared state and message passing. I'm not aware of the last. Although at least Java supports some form of RPC. It is not the case that RPC can be identified with message passing.

RPC is indeed a form of message passing.--Carl Hewitt 21:42, 11 July 2005 (UTC)[reply]

No RPC is a mechanism for client-server intercation. It has nothing to do with message passing. -- Koffieyahoo 12:30, 15 July 2005 (UTC)[reply]

Why are the references to Occam and Erlang removed from the message-passing part? They examplify what is going on.

The most common programming language use cases are Java and C#. Maybe put Occam and Erlang in a footnote?--Carl Hewitt 21:42, 11 July 2005 (UTC)[reply]

The nature of Java and C# is also somewhat ambivalent, as Lost Goblin rightfully notices. So just a footnote for Occam and Erlang is not enough. -- Koffieyahoo 12:30, 15 July 2005 (UTC)[reply]

Why is a reference to the Internet added to the message-passing part? The Internet is not a message passing system it's simply a set of protocols for computers to communicate. Of course, a message passing system can be build on top of the Internet. The Internet is simply not a programming language.

Almost all distributed message passing systems (e.g. SOAP) use the Internet.--Carl Hewitt 21:42, 11 July 2005 (UTC)[reply]

That the Internet is used is also completely irrelevant for all these systems. -- Koffieyahoo 12:30, 15 July 2005 (UTC)[reply]

Koffieyahoo 8 July 2005 10:07 (UTC)

I also strongly disagree with CarlHewitt changes, C# and Java can hardly be considered concurrent languages(as has been noted before), if no one else defends the changes I'll revert to the May 20, 2005 version of this page. Lost Goblin 20:25, July 14, 2005 (UTC)

Just what do you think is the purpose of the the locking constructs in C# and Java?--Carl Hewitt 20:45, 14 July 2005 (UTC)[reply]

Hacks around the limitations of the non-concurrent design of those languges. Lost Goblin 23:58, July 15, 2005 (UTC)

These are integral constructs of these programming languages for concurrency. Why do you think that they are hacks?--Carl Hewitt 02:14, 16 July 2005 (UTC)[reply]

Please do not remove java and C#, they are rightfully in the list as they have constructs that facilitate concurrency. However, I do think that Java and C# don't deserve the prominent place they have now, as they were not specifically constructed as concurrent programming languages. -- Koffieyahoo 12:30, 15 July 2005 (UTC)[reply]

I'm only planning to revert to the previous version([1]), which did mention Java(and I don't have anything against adding C# beside it) but that had more emphasys on truly concurrent languages. Lost Goblin 23:58, July 15, 2005 (UTC)

Why don't you propose making changes to the current version instead of reverting the contributions of other people?--Carl Hewitt 02:14, 16 July 2005 (UTC)[reply]

I'm trying to do that by first getting all satisfying to all the above questions and remarks. However, if no one (and you in particular Carl Hewitt) responds, it seems best to me to revert, add C#, and to revamp the text a bit (as the prose in the version that will be reverted to can be better). -- Koffieyahoo 12:57, 19 July 2005 (UTC)[reply]

I also think that reverting is the most practical solution, then we can work from that point doing changes that are less 'controversial' and more generally accepted. Lost Goblin 08:23, July 20, 2005 (UTC)

What do you mean by "generally accepted". Just what beliefs do you believe are generally accepted and by whom? It generally doesn't work well to revert the contributions of other people to a long ago version. Editing is the Wikipedia way forward to incorporating the contributions of others.--Carl Hewitt 15:44, 20 July 2005 (UTC)[reply]

It would help if you would would motivate your changes by seriously replying to my questions and remarks above. -- Koffieyahoo 07:14, 21 July 2005 (UTC)[reply]

I think the current article is of /low/ quality and it would be better to spend time on improving it rather than disputing suitability of reverts. A novice reading the article wont learn anything about concurrent programming, how it is different from other styles and what it is good for. Pavel Vozenilek 18:40, 20 July 2005 (UTC)[reply]

Before we start rushing into anything we might want to consider how any change made here relates to the Message passing, Parallel Programming, Parallel computing, Distributed Computing, etc. articles making sure the contents of these articles is consistent. For example: Is Parallel Programming the same as concurrent programming? Are they instances of Distributed computing? Or is there some other relation? -- Koffieyahoo 07:14, 21 July 2005 (UTC)[reply]

Parallel programming is a special case of concurrent programming.--Carl Hewitt 21:22, 21 July 2005 (UTC)[reply]

Concurrency languages

While languages as Java and C# (I know only little about Ada) do support concurency, they are in different league than say Erlang. I think this page should concentrate more on those advanced. Pavel Vozenilek 02:40, 17 July 2005 (UTC)[reply]

Pavel, thanks for your message. However, I don't see what Erlang has to offer in the way of programming language concurrency constructs over Java and C#.--Carl Hewitt 13:38, 17 July 2005 (UTC)[reply]

Erlang provides completely isolated processes as part of language. Communication between the processes is absolutely location transparent. The syntax for using this functionality is very simple and consistent. While it is possible to provide similar services in a conventional language it makes great pain and danger of mistake stays high. Pavel Vozenilek

This may be a valuable feature. However, does Erlang actually add any concurrent programming language constructs?--Carl Hewitt 20:55, 17 July 2005 (UTC)[reply]

It has build-in message passing facilities contrary to Java (and don't start calling RPC message passing again) -- Koffieyahoo 13:17, 19 July 2005 (UTC)[reply]

Part of the language is that parent process is informed automatically about died children. Its the language who ensures isolation between processes (and this is probably the strongest feature). Every process is automatically given unique and un-enforgeable name. Pavel Vozenilek 17:54, 19 July 2005 (UTC)[reply]

What's up with making this page a shrine to C# and Java? Are they really both the One True concurrency language, while Ada, Erlang, etc. are just pale imitations? Ojw 13:57, 9 October 2005 (UTC)[reply]

Unfortunately I don't have the time to fight Carl Hewitt delusions and fix this page properly, if someone does, I would be thankful. I suggest reverting to the version mentioned in another thread and if Hewitt persists we probably should make a Wikipedia:Requests_for_mediation, again, I don't have time to pursue this, but I would be happy if someone else does Lost Goblin 15:15, 9 October 2005 (UTC)[reply]

I would be interesting in knowing the number of C# and Java programmers versus the numbers for Ada, Erlang, etc.;-)--Carl Hewitt 17:41, 9 October 2005 (UTC)[reply]

Asynchronous Concurrent excution

Why do programs need to execute instructions at the same time?

On the proposed merge

It seems a plan to merge Concurrent programming with Concurrent computing, as these articles very much overlap. The same holds for Parallel programming and Parallel computing. However, I do think some more work than this is required to make this in a good set of articles. In particular, I think we should clear up the relations between the following articles (I have ideals about this but they might quite controversial):

So, my view is as follows:

1 and 3 should be merged into one article, as they are basically the same thing. However, section should be devoted explaining that some people disagree with this view and what other view are.
2, 4, 5, and 10 should be merged into one article , as they are again basically the same thing. However, section should be devoted explaining that some people disagree with this view and what other view are.
8 and 9 should be merged, as they are too small to warrent two separate articles.
The relation between 6 and 7 on the one side and the other articles on the other side should be cleared up. One stance is that 6 and 7 work on a global scale, while the others are concerned with thighly coupled systems. However, this disagrees with the theory computer science view of concurrency, which does not invlove any concept of thighly coupledness.

-- Koffieyahoo 08:24, 16 January 2006 (UTC)[reply]

I agree that there is some work that needs to be done to get this set of articles into good shape. Unfortunately, I don't quite agree with your proposals :-) Here are my views:

Merging 8 and 9 (message passing and message passing programming) certainly makes sense to me
I would prefer to see Concurrency remain as a separate article (significantly improved), since it can provide a good head article for both theoretical and practical aspects of the study of concurrency
I don't agree that 1 and 3 are the same thing. Parallel computing involves splitting a single (generally terminating) computational problem (such as a large simulation) into smaller tasks, and spreading them across multiple processors to improve throughput. Parallel programming would presumably involve programming such systems. Concurrent computing does not necessarily require multiple processors, isn't (necessarily) terminating (e.g. servers), and may be made concurrent for reasons other than performance (such as to match natural concurrency in the problem domain). Concurrent programming would involve programming such systems. Both types of systems are obviously related, and can be analyzed using concurrency theory, but their focus and concerns are somewhat different. At least IMHO.
Similar arguments apply to the merging of 2 and 4
Merging 5 into 4 makes some sense - we'd have to see what the other people who have contributed to Parallel computing have to say
We might consider separate articles on Message passing and Shared memory approaches to concurrency (and perhaps one on declarative or dataflow concurrency). They are quite different approaches. Both the Concurrent computing and Parallel computing articles could then point to the appropriate articles on concurrency approaches as necessary
I agree that clarifying the relationship between Distributed computing, Parallel computing, and Concurrent computing would be useful.

--Allan McInnes 18:29, 16 January 2006 (UTC)[reply]

What Allan says above makes sense to me. --Carl Hewitt 18:35, 16 January 2006 (UTC)[reply]

Seems like a good plan! (I don't understand why Carl agrees with this, given that he expressed in the past that parallelism is a special case of concurrency, but the more support the better!) -- Koffieyahoo 08:40, 17 January 2006 (UTC)[reply]

I read Allan's views to be compatible with the thesis that parallelism can be considered to be a special case of concurrency. Also shared memory is going to continue to be one of principle means of implementing message passing although this fact does not, of itself, preclude separate articles. --Carl Hewitt 10:02, 17 January 2006 (UTC)[reply]

Yes. I consider parallelism a special case of concurrency. My reason for wanting to see separate "parallel computing" and "concurrent computing" article is that, as I said above, their focus and concerns are somewhat different. I think it's worth mentioning that message passing can be implemented via shared memory. But I think it's useful to have separate articles, since programming directly in a shared memory concurrency model is quite different than programming in a message-passing model.

Since we're discussing the overall organization of WP concurrency articles here, I guess we'd better include articles like Thread (computer science), Computer multitasking, Process (computing), and Inter-process communication in our considerations. This is starting to sound like a major undertaking. Is there a need for a Concurrency Wikiproject to coordinate our efforts, and the efforts of other contributors who have worked on these articles? Another alternative might be to get Category:Concurrent computing on the radar at Wikipedia:WikiProject Computer science, and make use of their infrastructure to coordinate things. --Allan McInnes 03:31, 18 January 2006 (UTC)[reply]

It seems to me that a Concurrency Wikiproject is a good idea to coordinate our efforts because of the special needs of the area which are different from the more general concerns of Wikipedia:WikiProject Computer science. It is starting to sound like a major undertaking and I would like to thank you for getting the ball rolling. --Carl Hewitt 12:01, 19 January 2006 (UTC)[reply]

Little food for some thought (although admittedly quite "old"): G.R. Andrews, Concurrent Programming, principles and practice, Benjamin/Cummings (1991), p. 3. Andrews says that parallel programming is exactly the same as concurrent programming except that a multiprocessor is used for execution in the case of parallel programming while this does not need to be the case with concurrent programming. -- Koffieyahoo 12:30, 19 January 2006 (UTC)[reply]

Yes, "parallel programming is exactly the same as concurrent programming except..." in the sense that the techniques used are essentially the same. Andrews is quite correct there. My reason for wanting to keep two different articles is that (IMHO) the problems that each is used to address are often quite different, which leads to differences in emphasis. A little further food for thought: A.W. Roscoe The Theory and Practice of Concurrency, Prentice Hall (1998) (online here), p. 2. Roscoe claims that the difference between "parallel computing" and the study of concurrency is that the former is concerned with "...understanding the structure of the problem or algorithm...", while the latter is concerned with the "...concurrent behaviour..." and interaction (the design of the parallel computing system having made the details of interaction less of a concern - see also Parallel Random Access Machine).

Another way to look at it is that Concurrent computing systems are generally (although not necessarily) interactive (their behavior depends on external inputs that may appear during the computation), while Parallel computing systems are (AFAIK) essentially non-interactive - the computation they perform may be carried out in parallel, but it is not influenced by inputs during computation (for example the Embarrassingly parallel problems and Grand Challenge problems. Granted, the terminology is confusing. Perhaps the best approach would be to fold Parallel programming into Concurrent computing along with Concurrent programming, since there is a reasonable argument that the programming aspect is pretty much the same in both cases, but keep Parallel computing as a separate article that discusses things like the design of the parallel computing systems, and the types of algorithms that are used in such systems. It would probably be worthwhile to get some input from users who have contributed significantly to Parallel computing, such as User:Egil and User:Arcann. I'll drop them a note to look in on this discussion. --Allan McInnes 17:11, 19 January 2006 (UTC)[reply]

I'm by no means an expert on the terminology. However, my understanding of the terms meshes best with what Allan has said. To me Concurrent computing / Concurrent programming focus on thread interactions -- with the classical example being the implementation of an OS. Parallel programming and Parallel computing on other hand are related to algorithms for breaking a single task into multiple threads. My particular work has been with parallel ETL or data analysis development. Arcann 22:22, 19 January 2006 (UTC)[reply]

Reading your explanation I think we basically agree on what concurrency and parallelism mean (I hereby admit that my parallelism = concurrency was a bit of an overstatement to get the proverbial ball rolling). I'll try to summarise my interpretation of things to see we really agree:

Concurrency is concerned with mechanisms and ways in which threads or processes interact. These processes and thread may or may not run on different processors (or cores, whatever). Interaction with the user may or may not occur.
In parallelism you basically have multiple processors and and you exploit these to scale your computing jobs. This uses concurrency techniques. Usually, systems that call themselves parallel are tightly coupled (i.e., the processors are close to each other, e.g., all in the same room) However, this is not a strictly necessary, see e.g. SETI@home, the ways of dealing with the RSA challenges, some of the work of Henri Bal. Interaction usually does not occur.
In distributed computing the processors are definitely not tightly coupled, and possibly distributed all over the world. In this case the the interaction is back once more, e.g., in the case the WWW (although admittedly this might not be the best example of a distributed system).

-- Koffieyahoo 07:52, 20 January 2006 (UTC)[reply]

We are in agreement :-) --Allan McInnes 17:18, 20 January 2006 (UTC)[reply]

Concurrency wikiproject

I have put up a proposal for a concurrency wikiproject at User:Allan McInnes/Concurrency project. Input from all interested parties (especially those who will actually contribute) is most welcome. --Allan McInnes 21:29, 20 January 2006 (UTC)[reply]

We'll be coordinating work on concurrency articles through Wikipedia:WikiProject Computer science instead. --Allan McInnes 04:57, 27 January 2006 (UTC)[reply]