Remember, a real engineer doesn’t want just a religion about how to solve the problem. Like ‘object-oriented’, or ‘functional’, or ‘imperative’, or ‘logic programming’. This piece of the problem wants to be a functional program. This piece of the program wants to be imperative. This piece wants to be object-oriented and guess what—this piece want to be logic-based. And they all want to work together usefully, because of the way the problem is structured.
—
Gerald Jay Sussman, We Really Don’t Know How to Compute!
Gerald Jay Sussman, We Really Don’t Know How to Compute!
Christian Hjalmarsson
on 01 Nov 11Word!!
EH
on 01 Nov 11What does this mean for my presenterFactory?!
Jimmy Chan
on 02 Nov 11Real Engineer just want to solve problem with simple purpose in mind.
37signals mantra
Nick
on 02 Nov 11As long as it runs in the cloud!
;)
Jeremy J Barth
on 02 Nov 11Another great quote from GJS, “One of the things every sorcerer will tell you, is that if you have the name of a spirit, you have power over it.” Could be profound. Probably just nerdy.
Deltaplan
on 02 Nov 11I’m sorry but, taken without any context, this quote is just plain wrong.
What’s a “piece of a program” ? Who did decide of its boundaries, why was that particular part of the program looked upon at the first place, why was it not split into two pieces, or maybe 20% of it could belong to another piece of the program, and it could take some things from a third one, etc…
All these are human decisions. And these decisions are made by incorporating some assumptions about the program, some conscious assumptions (the programming language and platform of the project for example), and also some unconscious ones (the developer being familiar with a particular programming style rather than with another one).
For example, for years I’ve been told that mathematical algorithms would be poorly implemented in object-oriented programming, that they needed procedural syntax… If it wasn’t by pure faith in oop, I would perhaps have found it plausible, since my early experiences with mathematical algorithms implemented in OOP have been mostly miserable. But after a few years of experimenting with that domain, learning and trying some design patterns and seeing which ones would work better than other ones, I’ve finally come to a point where I can clearly see how OOP can be a real blessing in implementing mathematical algorithms. The only thing is, to be able to do this, you can’t just use any OOP. You have to learn a kind of OOP that is suitable for such a work.
Another thing is that the programming style is highly dependent on the paradigms of some languages… OOP in Java has very little in common with OOP in JavaScript for example.
AC
on 02 Nov 11@37signals
Did you cut the quote off too early?
The quote above doesn’t actually answer it’s own question of what a real engineer wants.
Neil N
on 03 Nov 11If I had three “pieces” of the same program in each of OOP, Functional, and Imperative, I’d call it the most epic code smell of all time and immediately forward it to CodingHorror.com to be ridiculed for eternity
Michael
on 03 Nov 11I think what poor GJS is trying to say is that there is a better paradigm out there that our current programming paradigms derive from, but since he doesn’t know what it is the best he can say is that we would see pieces of our current paradigms in it.
Teja
on 05 Nov 11This feels out of context & doesn’t make any sense at all. How do you structure part of your app to be written functionally and part of the app in an OO way?
Joe
on 08 Nov 11dhh said it best: “Top phrase used to deflect comparison and criticism from technical solutions: “Use the right tool for the job”. It’s such a lazy reach. Like sticking fingers in your ears and going la-la-la. Not everything is equally good. Often different = worse.”
This discussion is closed.