Should a good programming language enforce one particular paradigm or should it incorporate multiple paradigms?

donaldkellett profile image Donald Sebastian Leung ・1 min read

I've had a few years of experience working with programming languages that mainly support imperative programming (declaring variables, creating loops, maintaining implicit state) but I've picked up Haskell over the past few months (which strictly enforces pure functional programming) and sometimes I wish that Haskell would provide at least basic support for some form of imperative programming (something like F#) - after all, it is much easier to create a loop and mutate a few variables than express everything in terms of recursion, monads and the like for certain types of problems. But then I look at languages like Swift which attempt to incorporate procedural, object-oriented and functional programming into one and all I see is a mess - it tries to make itself look familiar to developers using C-like languages but barely resembles C (or even Java, C#, JS and the like); it tries to make itself concise and human-readable like Python/Ruby by borrowing certain syntactic features but is actually far more verbose, and its extra-strong type system along with its "functional" features just seems to get in the way most of the time.

So, what do you think? Should a "good" programming language (whatever that may mean) strictly enforce one particular paradigm for all sorts of problems like Haskell, should it emphasize one particular paradigm but allow for other approaches as well like F# or should it try to incorporate as many different paradigms as possible and let the programmer decide which one(s) to use for each problem (e.g. Swift or C++)? Feel free to leave a comment below explaining your view :)

Posted on by:

donaldkellett profile

Donald Sebastian Leung


A Year 2 Computer Science and Engineering undergraduate at The Hong Kong University of Science and Technology


markdown guide

I think a great programming language should be extremely "choosy" of what it decides to incorporate as features. In my eyes, a bad example of a "choosy" language is Scala. It's absolutely chocked full of features, allowing you to use it in an assortment of ways - which is the biggest problem I have with it. In programming, it's already hard enough to choose the path of least resistance, so Scala's feature-rich ecosystem only compounded the challenge of deciding how to structure and write my code.

On the other hand, a great example of a "choosy" language, in my eyes, is Java. Some of the beauties of working with Javascript, such as callbacks (functions are objects) and built-in map, filter, reduce operations, just weren't possible in heavily imperative languages like Java. But with Java 8 came lambda expressions and official support for Streams, making functional programming in Java far more accessible and concise. I think Java allows you to do just enough with the language in order to get stuff done, without all of the bloat that comes with a language like Scala. In my opinion, keeping the language lean, but responding to what its user-base wants, is the recipe for a lasting, impactful, and widely-used language.


One of the reasons I really like Go is due to its "choosy"-ness. I know that some consider Go to be oversimplified or too "stupid", but I really enjoy the fact that I can focus on designing my application and structuring my data instead of worrying too much about the language.