Re: Language Oriented Programming
- From: Thomas Gagne <tgagne@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 02 Aug 2005 07:26:55 -0400
Robert C. Martin wrote:
On 18 Jul 2005 22:46:21 -0700, raxitsheth@xxxxxxxxx wrote:
Hello All...
http://www.onboard.jetbrains.com/is1/articles/04/10/lop/
Above link is Language Oriented Programming...(It might be Beyond OOP...) I have gone thru the link ,Its Very good...
I don't know what to think of this yet. On the one hand it sounds a bit too ambitious. On the other hand, there is no doubt that intelliJ is one of the best (if not THE best) Java IDE out there. It took a lot of skill and creativity to conceive and build it. So when the creator of IntelliJ speaks, I'm going give what he says due consideration.
Interesting thoughts. From the paper cited above:
-------
"For me, the most serious problem is that there is a very long gap between when I know exactly how to solve a problem and when I have successfully communicated this solution to the computer as a program. I can explain the problem and solution to another programmer in a matter of hours, but encoding this solution into the computer takes much longer. This is because with a programmer I can use natural language which is very rich, but for the computer, I must use a general-purpose programming language which is much less expressive."
-------
Programmer make huge assumptions about the details. When explaining something to another programmer we don't have to be specific. We can be ambiguous, and that's the problem with "natural" languages. They're too ambiguous. Programs must do specific things, and they require specific, unambiguous instructions to follow.
It takes time just to discover the details before coding, or the lack of details after the coding.
The paper goes on to say:
------- "The process of OOD is necessary because these classes and methods are the only abstractions that object-oriented languages understand. It seems like it is necessary and creative, but with Language Oriented Programming, OOD is not needed at all." ------
What are we supposed to imagine here? Each of us with our own perspective (favorite language) might either agree or disagree. I'm curious from what frame of reference the author writes from. When the paper throws around OO are they shortcomings found in specific OO languages? Java and C++ drive me nuts and I'd tend to agree with any OO criticism if it were based on either. However, not all OO languages are similarly restricted, just as not all programmers are similarly restricted. Some languages already facilitate the creation of DSL-like constructs by leaving /everything/ open to extension and tailoring by programmers. Nothing is final. Nothing is protected.
More: ------ "The traditional way to address this problem is to write comments or other forms of documentation to capture the design and model information. This has proven to be quite a weak solution for a number of reasons, not the least of which is the cost of writing such auxiliary documentation, and the tendency of documentation to grow out-of-synch with code."
This problem is not unique to programming. Our company is experiencing a growth spurt and investors are requiring written policies and procedures. We were amazed at how many "procedures" were being performed informally. How did we know how to do that? How were so many important functions being performed if there weren't instructions?
After documenting them we performed an audit a few months later. The procedures had changed again even though they were "documented". In some cases they're barely recognizable.
The lesson to get from this is HUMANS are incredibly flexible and adaptable, and can respond in real-time to change. HUMAN procedures don't generally go through QA and aren't system integrated. If a human tries something and it throws an exception, they fix it there-and-then and proceed. Nearly ALL companies would throw conniptions if programmers debugged a running application, fixed the code, and allowed the program to continue from there.
The next paradigm in programming should be modeled after how humans deal with procedure and exceptions, and learn from it. There has already been a lot of work done in this area and I've ready some interesting results in books on complexity and artificial life using real-world practical examples, like a system that "watched" a real human route gas around the country including problems, broken lines, strikes, etc. After some time (I can't remember how much) the system was allowed to take over and did a remarkable job -- even finding ways around problems. Besides its ability to "learn" another important feature was positive and negative feedback. You don't know if what you did was good if there isn't some reinforcement.
Anyway, interesting article. Some great insight.
.
- Follow-Ups:
- Re: Language Oriented Programming
- From: Laurent Bossavit
- Re: Language Oriented Programming
- Prev by Date: Re: OO Design induces an existential crisis
- Next by Date: Re: Bitwise Mag editorial calls OOP 'Snake Oil'
- Previous by thread: Re: Language Oriented Programming
- Next by thread: Re: Language Oriented Programming
- Index(es):
Relevant Pages
|
