I don't it's completely fair to say that functional thinking enforces a particular structure. In many ways, FP languages are better at describing behavior than imperative languages. This should, in theory, give compilers more latitude to optimize for better performance. However, compilers today are nowhere near good enough to do that. I think that most high performance oriented languages choose an imperative style mostly because of the C-style syntax (as mentioned above), but also partly because of some of the abstractions common to FP languages are not zero-cost (garbage collection, in particular, is very expensive). However, I think a language such as Rust, while not the most performant nor the most expressive language, has shown we can still introduce functional ideas with minimal overhead (pattern matching, traits, mutable vs. immutable, etc.).
Firephinx
Just a note: I was wondering what the definition of a "side-effect" was relative to programming languages.
Side-effects just mean that a function or expression in a language can interact with state that is outside of its scope, i.e. global variables or memory (other than a return value).
Imperative programming frequently uses side-effects because it tends to modify variables all over the place.
However, functional programming like SML tends to be side-effect free because "functions are values," and we don't tend to change values outside of the scope of the function. SML does not explicitly restrict side-effects though.
Haskell is a functional language that uses side effects for I/O and other stateful computations.
If you want to read more about side-effects, you can do so here.
I don't it's completely fair to say that functional thinking enforces a particular structure. In many ways, FP languages are better at describing behavior than imperative languages. This should, in theory, give compilers more latitude to optimize for better performance. However, compilers today are nowhere near good enough to do that. I think that most high performance oriented languages choose an imperative style mostly because of the C-style syntax (as mentioned above), but also partly because of some of the abstractions common to FP languages are not zero-cost (garbage collection, in particular, is very expensive). However, I think a language such as Rust, while not the most performant nor the most expressive language, has shown we can still introduce functional ideas with minimal overhead (pattern matching, traits, mutable vs. immutable, etc.).
Just a note: I was wondering what the definition of a "side-effect" was relative to programming languages.
Side-effects just mean that a function or expression in a language can interact with state that is outside of its scope, i.e. global variables or memory (other than a return value).
Imperative programming frequently uses side-effects because it tends to modify variables all over the place.
However, functional programming like SML tends to be side-effect free because "functions are values," and we don't tend to change values outside of the scope of the function. SML does not explicitly restrict side-effects though.
Haskell is a functional language that uses side effects for I/O and other stateful computations.
If you want to read more about side-effects, you can do so here.