> So, whether you prefer an imperative, functional, object-oriented, or pipelined approach
The problem with this: if you give people a multi-paradigm language, they'd be using all of them. Often in the same codebase.
back
3 comments
I think people should use all of them. Some problems are much better expressed with logic programming, others with inheritance, others with polymorphic functions.
There is one school which says people ought to be giving a powerful programming language to better write powerful programs in the best way. The idea is to amplify what a single programmer can produce.
Another school says you should give programmers a non-powerful language because they aren’t to be trusted. The goal is to make changing enormous codebases easy (or maybe to maximise lines of code).
Perl fits into the first category and java is representative of the second. So I think this argument isn’t so much about Perl as it is a complaint about its philosophy. It could equally go on an article about the next c++ feature.
Any business problems that can be shown, objectively, to be better solved by one paradigm versus another can also be isolated into its own code base/module where said paradigm is canonical and ubiquitous.
The problem is, this rarely happens and with a language like Perl and Java you end up with a mish mosh of hard to reason about code bases because the authors at the time were just trying to muddle through as best they could with whatever approach resonated with them.
I'd like a definition of "powerful" that is more than just "agrees with my personal prejudices"; Perl lacks the power of a strongly checked type system, for example.
All the examples in the post are written in Perl 6 though, which does not lack it.
This is what finally killed it for me and Python. I'm inclined to functional programming and writing SQL instead of using an ORM. This was easily possible in Python, but my coworkers would often refer to it as "hacky" even though my tests would show it was more performant than marshaling objects to do a simple transform. My direct lead would often only write imperative code, and one off scripts with very little reuse possible (let alone tools that could be handed off to other team members). Very frustrating.
I find more opinionated languages like Clojure help. On that note, is the title a riff on "Simple Made Easy"?
Your problem was in environment which didn't embrace the ways you like, not that language was multi-paradigm. "I love Python cooked functionally, but my colleagues do only OO" is equivalent to "I love Clojure, but my colleagues do only Java".
I think the problem with almost all mainstream languages today that they are morally outdated. I feel for the next decade the industry will be striving for programming languages optimized either for developer's productivity, for correctness or for the execution performance and/or minimized footprint. Most languages today, including Python and Perl (and many others) sadly are not making progress in any of those directions. That's why programmers are desperately trying to find better ways, jumping from OOP to functional, from dynamically typed to statically typed, creating new frameworks, trying all sorts of hacks to improve concurrency, performance characteristics, etc. Burnout rates are high, and writing software is more complicated than ever. You can literally choose any PL from TIOBE's top 10 and if you get enough expertise - you'd realize that it is nothing but a big clusterfuck of a language.
Have you looked at Perl 6 ??
"I love Python cooked functionally, but my colleagues do only OO" is equivalent to "I love functional Java but my colleagues do only OO Java".
Fixed that for you. The whole point of the comment was that Clojure, by and large, forces you to work one way and Python doesn't.
The whole point of the comment was that Clojure, by and large, forces you to work one way and Python doesn't.
The point of my comment is that it's not true (except in a narrow educational meaning). Your working environment (managers, colleagues, existing codebase) is what defines your limits in general, including language, approach, style, and frameworks. If your current shop can't accept your call to write more functional code in whatever language is used there, it obviously won't start developing in Clojure. It works exactly this way, not in the opposite direction. Ergo, the guy's problem was that his environment wasn't inclined to switch from OO. He couldn't say "Mates, let's use Clojure, because it will finally FORCE you to discover the beautiful world of FP", because they just want to keep doing what they were doing yesterday.
Fixed that for you.
It's not a correction, and I hope you see now what I mean.
You have a point, but coming to a consensus within a working environment can lead to a lot of friction and politics.
Sadly also software is hardly ever one working environment. In Python, the libraries are a strong feature, and each library will have different contributors. Each with their own opinion on what is the most effective programming style.
Take Python's Django framework for an example, it contains both OO and functional ways of doing most things. This can be confusing for newcomers who just want to know what is the best methodology going forward. One of the key features of using a framework is it allows you to add new developers to your project and they will know how to get things done.
Clojure is kinda unique. It minimizes vector of frustration by merely not allowing needless garbage. Commas are the whitespace - totally makes sense. No bullshit stuff like semicolons. How many precedence rules are there, for example in Javascript? Like 19. In Scala? 14. In Clojure? Zero. How many things in Javascript can be falsy? (evaluate to false) - Seven. In Clojure - only two. How many reserved words there in Javascript? 64! How many in Clojure? Zero. Yes, that's right: there are no reserved words in Clojure. Do you know how many rules are there in ESLint? A lot! In contrast, Clojure teams have to agree to a single styleguide rule - either they align things or indent them - and that's it.
Does that all make Clojure less powerful than other languages? It turns out it, actually that makes it a lot more fun to work with. So yes, I agree with you, the article takes "Simple Made Easy" and turns it upside down. That talk is absolutely not about what was demonstrated in the article.
This is Perl, the native language of Tim Toady, so this is to be expected.
Never mind that functional and imperative programming have been attached to OO languages since at least SmallTalk…