5 ms·

I think the types of problems each programmer tends to confront make up a large part of the disconnect between the ones who "drink the koolaid" of a programming

I think the types of problems each programmer tends to confront make up a large part of the disconnect between the ones who "drink the koolaid" of a programming paradigm or process and the people who are unimpressed. I typically do games. Games are useful to think, in part, in OOP terms; there is very little "data flow" and (typically) there are a lot of objects that need to interact in asynchronous ways. There are specific parts that could be reduced to flow based programming (FBP), but it seems like the wrong paradigm for writing an entire game, as an example close to me. I could imagine FBP certain AI logic state machines being useful, for instance. But other areas of development have flow-style tools and that's clearly the right way to write code. Signal processing is an obvious example: When you want to send an audio signal through a reverb, split it to two different types of processors and re-merge it later with a fader tied to an external control, laying those components out with boxes is 1000x better than trying to write code in text to do the same thing. So I think articles like this are useful to introduce everyone to various other paradigms, in case they might be applicable to a problem that you're working on. But it's never a "silver bullet" simply because each tool works best in certain problem domains. A friend tried to convince me that I should drink the functional programming koolaid, for instance, but on drilling deeper I found that he had never worked on a game, and didn't really grok what kinds of code you would normally end up putting in a game. What I'd love to see is an article that compared a lot of different processes and paradigms and talked about where each is most useful. Especially if that article surprised me. :) Problem is that most people are familiar with their own areas and toolsets; we'd probably need a team of people from different specialties to collaborate on it. Maybe a wiki where people could add in their experiences trying each approach or tool on their own problem domains? Then when someone does use functional programming to write a game, they could talk about the pros and cons and the kind of game they wrote. And that would be useful data.

agentultra 12y ago
> I think the types of problems each programmer tends to confront make up a large part of the disconnect between the ones who "drink the koolaid" of a programming paradigm or process and the people who are unimpressed. Sounds a lot like selection bias. Even in games there is a growing movement to stop the OOP paradigm and focus on data-oriented or "data flow". It's hard to know whether there are universally-applicable truths in a given paradigm... but it's rather nice to have the option. Flow-based tools are becoming popular in procedural content generation, have been in audio/music/dsp for some time, and are probably quite useful in other sort of "pipeline" analogies. But certainly past experience will play a large role in determining which tools you think are applicable to a given problem.
- SomeCallMeTim 12y ago
  Selection bias implies that people just like what they're familiar with; I'm sure that does keep people from switching to new tools, but that's not what I'm referring to. I'm talking about people who actually try new tools and reject them as useful to their problem domains; I try a lot of new tools, and some fit with the problems I solve better than others. I didn't quite remember what "data oriented meant," but a quick search brought up this article [1] on using data-driven design in games. It brings up some important points, but really the point of data flow design seems to be optimization and efficiency rather than making it easier to write the code. And I'm all for that, and I thank you for making me look that up since I will likely use that idea, but I'll keep my text editor for most of the game development I do going forward. Except maybe the particle systems, which as the article below points out, are typically already data oriented, and have had good data-flow-based tools for years. ;) [1] http://gamesfromwithin.com/data-oriented-design http://gamesfromwithin.com/data-oriented-design
  - agentultra 12y ago
    I think you're referring to confirmation bias which is related but not quite the same. Never the less I understand what you're getting at. I took it to mean that the kinds of problems a programmer encounters is not sufficiently random to properly determine the usefulness of a given language or "paradigm." Which may keep people from switching to new, better tools (or from trying them out at all). The data-oriented design thing is interesting and something I've heard come and go over the years. Check out: http://www.dataorienteddesign.com/dodmain/ http://www.dataorienteddesign.com/dodmain/ and https://www.youtube.com/watch?v=ZHqFrNyLlpA https://www.youtube.com/watch?v=ZHqFrNyLlpA A video demonstration of Jai; a new compiler from Jonathan Blow designed around this paradigm. Cheers!
    - SomeCallMeTim 12y ago
      Ahh, I see. Yeah, I guess I meant that each paradigm is inherently a different value for different domains, and so therefore has a different value for programmers who specialize in their domain(s). And when someone checks out a paradigm that doesn't match their domain, they may end up complaining about how the tool isn't good. Love the links. Listening to Blow talk now. Will look at the longer book later.
robhawkes 12y ago
"There are specific parts that could be reduced to flow based programming (FBP), but it seems like the wrong paradigm for writing an entire game, as an example close to me." Very much so! While I disagree slightly (a game could definitely be created this way – I have a background in game development), I'm 100% behind the statement that not everything has to be FBP. In my case, I'm using FBP for one specific part of my application that dynamically manipulates large quantities of data – FBP made sense. As for the rest of the application, FBP could work but it would be because I want to implement it in FBP rather than using FBP because it's better at solving the problem at hand. My intention with this article is to try and offer a fair view of one potential approach (out of many). I make a deliberate effort to try not to dictate what people should be using, rather leave it up to them to decide if it fits.

agentultra 12y ago

> I think the types of problems each programmer tends to confront make up a large part of the disconnect between the ones who "drink the koolaid" of a programming paradigm or process and the people who are unimpressed. Sounds a lot like selection bias. Even in games there is a growing movement to stop the OOP paradigm and focus on data-oriented or "data flow". It's hard to know whether there are universally-applicable truths in a given paradigm... but it's rather nice to have the option. Flow-based tools are becoming popular in procedural content generation, have been in audio/music/dsp for some time, and are probably quite useful in other sort of "pipeline" analogies. But certainly past experience will play a large role in determining which tools you think are applicable to a given problem.

SomeCallMeTim 12y ago
Selection bias implies that people just like what they're familiar with; I'm sure that does keep people from switching to new tools, but that's not what I'm referring to. I'm talking about people who actually try new tools and reject them as useful to their problem domains; I try a lot of new tools, and some fit with the problems I solve better than others. I didn't quite remember what "data oriented meant," but a quick search brought up this article [1] on using data-driven design in games. It brings up some important points, but really the point of data flow design seems to be optimization and efficiency rather than making it easier to write the code. And I'm all for that, and I thank you for making me look that up since I will likely use that idea, but I'll keep my text editor for most of the game development I do going forward. Except maybe the particle systems, which as the article below points out, are typically already data oriented, and have had good data-flow-based tools for years. ;) [1] http://gamesfromwithin.com/data-oriented-design http://gamesfromwithin.com/data-oriented-design
- agentultra 12y ago
  I think you're referring to confirmation bias which is related but not quite the same. Never the less I understand what you're getting at. I took it to mean that the kinds of problems a programmer encounters is not sufficiently random to properly determine the usefulness of a given language or "paradigm." Which may keep people from switching to new, better tools (or from trying them out at all). The data-oriented design thing is interesting and something I've heard come and go over the years. Check out: http://www.dataorienteddesign.com/dodmain/ http://www.dataorienteddesign.com/dodmain/ and https://www.youtube.com/watch?v=ZHqFrNyLlpA https://www.youtube.com/watch?v=ZHqFrNyLlpA A video demonstration of Jai; a new compiler from Jonathan Blow designed around this paradigm. Cheers!
  - SomeCallMeTim 12y ago
    Ahh, I see. Yeah, I guess I meant that each paradigm is inherently a different value for different domains, and so therefore has a different value for programmers who specialize in their domain(s). And when someone checks out a paradigm that doesn't match their domain, they may end up complaining about how the tool isn't good. Love the links. Listening to Blow talk now. Will look at the longer book later.

robhawkes 12y ago

"There are specific parts that could be reduced to flow based programming (FBP), but it seems like the wrong paradigm for writing an entire game, as an example close to me." Very much so! While I disagree slightly (a game could definitely be created this way – I have a background in game development), I'm 100% behind the statement that not everything has to be FBP. In my case, I'm using FBP for one specific part of my application that dynamically manipulates large quantities of data – FBP made sense. As for the rest of the application, FBP could work but it would be because I want to implement it in FBP rather than using FBP because it's better at solving the problem at hand. My intention with this article is to try and offer a fair view of one potential approach (out of many). I make a deliberate effort to try not to dictate what people should be using, rather leave it up to them to decide if it fits.