> My graduate school experience convinced me that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones.
I wonder if that last bit was as unfashionable a statement when he made it as it would be now.
The vast majority of the world's programs are written in procedural languages, and that situation does not look likely to change for the foreseeable future.
(I should know better than to post ambiguous one-liners late at night.)
It's certainly not an uncommon preference, but it's an unfashionable statement, at least among the intellectual circles that programming language designers with PhDs (or almost-PhDs!) tend to belong to. That's why I was interested to read it there. I've long had a joke, when asked if I prefer FP or OO, to say "I prefer imperative programming". It's funny because of that fashion. What I was wondering was whether said fashion was in place by the late 90s when dmr apparently wrote this, in which case maybe there was a trace of a joke there as well.
Edit: having read more of the OP, it seems to me deliciously apropos that his dissertation involved replacing recursive logic with loops.
Functional programming languages have alway been somewhat dismissed by most. Even though every once in a while functional programming becomes somewhat of a hot topic, only few programmers actually take it up as their main or favourite programming style. I'd say Ritchie's attitude there is and was kind of mainstream. I suppose just as C (or C style languages) have been mainstream for the past 40 years.
Many universities teach FP to their undergraduates, some of them even use Haskell as their first programming language.
I have published at ICFP and in the JFP, and understand garbage collectors, laziness, monads, good persistent data structures very well. Yet, I prefer CBV to lazy evaluation, I prefer full unrestricted support for imperative programming, I don't think Haskell approach to effects by monads is ideal (I prefer Scala's giving you the option to tame effects by monads).
There is a reason why, despite near half a century since Backus' "Can programming be liberated from the von Neumann style?", CUDA dominates HPC, C++/C (and Rust) dominate mainstream infrastructure programming, Go took the cloud world by storm, ML is dominated by Python, front-end is dominated by Javascript/Typescript, hardware design is dominated by Verilog, and business computing (for lack of a better term) is dominated by Java/C#. I really don't think the reason is that everybody is too uneducated to realise the benefits of Haskell.
I don't know, as far as I know functional programming is a standard course in computer science university curriculum. I've only been part of small dev teams so far, but of those teams always more than half were university educated, and none of them continued functional programming after university. Of all my university friends only one did Haskell outside of university that I know of (maybe there's some secret Scala/F# lovers at Java/.net firms). I've been part of the Haskell community, so it's not like I don't know Haskell programmers, but I'm saying I know a lot of formally educated programmers, and only very few of them took a liking to functional programming to an extent they'd do it professionally or even as a hobby.
I think there are quite a few closet "functional" programmers, who may not even consider themselves as such, doing their best to write mostly side-effect-free, declarative code within the confines of an OO or multi-paradigm language (in .NET land, functional-ish features like LINQ and pattern-matching bleeding into C# makes this easier). I also met more than one person trying to introduce F#/Scala in a pretty small .NET shop I used to work for.
Excel is at its core a declarative programming language. Entering formulas in cells that reference other cells declares the relationship of the calculated cells to its referents.
It is not an imperative language: the user does not tell the computer which order in which to carry out computations. It is not procedural: there is no notion writing of procedures within its cells. It is not functional: while there are built-in functions users cannot write their own in the same way.
You can indeed, but VBA is of course imperative, and VBA is used in part because it is difficult to read/write and considered a poor practice to have any significant chaining of functions in the spreadsheet. The bigger reason it is used, of course, is because Excel's declarative environment does not accommodate all behaviors and users prefer to implement them imperatively. So this sort of reinforces Excel as not being a functional environment.
Being able to write functions doesn’t make a language functional. The hallmark of functional programming is closures as first-class objects, passed as arguments or returned from other functions.
The nearest Excel equivalent would be constructing a formula string for later evaluation, which is far from the same thing. If you wanted to perform lambda calculus in Excel you’d end up implementing your own functional programming language in VBA. Have fun with that :-)
I’ve heard this before, but long felt it is more like logic programming: you declare facts and relationships, then an evaluation engine finds results.
Not saying you can’t, say, pass around closures in Excel but it’s far from natural. Whilst spreadsheets always remind me, more than anything, of the Prolog I took in college, and not the Lisp or ML.
> When you write a function in an Excel cell, IIANM it's a VBA function
No, its uses the Excel formula language, which isn't the same as VBA (nor is it a subset of VBA; Excel formula language expressions generally aren't valid VBA.)
Hated functional programming in university, now wish there was wider industry adoption. Deep diving into FP made me think more about the code, rather than just writing it in an OO-Language.
Having used functional languages extensively in a job setting and now using C++ more and more, I find that there's nothing wrong in just writing procedural code if that's easier. Easier both to write and easier to read later. I've seen people take 20 minutes to write a single line of functional Javascript or Kotlin, when the underlying work is obvious and just writing the loop directly would be faster to create and much easier to understand later by you or anyone else who has to read the code.
The move to functional-style code the last many years seems a bit silly to me. Even C++ has been moving in a well-known trend of "no raw loops" in favor of the algorithms header in STL. I don't find there is a significant reason to abandon easy code most of the time. If you actually need to use the functional paradigm to swap out behavior in a polymorphic fashion using functions instead of inheritance, for example, then great.
I tend to go with whatever makes the code the most readable; best expresses the intent. If I'm iterating over a list, mapping each element to a lookup somewhere, and then removing those that weren't found... that's a good choice for functional. If I'm iterating over a list, if it matches one thing do something, otherwise filter it some more and do something else... I tend to find procedural is easier to read. Maybe it's a transform vs act-on type of thing; I'm not sure.
In hindsight you can say he suffered from imposter syndrome.
People often have trouble to accept that an easy working solution to a difficult problem is an act of genius, instead they feel that they took a shortcut and are non deserving.
I've seen so many junior developers and interns thinking like this.
Sometimes they're are able to find a good simple solution to a hard problem but then feel bad for not using complex patterns, some popular external dependency, or for the lack of ability of giving it a complicated name.
The pro argument: many of the people I've exchanged email with[1] from that period have indicated that functional had more geek cred even then.
The con argument: we have enough memory and cpu now that functional languages are more practical than they ever were, which may help them be more prêt-à-porter fashion than the haute couture of a geekish peacock tail or springbok leap.
[1] I'm usually asking questions about long-dead endian-style controversies (cue the compromise of arrays starting at 0,5), and it's been nice to hear many of the people involved recommending the work of their opposites. Folk history seems to ascribe more dogmatic attitudes to the people who lived through technical controversies than they actually have.
Another lesson learned: when I try to tease out chains of influences, a not uncommon response is "I wish I'd been that clever, really it was just hacked together."
Thanks to Moore's Law, functional programming is no longer just for the mainframe, but can now be used for normal programs on standard platforms. If more people choose functional now just because they like the style[1], then it could be that procedural would be becoming less fashionable[2] over time.
[1] instead of before, when "wearing the hair shirt" of functional programming could be seen as declaring oneself a strong enough hacker that one could hack despite all the practical drawbacks.
Since it was on his Bell Labs website, surely this phrasing of the feeling came no earlier than the late 80s, rather than when he left academia in '68? ("Functional programming" as a contrasting term seems to have barely existed before Backus's Turing Award lecture in '77.)
For the 80s and much of the 90s Ritchie's view seems obviously dominant, in no small part due to his own work in making extremely "usable" tools for procedural programming.
Reading CACM on 50-year delay gives me an interesting diff against current state of the art. Functional programming was a thing (albeit perhaps before "functional programming" was a name) in the sixties.
CPL, IIRC, actually had an outer-functional semantics, and one would escape to "value of" blocks to do procedural stuff (which was necessary in inner code due to the pitifully small machines of the day).
Writing bootstrap compilers in GPM must've been very similar to working in a lazy functional language.
Is it possible that "functional programming" meant as in Kleene's Introduction to Metamathematics, where the work has a mathematical flavor with recursive functions, in contrast with FORTRAN or ALGOL or whatever language DR was using on physical machines at the time?
The best indicator of prevailing fashion is that the most popular languages are imperative or multi-paradigm, and some of them are descendants (at least in some aspects) of one made by Ritchie.
> I liked procedural languages better than functional ones.
(Emphasis, mine). I suspect that he understood functional languages quite well.
He just didn't like them.
I like some aspects of FP, but there are other aspects that I don't like.
My own development style is a ghastly chimera of techniques, technologies and jargon that coagulate into a disgusting bouillabaisse that makes everyone go "tsk, tsk," but that always seems to work quite well, is of extremely high quality, easy to understand, and results in a great deal of ship.
> I like some aspects of FP, but there are other aspects that I don't like.
Care to enumerate? Asking because I feel the same: I really enjoy immutability, first class functions, map/filter/reduce, Option<T> and powerful types (I dislike: currying, point-free, monads), but at the same time I feel more at home doing that in imperative-ish languages like C#, JS/TS and Rust where I can have guard ifs and the odd mutation here and there. Wondering if anyone else is the same.
Don't worry then, that's fine, you just dislike Haskell.
I personally really like functional programming but can't stand Haskell. The style favoured by the community is optimised to be the most impenetrable possible.
You should try Ocaml. The preferred style favours piping to point-free and uses monads sparingly. Currying is everywhere but copious use of named arguments tends to make things simpler.
Ah, funny thing: I worked with Haskell professionally for a while. I even enjoy the laziness.
My biggest gripe with it is not so much the language itself but the culture: it favours bloated and pompous solutions much in the same way Java/Spring does. Monad Lifting, Lenses, Aspects and FactoryFactories occupy the same space in my head.
I guess I just prefer both the simple side of functional and the simple side of imperative.
OCaml/Standard ML are both pretty nice because you can still use mutation, and the languages are significantly simpler than Haskell.
My only gripe with them is that there seems to be a culture of having zero type annotations (due to HM), which can make reading other people's code difficult.
> the languages are significantly simpler than Haskell
I don't think that's quite true.
Ocaml has plenty of advanced features (the module system, GADT, structural typing in the object system) but the community relationship with them is very different than how the Haskell community uses the language. For the most part, the Ocaml community tends to dislike gratuitous complexity and be non dogmatic (I fondly remember a lens library announcement on which the top comment could be boiled down to "just use mutations").
> My only gripe with them is that there seems to be a culture of having zero type annotations (due to HM), which can make reading other people's code difficult.
Interfaces tend to be annotated (mli files) but usually people rely on the tooling to know types inside files. Merlin is a blessing. It is a very fast type-checker which keeps working on incorrect files.
You’d probably like Erlang. Functional but pragmatic, an imperative core with immutability, native concurrency...it was my introduction to FP and I hope to get another shot at working with it professionally.
Yeah! Actually Joe Armstrong's Programming Erlang was my true introduction to FP, got the book when it was released. Lovely language, a shame I never found an opportunity to use it after that.
I do that a lot with Reason/OCaml. It is surprising how powerful imperative, mutable programming is when most of the code you write is functional, and then you want do something a little difficult in the paradigm, and you make a `ref`, write a while loop, mutate an array, or store stuff in a global variable, and it is done! Mutation in OCaml is like a fine scalpel - extremely powerful, occasionally used, and just right on the table whenever you need it.
Though C programming is usually about effects, effects occur in expressions which usually return a value except in cases when their type is "void" (which was a later introduction into C, possibly from C++).
C even has an if/then conditional that yields a value, the ternary operator x ? y : z, which is a more strongly typed version of (if x y z).
Ritchie: I liked procedural languages better than functional ones.
ChrisMarshallNY: I suspect that he understood functional languages quite well. He just didn't like them.
Your statement doesn't follow from Ritchie's words that you quoted. Preference of A over B does not have the logical consequence that B is disliked. It doesn't even imply that A is intensely liked.
I've been researching your point since I read your comment, but I haven't been able to learn if he actually disliked functional languages.
Personally, I prefer Haskell or some functional Python at times, since that solves certain problems well. But, we have a lot more computing resources than existed in the past. I guess it could be possible that he enjoyed the functional paradigm, but pragmatically created a procedural language, given the hardware constraints.
I wonder if that last bit was as unfashionable a statement when he made it as it would be now.