5 ms·

IMO, it's something of a backlash against the rise of class-focused, object oriented languages (e.g. Java, C++, Ruby) leading to some complexity in the last dec

IMO, it's something of a backlash against the rise of class-focused, object oriented languages (e.g. Java, C++, Ruby) leading to some complexity in the last decade. Pendulum now swinging back the other way. Functional, data structure oriented programming has many benefits above old-school procedural programming e.g. C, Fortran. But it also doesn't have the baggage of mainstream OO languages. Thus, this feels like an appealing -- and new -- ecosystems. This -- along with a rediscovery of some functional concepts that seem have more importance in a distributed setting, like immutable data, purity, higher-order functions -- have led to some renewed interest.

seanmcdirmid 12y ago
This has gone on in academia for awhile, you are now considered mainstream if you embrace FP as the way, and you are considered a rebel if you instead believe that OOP is still the way. I predict that there will eventually be a FP backlash that reverses the situation again (hey, look how easy objects are to use vs. this crazy FP stuff!?).
- coolsunglasses 12y ago
  Question - why didn't you seek help in learning FP?
  - seanmcdirmid 12y ago
    I worked with Martin Odersky team for awhile, and I saw the way...was to use some FP and a lot of the cool OO stuff that Scala provided (traits!). Scala is one of the most advanced OO languages out there.
    - coolsunglasses 12y ago
      I'm very familiar with the PLT field, including OO languages like Scala and the history of its development. I was asking precisely because of your work on scalac. Much of your code had to get thrown out/refactored/cleaned up. The impression was that you didn't understand the FP part. Your recent comments on HN reinforce that. But that's besides the point. I'd like to find out what gaps can be filled so you no longer find FP difficult to understand or use. What material have you tried so far?
      - seanmcdirmid 12y ago
        That is complete BS, I didn't drink the Kool-Aid and was able to get the job done in a way that didn't use mega pattern matching functions, which are particularly loved by some (especially scalac) but not all. Martin also preferred lazy evaluation over incremental and reactive computation, and that was that. If you look at my recent IDE demoes (on YouTube or just see my papers), you'll see where Scala could have gone vs. where it is now. The Scala community eventually drifted away from OO, but it could have gone very differently.
- pcarbonn 12y ago
  Logic programming, the third programming paradigm, will come to the rescue...
  - seanmcdirmid 12y ago
    Sure, the database junkies will never give that up.
- FranOntanaya 12y ago
  I guess 2020 will be the year of procedural programming then.
  - seanmcdirmid 12y ago
    Why? Both OOP and FP are supersets of procedural programming, so in any case, it is the year of procedural programming already.
williamcotton 12y ago
Part of the issue with Object Oriented design is how they maintain state and deal with their dependencies. A pure function has a very portable interface that makes it suitable for the distributed and social nature of the way we create software together. These kinds of problems were not envisioned by the creators of the original Object Oriented systems like Smalltalk. Objects were designed for personal computers and building and using software designed for personal computers. While shared workspace environments were explored in systems like Self, they were always designed around the objects being these visual instances running in a GUI. Objects detached from a system like Self or Smalltalk lose a lot of their powers of abstraction. They are not and have never been portable, even if they were designed to be reusable.
- seanmcdirmid 12y ago
  > A pure function has a very portable interface that makes it suitable for the distributed and social nature of the way we create software together. Citation needed. I personally don't talk to other programmers in terms of functions, but I use plenty of metaphors and analogies that come with my evolutionary capabilities to use natural language (math, on the other hand, was something I had to learn).
  - williamcotton 12y ago
    I'm citing my own experience as a professional. Programmers talk to other programmers in terms of functions all the time. Every API you use exposes functionality. If that API assumes some sort of state, that can cause issues for the consumer of the API. It also forces whatever entity is maintaining state be tightly coupled to the consumer and leads to centralized systems. If the API does NOT have state and instead uses a token based system for authentication and access permissions it is operating in a functional manner. State is maintained outside of the function. The less coupled that two modules are the more portable that they are. You can bundle up something like the "express" npm package and ship that off to whomever. You can easily build modules on top of an express application by passing the entire app to another module. This pattern has been used to build an entire ecosystem of loosely coupled middleware. These are not Object Oriented designs. They aren't entities that communicate by sending messages to one another while floating around in some global workspace. They are interfaces that pass state around as arguments to function calls. Global state is very nicely demonstrated in how modules can be shared between Node and Browser Javascript. What is global? All of the I/O. Files, XHR, mouse clicks, sockets... all of these are the inputs and outputs and all are handled by "window" or "process" or other global state. Modules can be easily be reused between the server and client if they do not interface at all with any sort of global state.
CmonDev 12y ago
What about the baggage of the old-school functional languages?

seanmcdirmid 12y ago

This has gone on in academia for awhile, you are now considered mainstream if you embrace FP as the way, and you are considered a rebel if you instead believe that OOP is still the way. I predict that there will eventually be a FP backlash that reverses the situation again (hey, look how easy objects are to use vs. this crazy FP stuff!?).

coolsunglasses 12y ago
Question - why didn't you seek help in learning FP?
- seanmcdirmid 12y ago
  I worked with Martin Odersky team for awhile, and I saw the way...was to use some FP and a lot of the cool OO stuff that Scala provided (traits!). Scala is one of the most advanced OO languages out there.
  - coolsunglasses 12y ago
    I'm very familiar with the PLT field, including OO languages like Scala and the history of its development. I was asking precisely because of your work on scalac. Much of your code had to get thrown out/refactored/cleaned up. The impression was that you didn't understand the FP part. Your recent comments on HN reinforce that. But that's besides the point. I'd like to find out what gaps can be filled so you no longer find FP difficult to understand or use. What material have you tried so far?
    - seanmcdirmid 12y ago
      That is complete BS, I didn't drink the Kool-Aid and was able to get the job done in a way that didn't use mega pattern matching functions, which are particularly loved by some (especially scalac) but not all. Martin also preferred lazy evaluation over incremental and reactive computation, and that was that. If you look at my recent IDE demoes (on YouTube or just see my papers), you'll see where Scala could have gone vs. where it is now. The Scala community eventually drifted away from OO, but it could have gone very differently.
pcarbonn 12y ago
Logic programming, the third programming paradigm, will come to the rescue...
- seanmcdirmid 12y ago
  Sure, the database junkies will never give that up.
FranOntanaya 12y ago
I guess 2020 will be the year of procedural programming then.
- seanmcdirmid 12y ago
  Why? Both OOP and FP are supersets of procedural programming, so in any case, it is the year of procedural programming already.

williamcotton 12y ago

Part of the issue with Object Oriented design is how they maintain state and deal with their dependencies. A pure function has a very portable interface that makes it suitable for the distributed and social nature of the way we create software together. These kinds of problems were not envisioned by the creators of the original Object Oriented systems like Smalltalk. Objects were designed for personal computers and building and using software designed for personal computers. While shared workspace environments were explored in systems like Self, they were always designed around the objects being these visual instances running in a GUI. Objects detached from a system like Self or Smalltalk lose a lot of their powers of abstraction. They are not and have never been portable, even if they were designed to be reusable.

seanmcdirmid 12y ago
> A pure function has a very portable interface that makes it suitable for the distributed and social nature of the way we create software together. Citation needed. I personally don't talk to other programmers in terms of functions, but I use plenty of metaphors and analogies that come with my evolutionary capabilities to use natural language (math, on the other hand, was something I had to learn).
- williamcotton 12y ago
  I'm citing my own experience as a professional. Programmers talk to other programmers in terms of functions all the time. Every API you use exposes functionality. If that API assumes some sort of state, that can cause issues for the consumer of the API. It also forces whatever entity is maintaining state be tightly coupled to the consumer and leads to centralized systems. If the API does NOT have state and instead uses a token based system for authentication and access permissions it is operating in a functional manner. State is maintained outside of the function. The less coupled that two modules are the more portable that they are. You can bundle up something like the "express" npm package and ship that off to whomever. You can easily build modules on top of an express application by passing the entire app to another module. This pattern has been used to build an entire ecosystem of loosely coupled middleware. These are not Object Oriented designs. They aren't entities that communicate by sending messages to one another while floating around in some global workspace. They are interfaces that pass state around as arguments to function calls. Global state is very nicely demonstrated in how modules can be shared between Node and Browser Javascript. What is global? All of the I/O. Files, XHR, mouse clicks, sockets... all of these are the inputs and outputs and all are handled by "window" or "process" or other global state. Modules can be easily be reused between the server and client if they do not interface at all with any sort of global state.

CmonDev 12y ago

What about the baggage of the old-school functional languages?