oop is one pararadigm. the other is funcfional. Both together. So oopme up with scala or fsharp running on a virtual machine.
No, it's a book: small, bound, available in book stores. But you made me look in the high energy physics search engine (now known as INSPIRE, it used to be SPIRES), and while I find lots of publications about related topics (SPEAR, SSRL, accelerator control, control system programming ...), none about objects, and none with a name that rings a bell. And I know that I was never a co-author on any paper with the author of the book ... one of the things that ended my career at SLAC was that I had no interest in what is called "machine physics", the art and science of building and operating accelerators. I was always an instrumentation and data analysis person.
That’s what Ivan Čukić is preaching
At the lowest level, isn't OOP functional? Object methods that implement something like read a register, increment a value, I think is fundamentally "functional".That’s what Ivan Čukić is preaching
Solitaire was AI back in the day....
I've found it depends highly on the problem you are solving.
Same problem. Timer X is an interface that uses methods start() and stop(). Timer Y uses methods start() and stop(). If class A wants to "implement interfaces" X and Y, the resulting code will be difficult to read, since every time start() or stop() are used it needs to be disambiguated.
For fun, object orientation with sbcl,
;; functions returned as messages
(define w1 100)
> (w1 . 100)
((w1 'withdraw) 50)
> (w1 . 50)
((w1 'withdraw) 75)
> "Insufficient funds"
;; functions only
(define w2 100)
> (w2 . 100)
(make-deposit 20 w2)
> (w2 . 120)
(make-withdraw 150 w2)
> "Insufficient funds"Totally agree with your second sentence. I would even like to generalize it to become the single most important religious dogma in software engineering: #0 THERE ARE NOT RELIGIOUS DOGMAS IN SOFTWARE ENGINEERING. Always do what is appropriate for the situation. That means the problem domain, the performance characteristics (speeds and feeds), the deployment situation (quick prototype versus architecture that needs to survive for decades), the strength, size and weaknesses of the team, and so on. And all of these decisions are tradeoffs, in which different people (of different experiences, different ways to looking at questions, different strengths) can disagree on.
On that question, I happen to sit on the comfortable and wide railing on top of the fence. I find many situations where MI is useful. But the tradeoff is that MI adds complexity, in how to think about the source code. Say class X has two base classes, A and B. What if both A and B define a method foo(), which one will be called? What if both A and B derive eventually from a common origin class O, and perhaps O also has foo(), now which one will be called? If EVERYONE involved in the team that implements AND MAINTAINS the source code knows how to answer the question, and understands why we (together, after consultation) chose to implement X to inherit from both A and B, then none of this is a problem. In the real world, it is difficult to maintain that invariant. I would love to put into the source code the following lines:
assert(programer is skilled);
assert(programmer understands OO A&D);
assert(programmer has learned how MI works);
test_score = perform(give programmer quiz on MI);
assert(test_score > 0.8);
class X: public A, public B (
...
#lang racket
(define counter%
(class object%
(super-new)
(init-field x)
(define/public (setx x2)
(new this% [x x2]))
(define/public (add1)
(new this% [x (+ x 1)]))
(define/public (getx)
x )))
(define c (new counter% (x 3)))
(set! c (send c setx 5))
(set! c (send c add1))
(define res (send c getx))
(print res)