5 ms·

I agree, OO is ultimately good enough. Problem is, coding using OOP is like printing ideas on paper: you dont wanna do that because it's hard to discard ideas t

I agree, OO is ultimately good enough. Problem is, coding using OOP is like printing ideas on paper: you dont wanna do that because it's hard to discard ideas that's been printed on paper. You wanna use post-its instead because post-its are easy to discard. Refactoring is hard using OO and refactoring is the key difference between waterfall and good software development. Refactoring is easier, even fun, using functional programming because the medium is more malleable.

flavio81 9y ago
>I agree, OO is ultimately good enough. And Common Lisp has arguably the most flexible and powerful OOP system around, CLOS. Why don't write OOP in Lisp? It is done successfully by lispers around the world.
- kamaal 9y ago
  >>Why don't write OOP in Lisp? Because most people understand OO as some kind of namespace scheme. Basically to bunch together functionality under a name(class). When people talk of OO, most of them, are actually talking about modularizing code.
  - deleted 9y ago
    [deleted]
  - goatlover 9y ago
    That's modules or packages. OO includes inheritance, polymorphism and treating objects as black boxes (little computers in Alan Kay's mental model) with messages they respond to, or APIs for working with that kind of object. It's a lot more than simply being a namespace. It's also that idea that an object has state and behavior, with appropriate semantics for dealing with both (depending on the language). Objects (with classes or prototypes) act as a new kind of data type bundled with functionality for handling that data, which is more than just putting a bunch of functions and variables into a namespace. So you can treat your class/prototype as a built-in complex data type. You're extending the type system in an encapsulated manner. It's not called Namespace Oriented Programming
Retric 9y ago
Refactoring lisp gets harder the more complex the program gets. Approachs that are clever and reasonable for a 1000 line program can become hell in a 100,000 line program. Effectively programming languages get less powerful the longer the program becomes. Breaking up programs into more powerful little pieces is never a clean separation and you need to make real trade offs between more separation and more power.
- DannyB2 9y ago
  > Refactoring lisp gets harder the more complex the program gets. I have found that to be true in dynamically or duck typed languages. I have found it to be not true in strongly typed languages with good tooling. Example: refactoring large java program in, say, Eclipse. > Breaking up programs into more powerful little pieces is never a clean separation I would tend to disagree, to some extent. In Lisp(s), there are lots of small, sometimes obviously correct functions that do powerful operations on abstract data structures. Part of the reason for this is that unlike OOP (and I write Java daily) which has lots of data structures, Lisp has very few. In OOP you model your domain with new classes. In Lisp you model your domain with combinations of a few basic structures. (In Clojure...) List, Set, Array, Map. Maybe you have layers of separation. With one layer being between primitives that manipulate your domain objects, and another layer being the logic that decides how and when to do the manipulations. I want to solve a puzzle. The puzzle board has various states, pieces, and operations that transform a board into a new board state. Then the logic layer is an algorithm or algorithms written using the layer of primitive manipulations. That logic layer may, in fact, use canned algorithms, because the data structures are common primitives. Say, sort, search, A* search, depth first, breadth first, reduce, map fn over a sequence, etc. You can end up with a large program. But it can be a lot easier to reason about than, say, a large Java program. It seems to take more deliberate effort to keep a large java program easy to reason about.
  - Retric 9y ago
    > layers of separation Layers are exactly the kind of power trade-off I am talking about. If code X can't(1) impact code Y, you have less freedom in code X because it can't do some things, but can more easily reason about code Y. (1) either as an actual limit or a self imposed one. Granted, in theory you may be able to find perfect points of separation such that you don't lose power by doing so.
skybrian 9y ago
You'll have to substantiate that, because refactoring Java is pretty easy if you have a good IDE. In many other languages, you're lucky if you can reliably rename a function without having to manually check for false positives, let alone something complicated like change signature or extract superclass. Also, in any statically typed language, you can fall back on changing the function and using compile errors to tell you all the calls that need to be updated.
- quadcore 9y ago
  refactoring Java is pretty easy if you have a good IDE rename a function Refactoring in software development is not the same as refactoring in IDEs. Refactoring in software development is changing existing code. Specially the architectural parts.
  - skybrian 9y ago
    Could you explain what you mean? As far as I know it's the same process. Changing the architecture often involves a large number of small, safe code changes, many of which can be handled by IDE's and other software tools.

flavio81 9y ago

>I agree, OO is ultimately good enough. And Common Lisp has arguably the most flexible and powerful OOP system around, CLOS. Why don't write OOP in Lisp? It is done successfully by lispers around the world.

kamaal 9y ago
>>Why don't write OOP in Lisp? Because most people understand OO as some kind of namespace scheme. Basically to bunch together functionality under a name(class). When people talk of OO, most of them, are actually talking about modularizing code.
- deleted 9y ago
  [deleted]
- goatlover 9y ago
  That's modules or packages. OO includes inheritance, polymorphism and treating objects as black boxes (little computers in Alan Kay's mental model) with messages they respond to, or APIs for working with that kind of object. It's a lot more than simply being a namespace. It's also that idea that an object has state and behavior, with appropriate semantics for dealing with both (depending on the language). Objects (with classes or prototypes) act as a new kind of data type bundled with functionality for handling that data, which is more than just putting a bunch of functions and variables into a namespace. So you can treat your class/prototype as a built-in complex data type. You're extending the type system in an encapsulated manner. It's not called Namespace Oriented Programming

Retric 9y ago

Refactoring lisp gets harder the more complex the program gets. Approachs that are clever and reasonable for a 1000 line program can become hell in a 100,000 line program. Effectively programming languages get less powerful the longer the program becomes. Breaking up programs into more powerful little pieces is never a clean separation and you need to make real trade offs between more separation and more power.

DannyB2 9y ago
> Refactoring lisp gets harder the more complex the program gets. I have found that to be true in dynamically or duck typed languages. I have found it to be not true in strongly typed languages with good tooling. Example: refactoring large java program in, say, Eclipse. > Breaking up programs into more powerful little pieces is never a clean separation I would tend to disagree, to some extent. In Lisp(s), there are lots of small, sometimes obviously correct functions that do powerful operations on abstract data structures. Part of the reason for this is that unlike OOP (and I write Java daily) which has lots of data structures, Lisp has very few. In OOP you model your domain with new classes. In Lisp you model your domain with combinations of a few basic structures. (In Clojure...) List, Set, Array, Map. Maybe you have layers of separation. With one layer being between primitives that manipulate your domain objects, and another layer being the logic that decides how and when to do the manipulations. I want to solve a puzzle. The puzzle board has various states, pieces, and operations that transform a board into a new board state. Then the logic layer is an algorithm or algorithms written using the layer of primitive manipulations. That logic layer may, in fact, use canned algorithms, because the data structures are common primitives. Say, sort, search, A* search, depth first, breadth first, reduce, map fn over a sequence, etc. You can end up with a large program. But it can be a lot easier to reason about than, say, a large Java program. It seems to take more deliberate effort to keep a large java program easy to reason about.
- Retric 9y ago
  > layers of separation Layers are exactly the kind of power trade-off I am talking about. If code X can't(1) impact code Y, you have less freedom in code X because it can't do some things, but can more easily reason about code Y. (1) either as an actual limit or a self imposed one. Granted, in theory you may be able to find perfect points of separation such that you don't lose power by doing so.

skybrian 9y ago

You'll have to substantiate that, because refactoring Java is pretty easy if you have a good IDE. In many other languages, you're lucky if you can reliably rename a function without having to manually check for false positives, let alone something complicated like change signature or extract superclass. Also, in any statically typed language, you can fall back on changing the function and using compile errors to tell you all the calls that need to be updated.

quadcore 9y ago
refactoring Java is pretty easy if you have a good IDE rename a function Refactoring in software development is not the same as refactoring in IDEs. Refactoring in software development is changing existing code. Specially the architectural parts.
- skybrian 9y ago
  Could you explain what you mean? As far as I know it's the same process. Changing the architecture often involves a large number of small, safe code changes, many of which can be handled by IDE's and other software tools.