3 ms·
I’ve long thought that Smalltalk is as much a functional programming language as an object-oriented one, if not more so. From what I’ve seen, idiomatic Smalltal
by bradrn 5y ago
I’ve long thought that Smalltalk is as much a functional programming language as an object-oriented one, if not more so. From what I’ve seen, idiomatic Smalltalk code is constructed largely using anonymous functions, higher-order functions, function chaining, and other forms of function composition — hallmarks of more traditional functional languages. The object-oriented nature of Smalltalk becomes most apparent when looking at higher-level architecture, where it becomes obvious that programs are constructed of interacting things using each others’ methods.
In fact, continuing along these lines, it occurs to me that many systems seem to tend towards a similar design: functional programming at the small scale, object-oriented patterns at a larger scale. Quite aside from Smalltalk, this also arises in Haskell, with various effect systems (e.g. MTL) providing the statefulness, encapsulation and late-binding which in other languages is encoded in dedicated OOP syntax. On the other hand, I have less experience outside Haskell (I am but a mere hobbyist programmer), so I don’t really know how well this theory holds up elsewhere.
- jsmith45 5y agoI think to the extent that that a program needs interactivity whether via network, or some form of user interface, it is pretty normal to see something at least vaugely OOPish if you squint right in the overall program structure. This can be (among others): an actor system, an effect system, a struct full of function pointers approach, or native OOP support. I also don't think you are wrong that Smalltalk tends to be more functional than many other languages that call themselves "object oriented", which tend to emphasize a more procedural and imperative style (e.g. use of for loops instead of functions like map) of programming functions/methods. And your big picture OO-ish, small scale functional observation does sound about right, at least for languages that are more functionally aligned. Erlang uses its actor pattern mostly for the large scale organization, with details generally being pretty normal functional code. Even in procedural languages there is a growing tendency to add features to make functional style programming easier, and growing recognition that immutable data is easier to reason about, etc.