6 ms·

Lisp really is an eye-opening experience when learning to structure programs and computations. Stumbling on Lisp in college was a fascinating experience for me

Lisp really is an eye-opening experience when learning to structure programs and computations. Stumbling on Lisp in college was a fascinating experience for me in particular because I had been raised around C++ and Java, and my programming life up to that point had been a struggle understanding how to abstract a program into objects and how to build those objects' interfaces. Once I started down the path of functional programming and Clojure, it became clear in retrospect that "objects" as C++ and Java envisioned them were poor fits for most problem domains, which is why their purpose never clicked in my head. Reducing data down to...well, data, and methods down to functions, and programs down to pyramids of expression calls made everything about program structure click in my head. Functional, expression-based style was FAR more intuitive to my brain than stateful object style. I now try to lean heavily into expressions and referential transparency no matter what language I use, though some languages make it easier than others. Funnily enough, C program structure came much more naturally to me than either C++ or Java. Maybe because it's easy to decouple data from operations on that data, even if stateful. Hard to say.

monsieurbanana 2y ago
> Maybe because it's easy to decouple data from operations on that data, even if stateful You can use objects in C++ and Java without mixing code and data (by having data-only and code-only classes for example). I haven't fully read it, but there's a book from a clojure developer about about this: https://www.manning.com/books/data-oriented-programming https://www.manning.com/books/data-oriented-programming The book itself uses Java, not Clojure.
- netbioserror 2y ago
  I know Java programmers use static-method classes, which are just like modules in newer languages. Which just further illustrates the point. It's a hack on top of a language that requires everything to be defined inside of a class. That layer of abstraction on top of things that could be much simpler kills understanding. It massively complicates answering the question "What even is a class?" for a learner. I also realize C++ has simple structs, and classes can be avoided entirely, but that's definitely not the way the language is taught. Maybe I needed to "git gud", but learning Lisp enabled a career building valuable products currently in production. Java and C# were a roadblock on the way to my current productivity.
  - monsieurbanana 2y ago
    I didn't expect that much negativity regarding my comment, I never implied you need to "git gud". I'm happy in my Clojure job and I would rather not work with OO languages, and that's definitely not how they're taught, but if/when you're forced to use them you can choose not to follow the traditional way and instead write them in a more functional/data oriented way.
    - netbioserror 2y ago
      I didn't intend a negative tone and that's hard to convey in text.
- smokel 2y ago
  Sorry for going off-topic, but why is this comment being downvoted? The comment provides an alternative view on things and even links to a nice book. One may not agree with the perspective, but that's no reason to downvote. Perhaps it's the user interface (a special upvoting wand would be most welcome for those of us whose fingers are too fat). Or have we reached the stage where script kiddies deploy downvoting bots if they didn't like a comment in another thread?
- markc 2y ago
  >The book itself uses Java, not Clojure. Almost all of the code examples in the book are in JavaScript (not Java) though a significant feature of Sharvit's approach is that it decouples Data Oriented Programming from any specific language. As a Clojure geek, I highly recommend the book as the way to achieve some of Clojure's core virtues in other languages.
smokel 2y ago
The OO patterns are still quite popular in enterprise software, where people mostly work in large teams. Hiding implementation details is terribly annoying for a single developer, but can be a great way to reduce complexity for other team members. The same consideration applies to other powerful constructs, such as static typing, garbage collection, operator overloading, and macros. Whether you work alone or in a team can significantly influence how one appreciates such features.
- depaulagu 2y ago
  There’s nothing stopping you from hiding implementation details in a functional paradigm, no need for objects or other OO patterns.
  - renanoliveira0 2y ago
    I could certainly be wrong, but that doesn't seem to be the case to me. When you completely separate routines from the data, you end up coupling the code that calls the routine with the data it’s passing. I don’t see how it would be possible to maintain that level of separation while achieving the same level of isolation that’s possible with objects, where it’s possible to truly know nothing about the data in a given interaction. I’m referring here to the purest aspect, in terms of pure functions. At some point, the data has to come from an impure source, and honestly, I don’t see why a closure would be better than an object—practically, they’re the same thing.
taylodl 2y ago
A big piece of OO development is state management. If you're modeling a system having several interacting entities whose interactions may vary based off that entity's current state - then OO is most likely the way to go. You can encapsulate that state management in one place rather than having it strewn throughout the entire codebase. If you're doing information-oriented processing, whether it be a traditional batch process, or a decision-support system reacting in real time to incoming data - then functional is most like the way to go. If you're doing corporate CRUD development, then just use JavaScript (assuming Web CRUD) and the popular CRUD framework du jour. This is what it means to use the right tool for the right job. There is no perfect language that excels at everything. It all depends on what you need to do.
- slowmovintarget 2y ago
  The classic mistake most programmers made with OO is to translate the business domain objects to classes with behavior. While this allowed for some interesting cases like with Naked Objects, it was usually not the most useful way to analyze a system and encapsulate application functionality. The better way to employ OOA&D was to divide the system functions up into classes. You have an object that manages connection pools and an object that serializes data, and an object that manages tasks... These were the more useful abstractions, because for business systems we're generally not doing simulation. The state of the system encapsulated in these objects was the operational state of the stack, not the user state which was just more data to throw around. Abstracted this way, however, you get roughly the same kind of system over and over again. How boring! That way leads to frameworks... Which is also what you saw in the late 90s and early 2000s. It's because for most business applications the abstractions of the system, as opposed to the business domain, are so very close to the same that you can, in fact, codify those into cookie-cutter apps where only the domain data being passed around differs. Functional programming starts you in this state of abstraction, which is why it tends to be simpler for business systems.
- anthk 2y ago
  CL can do OO programming too.
  - 2y ago

monsieurbanana 2y ago

> Maybe because it's easy to decouple data from operations on that data, even if stateful You can use objects in C++ and Java without mixing code and data (by having data-only and code-only classes for example). I haven't fully read it, but there's a book from a clojure developer about about this: https://www.manning.com/books/data-oriented-programming https://www.manning.com/books/data-oriented-programming The book itself uses Java, not Clojure.

netbioserror 2y ago
I know Java programmers use static-method classes, which are just like modules in newer languages. Which just further illustrates the point. It's a hack on top of a language that requires everything to be defined inside of a class. That layer of abstraction on top of things that could be much simpler kills understanding. It massively complicates answering the question "What even is a class?" for a learner. I also realize C++ has simple structs, and classes can be avoided entirely, but that's definitely not the way the language is taught. Maybe I needed to "git gud", but learning Lisp enabled a career building valuable products currently in production. Java and C# were a roadblock on the way to my current productivity.
- monsieurbanana 2y ago
  I didn't expect that much negativity regarding my comment, I never implied you need to "git gud". I'm happy in my Clojure job and I would rather not work with OO languages, and that's definitely not how they're taught, but if/when you're forced to use them you can choose not to follow the traditional way and instead write them in a more functional/data oriented way.
  - netbioserror 2y ago
    I didn't intend a negative tone and that's hard to convey in text.
smokel 2y ago
Sorry for going off-topic, but why is this comment being downvoted? The comment provides an alternative view on things and even links to a nice book. One may not agree with the perspective, but that's no reason to downvote. Perhaps it's the user interface (a special upvoting wand would be most welcome for those of us whose fingers are too fat). Or have we reached the stage where script kiddies deploy downvoting bots if they didn't like a comment in another thread?
markc 2y ago
>The book itself uses Java, not Clojure. Almost all of the code examples in the book are in JavaScript (not Java) though a significant feature of Sharvit's approach is that it decouples Data Oriented Programming from any specific language. As a Clojure geek, I highly recommend the book as the way to achieve some of Clojure's core virtues in other languages.

smokel 2y ago

The OO patterns are still quite popular in enterprise software, where people mostly work in large teams. Hiding implementation details is terribly annoying for a single developer, but can be a great way to reduce complexity for other team members. The same consideration applies to other powerful constructs, such as static typing, garbage collection, operator overloading, and macros. Whether you work alone or in a team can significantly influence how one appreciates such features.

depaulagu 2y ago
There’s nothing stopping you from hiding implementation details in a functional paradigm, no need for objects or other OO patterns.
- renanoliveira0 2y ago
  I could certainly be wrong, but that doesn't seem to be the case to me. When you completely separate routines from the data, you end up coupling the code that calls the routine with the data it’s passing. I don’t see how it would be possible to maintain that level of separation while achieving the same level of isolation that’s possible with objects, where it’s possible to truly know nothing about the data in a given interaction. I’m referring here to the purest aspect, in terms of pure functions. At some point, the data has to come from an impure source, and honestly, I don’t see why a closure would be better than an object—practically, they’re the same thing.

taylodl 2y ago

A big piece of OO development is state management. If you're modeling a system having several interacting entities whose interactions may vary based off that entity's current state - then OO is most likely the way to go. You can encapsulate that state management in one place rather than having it strewn throughout the entire codebase. If you're doing information-oriented processing, whether it be a traditional batch process, or a decision-support system reacting in real time to incoming data - then functional is most like the way to go. If you're doing corporate CRUD development, then just use JavaScript (assuming Web CRUD) and the popular CRUD framework du jour. This is what it means to use the right tool for the right job. There is no perfect language that excels at everything. It all depends on what you need to do.

slowmovintarget 2y ago
The classic mistake most programmers made with OO is to translate the business domain objects to classes with behavior. While this allowed for some interesting cases like with Naked Objects, it was usually not the most useful way to analyze a system and encapsulate application functionality. The better way to employ OOA&D was to divide the system functions up into classes. You have an object that manages connection pools and an object that serializes data, and an object that manages tasks... These were the more useful abstractions, because for business systems we're generally not doing simulation. The state of the system encapsulated in these objects was the operational state of the stack, not the user state which was just more data to throw around. Abstracted this way, however, you get roughly the same kind of system over and over again. How boring! That way leads to frameworks... Which is also what you saw in the late 90s and early 2000s. It's because for most business applications the abstractions of the system, as opposed to the business domain, are so very close to the same that you can, in fact, codify those into cookie-cutter apps where only the domain data being passed around differs. Functional programming starts you in this state of abstraction, which is why it tends to be simpler for business systems.
anthk 2y ago
CL can do OO programming too.
- 2y ago