3 ms·

+1 abstract and 0 Neutral. I thought the imperative vs object oriented was strange, since they are the same thing.

teapot7 1y ago
Yes! The number of lousy articles and blog posts I've seen that talk about "imperative, oo and functional programming"...
josephg 1y ago
Mmm I don’t think I agree. The way I structure code in C or rust is subtly different than how I’d write the same program in Java. OO python or Ruby looks different from data oriented Python or Ruby. They’re all imperative programs though. “OO vs Imperative” isn’t the right name for that design choice.
- kqr 1y ago
  The way I was taught "imperative" encompasses both "object-oriented" and "procedural", much like "declarative", the opposite of imperative, captures both functional and logic.
  - josephg 1y ago
    It’s in the word. “Imperative” means something like “urgent demand to action”. Imperative code is code where each line is a command for the computer to do something. Like functions in C - which are made of a list of statements that get executed immediately when they get visited. C++ and Java are imperative languages because functions are expressed as a list of imperative statements. But there’s nothing inherently imperative about structs and classes. Or any of the concepts of OO. You could have encapsulation, inheritance and polymorphism in a functional language just fine if you wanted to. Haskell fits the bill already - well, depending on your definition of OO.
- Supermancho 1y ago
  This is an excellent talk explaining how procedural (imperative) came to be OO - which are abstractions over procedural statements: https://www.youtube.com/watch?v=mrY6xrWp3Gs https://www.youtube.com/watch?v=mrY6xrWp3Gs To summarize: Block scope is procedural. Wrapping that up in other abstractions like objects, which are fancy closures, eventually ends up in OO. When talking about OO, people often conflate the data design with the program abstractions. Ofc you program differently in languages that have dedicated data structures and idioms around domain driven design^1, which take advantage of imperative execution within those mechanisms as well. eg Java Spring - Spring has a lifecycle. It's imperative. Beans and other annotations have a lifecycle. It's also imperative. ^1 Domain driven design is still the norm and any efficiency observed from circumventing (or ignoring) the design is considered novel, which should inform the industry that there might be a better way. Good enough wins out again.

Yes! The number of lousy articles and blog posts I've seen that talk about "imperative, oo and functional programming"...

josephg 1y ago

Mmm I don’t think I agree. The way I structure code in C or rust is subtly different than how I’d write the same program in Java. OO python or Ruby looks different from data oriented Python or Ruby. They’re all imperative programs though. “OO vs Imperative” isn’t the right name for that design choice.

kqr 1y ago
The way I was taught "imperative" encompasses both "object-oriented" and "procedural", much like "declarative", the opposite of imperative, captures both functional and logic.
- josephg 1y ago
  It’s in the word. “Imperative” means something like “urgent demand to action”. Imperative code is code where each line is a command for the computer to do something. Like functions in C - which are made of a list of statements that get executed immediately when they get visited. C++ and Java are imperative languages because functions are expressed as a list of imperative statements. But there’s nothing inherently imperative about structs and classes. Or any of the concepts of OO. You could have encapsulation, inheritance and polymorphism in a functional language just fine if you wanted to. Haskell fits the bill already - well, depending on your definition of OO.
Supermancho 1y ago
This is an excellent talk explaining how procedural (imperative) came to be OO - which are abstractions over procedural statements: https://www.youtube.com/watch?v=mrY6xrWp3Gs https://www.youtube.com/watch?v=mrY6xrWp3Gs To summarize: Block scope is procedural. Wrapping that up in other abstractions like objects, which are fancy closures, eventually ends up in OO. When talking about OO, people often conflate the data design with the program abstractions. Ofc you program differently in languages that have dedicated data structures and idioms around domain driven design^1, which take advantage of imperative execution within those mechanisms as well. eg Java Spring - Spring has a lifecycle. It's imperative. Beans and other annotations have a lifecycle. It's also imperative. ^1 Domain driven design is still the norm and any efficiency observed from circumventing (or ignoring) the design is considered novel, which should inform the industry that there might be a better way. Good enough wins out again.