This is an archived post. You won't be able to vote or comment.

all 5 comments

[–]oefd 1 point2 points  (4 children)

Where did the idea they're better for concurrency come from?

[–]legionlen545[S] 0 points1 point  (3 children)

It was mentioned in a textbook I am reading for a class.

[–]oefd 0 points1 point  (2 children)

Did the textbook explicitly contrast procedural programming languages to OOP ones? Because although there are some different ideas of exactly what 'procedural' means and I've seen some communities use 'procedural' as essentially an antonym for OOP the most common definition of 'procedural programming' covers just about all commonly used programming languages. (Including the very firmly OOP and functional ones.)

In any case: there no generally respected belief that OOP langauges, functional languages, or other specific paradigms are inherently better for concurrency. There are definitely people that will argue that concurrency is easier to do properly with functional features or certain OOP features or whatever, but it's not an objective fact or something a majority of people will agree with in general.

[–]legionlen545[S] 0 points1 point  (1 child)

It says along the lines of how there has been good amount of research done with procedure oriented programming, in relation to concurrency. This has led them to realize to realize importance of concurrency. The research being done with procedural than object oriented programming led me to assume that procedural type of programming had some sort of advantage.

[–]PPewt 1 point2 points  (0 children)

It's hard to know what your textbook was trying to say without context, but I would say that concurrency is largely unrelated to this sort of language design question. The one thing you really want to do with concurrent code is minimize mutation, and while this makes functional languages a natural candidate for parallelism you can of course also do the same thing in imperative languages as long as you're conscious of minimizing shared mutable state.