4 ms·

Wow never thought of it that way. Can you provide an example of what your programs might look like? I'm pretty interested to know what style you are employing.

gruseom 18y ago
There's very little to it. As I said, sometimes a function is only a function. I'm wary of providing an example, because the discourse on programming languages is distorted by being conducted at the level of code snippets when what really matters is whole systems, which are harder to talk about. But since you asked, I went through my code and picked at random the first reasonable example of what I'm talking about: (defun ranges-intersect? (range1 range2) (destructuring-bind (c1 c2 r1 r2) range1 (destructuring-bind (xc1 xc2 xr1 xr2) range2 (return% (and (or (= c1 0) (= xc2 0) (> xc2 c1)) (or (= c2 0) (= xc1 0) (> c2 xc1)) (or (= r1 0) (= xr2 0) (> xr2 r1)) (or (= r2 0) (= xr1 0) (> r2 xr1))))))) (The ugly return% is because this code also compiles to Javascript, but that is another story.) See? It's just a function. In the past, I would have made a Range class with an Intersects method. Now, I don't, and my life is better. What's valuable is that this function isn't tied to other functions and it isn't tied to any state. That's what I mean by orthogonal. If I want to use this somewhere, I just use it. I'm not forced to pick up a whole glob of other stuff that's stuck to it. I'm not forced to create anything in order to call it - except a couple of lists of four numbers, if I don't have them handy, but this kind of thing is an order of magnitude more lightweight than defining specialized types and creating instances of them; especially since, if your object model is a rich one, your types inevitably reference other types, which makes creating things hard and forces you to jump through hoops just to get at one lousy function. Eventually people create entire technical disciplines called things like "dependency injection" and frameworks to jump through the hoops for them. No one seems to notice that they're taking a complicated thing and making it more complicated. You may object that writing "new Range(c1,c2,r1,r2)" isn't much different than "(list c1 c2 r1 r2)". All I can say is, yes it is, utterly different in a way that has profound implications for how I build programs - but this isn't the sort of thing that a code snippet can make clear. What's really going on here, I think, is that "functional programming" is just a tautology. No one has programmed without functions since the 1950s (assembly language excepted). But the facilities for defining functions were low-level for a long time, which made complex programs hard to write. One way of looking at OO is that it was an attempt to fix this problem by adding the abstractions of class and method over top of low-level functions. This turned out to be a mistake, I think. A much better fix is to just have higher-level functions.
- jamongkad 18y ago
  Oooohh thank you! Brain Level Up +1, honestly I would have done the same thing and created a Range Class as well.
  - gruseom 18y ago
    It depends on the language. In Java/C# I would create a Range class - it would cause more trouble not to.

gruseom 18y ago

There's very little to it. As I said, sometimes a function is only a function. I'm wary of providing an example, because the discourse on programming languages is distorted by being conducted at the level of code snippets when what really matters is whole systems, which are harder to talk about. But since you asked, I went through my code and picked at random the first reasonable example of what I'm talking about: (defun ranges-intersect? (range1 range2) (destructuring-bind (c1 c2 r1 r2) range1 (destructuring-bind (xc1 xc2 xr1 xr2) range2 (return% (and (or (= c1 0) (= xc2 0) (> xc2 c1)) (or (= c2 0) (= xc1 0) (> c2 xc1)) (or (= r1 0) (= xr2 0) (> xr2 r1)) (or (= r2 0) (= xr1 0) (> r2 xr1))))))) (The ugly return% is because this code also compiles to Javascript, but that is another story.) See? It's just a function. In the past, I would have made a Range class with an Intersects method. Now, I don't, and my life is better. What's valuable is that this function isn't tied to other functions and it isn't tied to any state. That's what I mean by orthogonal. If I want to use this somewhere, I just use it. I'm not forced to pick up a whole glob of other stuff that's stuck to it. I'm not forced to create anything in order to call it - except a couple of lists of four numbers, if I don't have them handy, but this kind of thing is an order of magnitude more lightweight than defining specialized types and creating instances of them; especially since, if your object model is a rich one, your types inevitably reference other types, which makes creating things hard and forces you to jump through hoops just to get at one lousy function. Eventually people create entire technical disciplines called things like "dependency injection" and frameworks to jump through the hoops for them. No one seems to notice that they're taking a complicated thing and making it more complicated. You may object that writing "new Range(c1,c2,r1,r2)" isn't much different than "(list c1 c2 r1 r2)". All I can say is, yes it is, utterly different in a way that has profound implications for how I build programs - but this isn't the sort of thing that a code snippet can make clear. What's really going on here, I think, is that "functional programming" is just a tautology. No one has programmed without functions since the 1950s (assembly language excepted). But the facilities for defining functions were low-level for a long time, which made complex programs hard to write. One way of looking at OO is that it was an attempt to fix this problem by adding the abstractions of class and method over top of low-level functions. This turned out to be a mistake, I think. A much better fix is to just have higher-level functions.

jamongkad 18y ago
Oooohh thank you! Brain Level Up +1, honestly I would have done the same thing and created a Range Class as well.
- gruseom 18y ago
  It depends on the language. In Java/C# I would create a Range class - it would cause more trouble not to.