12 ms·

Multi-Paradigm Languages

29 points by kiyanwang 6y ago

0x445442 6y ago
With Java I've seen an increasing problem with programming style in large projects because of it's kitchen sink support of so many paradigms. In addition to code readability it also effects code reviews because many cases come done to taste and it's difficult to build any type of consensus.
- dragonwriter 6y ago
  > With Java I've seen an increasing problem with programming style in large projects because of it's kitchen sink support of so many paradigms. Java is pretty much the purest classic class-based OOP language of all industrially-significant languages. It has constructs inspired by those from other paradigms, especially FP, transposed into a class-based OOP context, but it's pretty much the last language I’d point it as suffering (or benefiting) from “support of so many paradigms”.
  - 0x445442 6y ago
    It’s pretty easy to go full procedural with static where classes function only as a name space. Also, I’ve worked in code bases that were a Frankenstein mixture of deeply nested inheritance hierarchies mixed with attempts to be fully functional mixed with C code written in Java. So I stand by my statement.
  - pjmlp 6y ago
    Some of those FP concepts, transposed into a class-based OOP context, like closures and algorithms over data structures, where already present in Smalltalk-80 actually.
sriku 6y ago
One fantastic multi-paradigm-from-the-start language that often gets missed out is Mozart/Oz - http://mozart2.org http://mozart2.org . This language is used in the awesome book "Concepts, Techniques, and Models of Computer Programming" by Peter van Roy and Seif Haridi - https://www.info.ucl.ac.be/~pvr/book.html https://www.info.ucl.ac.be/~pvr/book.html
- rramadass 6y ago
  This is a great and mind expanding book/System. However since Mozart/Oz does not seem to be used that much in the "real world", i think it maybe worthwhile to investigate application of the same ideas to a mix of Erlang and C/C++.
  - edfalis 6y ago
    Although it's nominally about C++, this book looks at the design issues for selecting among paradigms based on application characteristics. IE it generalizes to other languages capable of supporting multiple paradigms. https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien/dp/0201824671/ref=sr_1_1?dchild=1&keywords=coplien+multiparadigm+programming&qid=1606226686&s=books&sr=1-1 https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien...
- Wildgoose 6y ago
  Just wanted to add my recommendation for Concepts, Techniques, and Models of Computer Programming" by Peter van Roy and Seif Haridi. This is an amazingly thorough, comprehensive and erudite work. Highly recommended.
- nextos 6y ago
  Mozart/Oz is so underrated. It's a shame it never took off. AliceML was also an interesting hybrid of Oz + SML.
  - mncharity 6y ago
    > Mozart/Oz is so underrated. It's a shame it never took off. The documentation was a major barrier. More so than any other language (trying for public adoption) that I can immediately think of. A textbook-expensive dead-tree book as onboarding path. With the usual pattern of commercial thing reducing incentive to create accessible thing, without fully meeting the need for same. And online documentation that was fragmented and poorly integrated. So "looking up" a topic would involve groveling over a pile of documents, and lecture notes and such, searching out pieces of the puzzle, and pulling them together yourself. So much niftiness, so inaccessibly documented. :/ I once massaged together a distributed table of contents[1] (long since link rotted), which might give a feel for it. Part of the problem was M/Oz was at heart a teaching and academic effort - think of early Racket. One of the hardest things about capturing history (and perhaps a fruitful way to teach it?) is the "wait, they wat?!!?". Picking up a language now, with expectations of how language and ecosystem are documented, and HN kibitzing on "the landing page should be improved by ...", reflects a big cultural learning process on how to do this well. Mozart/Oz, didn't. [1] http://www.vendian.org/oz/wiki/index.cgi?VirtualManual http://www.vendian.org/oz/wiki/index.cgi?VirtualManual
nabla9 6y ago
Common Lisp is the best multi-paradigm language I know.
- galactus 6y ago
  I came here to write this, I was surprised it was not even mentioned.
milansuk 6y ago
Another option is DSL[0]. It takes some time to create a new language and other team members have to learn it, but long-term efficiency will be out of the roof! Also, I think it would be nice, If there was a platform(maybe it exists?), which would connect let's say top 20 languages and it would be super easy to call function/block of code from other languages. Programmers just pick up the right language for the specific part of project. [0] https://en.wikipedia.org/wiki/Domain-specific_language https://en.wikipedia.org/wiki/Domain-specific_language
- joombaga 6y ago
  The platform you're describing is the way I use bash (understood that you're asking for a little more integration than just exec/fork/spawn).
- AnimalMuppet 6y ago
  I think SWIG (the Simplified Wrapper and Interface Generator, www.swig.org) may be what you're looking for. It can create interface code for calling language X from language Y. I'm not sure it covers all the most popular 20 languages, but it covers a lot.
- ywei3410 6y ago
  It does exist and it's called Racket [1] and language-oriented programming. You can write prolog-like languages [2], or Haskell-like [3], or even C-like languages [4]. You can even write BNF directly [5] and you can /call/ these constructs across different languages. Racket makes it /easy/ to play with semantics and syntax. You can feasibly write a language in an afternoon, to solve 1 specific problem. [1] https://racket-lang.org/ https://racket-lang.org/ [2] https://docs.racket-lang.org/datalog/datalog.html?q=datalog https://docs.racket-lang.org/datalog/datalog.html?q=datalog [3] https://github.com/lexi-lambda/hackett https://github.com/lexi-lambda/hackett [4] https://docs.racket-lang.org/profj/ https://docs.racket-lang.org/profj/ [5] https://beautifulracket.com/appendix/why-lop-why-racket.html https://beautifulracket.com/appendix/why-lop-why-racket.html
  - dgb23 6y ago
eyelidlessness 6y ago
A little surprised Swift and Kotlin aren’t mentioned. Both expressly support FP and OOP approaches (although some of Swift’s FP-enabling features like protocols look more familiar in OOP contexts, similar to the common misconception that TypeScript is primarily designed for OOP).
williadc 6y ago
Raku (formerly Perl6) is multi-paradigm.
dkarl 6y ago
This article doesn't take a fair look at where the "wars" come from at all. In my experience, the wars come from people wanting to be productive in a language but not feeling productive in an unfamiliar paradigm. It's a social problem that needs a social solution -- and the solution isn't to tell people to "reject purity." The skills and mental habits required to be productive in a given language and paradigm take time to develop, and different paradigms can have substantially different library ecosystems, even in the same language. In a language that supports multiple substantially different styles of programming, choosing a style has implications for short and long term productivity as well as programmer morale (maybe drastically different morale consequences for different programmers on your team.) Most people won't remember, but there was a time in the 1990s when there were a lot of professional programmers who were not comfortable with OO. In a codebase, you'd get fights between people who embraced classes and utilized dynamic dispatch and people who didn't see the point of those things and were able to be extremely productive without them. Now there are a ton of professional programmers who are not comfortable with FP, coexisting in the profession with programmers who have fallen in love with type classes and use them habitually to solve every problem. It's a massively unjust cop-out to tell the former that they need to "reject purity," as if it's a moral flaw they need to fix. It's a long process of learning new skills and concepts, during which they will not be performing as accustomed at their job. People who balk at that are not just narrow-minded. People who focus on present productivity rather than future productivity are often the people who are getting the most work done, and it's important for an organization to figure out a path forward for the entire team before letting a new paradigm loose in the codebase. Moreover, it's legitimate to ask if the short-term consequences will be balanced out by long-term gains. Also, as a response to the article trying to mix design patterns into the argument, if people want to make design patterns a thing, the idea needs a complete relaunch. Convince me that they're worth the effort. In my twenty years of experience working with other programmers, programmers who know design patterns are not better programmers than those who don't. I don't feel any less capable having 99% forgotten them. Most importantly, younger programmers who never bothered with them are just as good at structuring code as those of us who worked through the GoF book during our formative years. My opinion: just let it go.
- AnimalMuppet 6y ago
kevsim 6y ago
I worked at a company where they had to fire some of Scala programmers. The people who were fired were functional purists, whereas a bunch of the team were coming from Java and (understandably) wrote Scala as if it were just more terse Java (very Kotlin-esque). Long story short, the third or forth time they were caught rewriting perfectly adequate and correct code simply because it wasn't embracing all of Scala's functional constructs, they were warned. Next time, they were canned.
- dkarl 6y ago
  I've been a Scala programmer for close to ten years now, and I've been shocked at how blithely people will 1) unilaterally commit their coworkers to enormous learning curves, without regard for the consequences, and 2) use crucial projects as personal learning opportunities, again without regard for the consequences. Partly it's self-indulgence, partly it's machismo, partly it's a sincere desire to build the best thing possible, but whatever the motivation, it can cause a huge mess. People need to feel responsible for leaving a certain ratio of polished, mature code to beginner, learning code, even though that means that (gasp!) they can't live in a permanent state of learning big new things.
  - AzzieElbab 6y ago
    IMHO scala projects require company’s wide enforced coding styles. Otherwise one group will try writing it as Haskell while the other will run off with Java crap that is simply not needed in scala
    - valenterry 6y ago
      That's right. And actually, once you stick to one of them, Scala is an amazing and productive language, better than Kotlin and Java are and will probably ever be. But mixing the two styles does not work out.
      - dkarl 6y ago
        I agree. Vanilla OO/functional Scala, focused on immutability and functional idioms, but without effect systems and type classes, can be a really beautiful, simple, expressive, highly productive way to develop software. I'm neck deep in FP Scala now (the cats ecosystem with cats-effect) and hoping I eventually come to feel the same way about it. I'm very sad about the Java OO extremists and the Scala functional extremists finding common cause in denying the possibility of moderate, limited use of Scala's power. Programming that way is head and shoulders above Java, and I've yet to see FP Scala match it for productivity (again, hoping and working, so fingers crossed.)
rramadass 6y ago
A superficial article, not good enough. Better read this oldie but a goodie: Multi-Paradigm Design for C++ by James Coplien. It is an oldie only in the sense that we have learnt new techniques on using the "template sub-language" within C++ in even more interesting ways like meta-programming etc. since then. With "Modern C++" more features have been introduced to increase the footprint of "design expression space".
mumblemumble 6y ago
This article has me torn. On the one hand, I always use multiparadigm languages at work, and have always preferred a pragmatic, "best tool for the job" approach. On the other hand, I am starting to believe that, in truth, there are no multi-paradigm languages. Only imperative languages with bells and whistles. Because what matters isn't how you can use the language, it's how you do use the language. With the peculiar recent exception of Scala, multi-paradigm languages seem to always tend toward a mushy, homogeneous, imperative style whose most noteworthy feature is just how imperative it is. Even with all the classes, higher-order functions, and declarative DSLs sprinkled on top, the overall shape always ends up being overwhelmingly imperative. It takes more than a dollop of meringue to turn apple pie into key lime pie. I didn't really start thinking this way until more recently, when I started looking outside of the mainstream and paying more attention to explicitly single-paradigm languages. I think maybe it's a bit like how McDonald's, A&W, Burger King, Hardee's, etc. all seem completely interchangeable if you don't spend a lot of time eating at them.
a4444f 6y ago
"metalanguage does not exist"

29 points by kiyanwang 6y ago

With Java I've seen an increasing problem with programming style in large projects because of it's kitchen sink support of so many paradigms. In addition to code readability it also effects code reviews because many cases come done to taste and it's difficult to build any type of consensus.

dragonwriter 6y ago
> With Java I've seen an increasing problem with programming style in large projects because of it's kitchen sink support of so many paradigms. Java is pretty much the purest classic class-based OOP language of all industrially-significant languages. It has constructs inspired by those from other paradigms, especially FP, transposed into a class-based OOP context, but it's pretty much the last language I’d point it as suffering (or benefiting) from “support of so many paradigms”.
- 0x445442 6y ago
  It’s pretty easy to go full procedural with static where classes function only as a name space. Also, I’ve worked in code bases that were a Frankenstein mixture of deeply nested inheritance hierarchies mixed with attempts to be fully functional mixed with C code written in Java. So I stand by my statement.
- pjmlp 6y ago
  Some of those FP concepts, transposed into a class-based OOP context, like closures and algorithms over data structures, where already present in Smalltalk-80 actually.

sriku 6y ago

One fantastic multi-paradigm-from-the-start language that often gets missed out is Mozart/Oz - http://mozart2.org http://mozart2.org . This language is used in the awesome book "Concepts, Techniques, and Models of Computer Programming" by Peter van Roy and Seif Haridi - https://www.info.ucl.ac.be/~pvr/book.html https://www.info.ucl.ac.be/~pvr/book.html

rramadass 6y ago
This is a great and mind expanding book/System. However since Mozart/Oz does not seem to be used that much in the "real world", i think it maybe worthwhile to investigate application of the same ideas to a mix of Erlang and C/C++.
- edfalis 6y ago
  Although it's nominally about C++, this book looks at the design issues for selecting among paradigms based on application characteristics. IE it generalizes to other languages capable of supporting multiple paradigms. https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien/dp/0201824671/ref=sr_1_1?dchild=1&keywords=coplien+multiparadigm+programming&qid=1606226686&s=books&sr=1-1 https://www.amazon.com/Multi-Paradigm-Design-C-James-Coplien...
Wildgoose 6y ago
Just wanted to add my recommendation for Concepts, Techniques, and Models of Computer Programming" by Peter van Roy and Seif Haridi. This is an amazingly thorough, comprehensive and erudite work. Highly recommended.
nextos 6y ago
Mozart/Oz is so underrated. It's a shame it never took off. AliceML was also an interesting hybrid of Oz + SML.
- mncharity 6y ago
  > Mozart/Oz is so underrated. It's a shame it never took off. The documentation was a major barrier. More so than any other language (trying for public adoption) that I can immediately think of. A textbook-expensive dead-tree book as onboarding path. With the usual pattern of commercial thing reducing incentive to create accessible thing, without fully meeting the need for same. And online documentation that was fragmented and poorly integrated. So "looking up" a topic would involve groveling over a pile of documents, and lecture notes and such, searching out pieces of the puzzle, and pulling them together yourself. So much niftiness, so inaccessibly documented. :/ I once massaged together a distributed table of contents[1] (long since link rotted), which might give a feel for it. Part of the problem was M/Oz was at heart a teaching and academic effort - think of early Racket. One of the hardest things about capturing history (and perhaps a fruitful way to teach it?) is the "wait, they wat?!!?". Picking up a language now, with expectations of how language and ecosystem are documented, and HN kibitzing on "the landing page should be improved by ...", reflects a big cultural learning process on how to do this well. Mozart/Oz, didn't. [1] http://www.vendian.org/oz/wiki/index.cgi?VirtualManual http://www.vendian.org/oz/wiki/index.cgi?VirtualManual

nabla9 6y ago

Common Lisp is the best multi-paradigm language I know.

galactus 6y ago
I came here to write this, I was surprised it was not even mentioned.

milansuk 6y ago

Another option is DSL[0]. It takes some time to create a new language and other team members have to learn it, but long-term efficiency will be out of the roof! Also, I think it would be nice, If there was a platform(maybe it exists?), which would connect let's say top 20 languages and it would be super easy to call function/block of code from other languages. Programmers just pick up the right language for the specific part of project. [0] https://en.wikipedia.org/wiki/Domain-specific_language https://en.wikipedia.org/wiki/Domain-specific_language

joombaga 6y ago
The platform you're describing is the way I use bash (understood that you're asking for a little more integration than just exec/fork/spawn).
AnimalMuppet 6y ago
I think SWIG (the Simplified Wrapper and Interface Generator, www.swig.org) may be what you're looking for. It can create interface code for calling language X from language Y. I'm not sure it covers all the most popular 20 languages, but it covers a lot.
ywei3410 6y ago
It does exist and it's called Racket [1] and language-oriented programming. You can write prolog-like languages [2], or Haskell-like [3], or even C-like languages [4]. You can even write BNF directly [5] and you can /call/ these constructs across different languages. Racket makes it /easy/ to play with semantics and syntax. You can feasibly write a language in an afternoon, to solve 1 specific problem. [1] https://racket-lang.org/ https://racket-lang.org/ [2] https://docs.racket-lang.org/datalog/datalog.html?q=datalog https://docs.racket-lang.org/datalog/datalog.html?q=datalog [3] https://github.com/lexi-lambda/hackett https://github.com/lexi-lambda/hackett [4] https://docs.racket-lang.org/profj/ https://docs.racket-lang.org/profj/ [5] https://beautifulracket.com/appendix/why-lop-why-racket.html https://beautifulracket.com/appendix/why-lop-why-racket.html
- dgb23 6y ago

eyelidlessness 6y ago

A little surprised Swift and Kotlin aren’t mentioned. Both expressly support FP and OOP approaches (although some of Swift’s FP-enabling features like protocols look more familiar in OOP contexts, similar to the common misconception that TypeScript is primarily designed for OOP).

williadc 6y ago

Raku (formerly Perl6) is multi-paradigm.

dkarl 6y ago

This article doesn't take a fair look at where the "wars" come from at all. In my experience, the wars come from people wanting to be productive in a language but not feeling productive in an unfamiliar paradigm. It's a social problem that needs a social solution -- and the solution isn't to tell people to "reject purity." The skills and mental habits required to be productive in a given language and paradigm take time to develop, and different paradigms can have substantially different library ecosystems, even in the same language. In a language that supports multiple substantially different styles of programming, choosing a style has implications for short and long term productivity as well as programmer morale (maybe drastically different morale consequences for different programmers on your team.) Most people won't remember, but there was a time in the 1990s when there were a lot of professional programmers who were not comfortable with OO. In a codebase, you'd get fights between people who embraced classes and utilized dynamic dispatch and people who didn't see the point of those things and were able to be extremely productive without them. Now there are a ton of professional programmers who are not comfortable with FP, coexisting in the profession with programmers who have fallen in love with type classes and use them habitually to solve every problem. It's a massively unjust cop-out to tell the former that they need to "reject purity," as if it's a moral flaw they need to fix. It's a long process of learning new skills and concepts, during which they will not be performing as accustomed at their job. People who balk at that are not just narrow-minded. People who focus on present productivity rather than future productivity are often the people who are getting the most work done, and it's important for an organization to figure out a path forward for the entire team before letting a new paradigm loose in the codebase. Moreover, it's legitimate to ask if the short-term consequences will be balanced out by long-term gains. Also, as a response to the article trying to mix design patterns into the argument, if people want to make design patterns a thing, the idea needs a complete relaunch. Convince me that they're worth the effort. In my twenty years of experience working with other programmers, programmers who know design patterns are not better programmers than those who don't. I don't feel any less capable having 99% forgotten them. Most importantly, younger programmers who never bothered with them are just as good at structuring code as those of us who worked through the GoF book during our formative years. My opinion: just let it go.

AnimalMuppet 6y ago

kevsim 6y ago

I worked at a company where they had to fire some of Scala programmers. The people who were fired were functional purists, whereas a bunch of the team were coming from Java and (understandably) wrote Scala as if it were just more terse Java (very Kotlin-esque). Long story short, the third or forth time they were caught rewriting perfectly adequate and correct code simply because it wasn't embracing all of Scala's functional constructs, they were warned. Next time, they were canned.

dkarl 6y ago
I've been a Scala programmer for close to ten years now, and I've been shocked at how blithely people will 1) unilaterally commit their coworkers to enormous learning curves, without regard for the consequences, and 2) use crucial projects as personal learning opportunities, again without regard for the consequences. Partly it's self-indulgence, partly it's machismo, partly it's a sincere desire to build the best thing possible, but whatever the motivation, it can cause a huge mess. People need to feel responsible for leaving a certain ratio of polished, mature code to beginner, learning code, even though that means that (gasp!) they can't live in a permanent state of learning big new things.
- AzzieElbab 6y ago
  IMHO scala projects require company’s wide enforced coding styles. Otherwise one group will try writing it as Haskell while the other will run off with Java crap that is simply not needed in scala
  - valenterry 6y ago
    That's right. And actually, once you stick to one of them, Scala is an amazing and productive language, better than Kotlin and Java are and will probably ever be. But mixing the two styles does not work out.
    - dkarl 6y ago
      I agree. Vanilla OO/functional Scala, focused on immutability and functional idioms, but without effect systems and type classes, can be a really beautiful, simple, expressive, highly productive way to develop software. I'm neck deep in FP Scala now (the cats ecosystem with cats-effect) and hoping I eventually come to feel the same way about it. I'm very sad about the Java OO extremists and the Scala functional extremists finding common cause in denying the possibility of moderate, limited use of Scala's power. Programming that way is head and shoulders above Java, and I've yet to see FP Scala match it for productivity (again, hoping and working, so fingers crossed.)

rramadass 6y ago

A superficial article, not good enough. Better read this oldie but a goodie: Multi-Paradigm Design for C++ by James Coplien. It is an oldie only in the sense that we have learnt new techniques on using the "template sub-language" within C++ in even more interesting ways like meta-programming etc. since then. With "Modern C++" more features have been introduced to increase the footprint of "design expression space".

mumblemumble 6y ago

This article has me torn. On the one hand, I always use multiparadigm languages at work, and have always preferred a pragmatic, "best tool for the job" approach. On the other hand, I am starting to believe that, in truth, there are no multi-paradigm languages. Only imperative languages with bells and whistles. Because what matters isn't how you can use the language, it's how you do use the language. With the peculiar recent exception of Scala, multi-paradigm languages seem to always tend toward a mushy, homogeneous, imperative style whose most noteworthy feature is just how imperative it is. Even with all the classes, higher-order functions, and declarative DSLs sprinkled on top, the overall shape always ends up being overwhelmingly imperative. It takes more than a dollop of meringue to turn apple pie into key lime pie. I didn't really start thinking this way until more recently, when I started looking outside of the mainstream and paying more attention to explicitly single-paradigm languages. I think maybe it's a bit like how McDonald's, A&W, Burger King, Hardee's, etc. all seem completely interchangeable if you don't spend a lot of time eating at them.

a4444f 6y ago

"metalanguage does not exist"