Hi.
I'm watching this lectures (thaks to the guy who posted the url)
http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/
I've got the feeling that sometimes i miss (don't see/notice) some
abstractions that i could implement.
Is there a way to learn to find the abstractions?
In article <······················@lnews.actcom.co.il>, ilya wrote:
> I'm watching this lectures (thaks to the guy who posted the url)
> http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/
>
> I've got the feeling that sometimes i miss (don't see/notice) some
> abstractions that i could implement.
>
> Is there a way to learn to find the abstractions?
Can you elaborate on or give an example of what you mean by
abstraction, in this context? Otherwise, I must admit, I have no idea
what you're talking about. I haven't seen the lectures, if that
helps (or hinders :).
ilya <············@example.com> writes:
> Hi.
>
> I'm watching this lectures (thaks to the guy who posted the url)
> http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/
>
> I've got the feeling that sometimes i miss (don't see/notice) some
> abstractions that i could implement.
>
> Is there a way to learn to find the abstractions?
Practice.
>>
>> Is there a way to learn to find the abstractions?
>
> Practice.
I am also trying to learn the 'abstraction' finding algo (-;
My best shot is: do whatever to make the function I'm
writing as small as close to natural language as
possible. Then worry about all the functions which i need
as a result of above.
Also i read somewhere about 'inventor's dilemma', -- solving
a generic problem may be easier then solving a specific
problem.
--Vardhan
Vardhan Varma wrote:
>>>Is there a way to learn to find the abstractions?
>>
>>Practice.
>
>
> I am also trying to learn the 'abstraction' finding algo (-;
>
> My best shot is: do whatever to make the function I'm
> writing as small as close to natural language as
> possible. Then worry about all the functions which i need
> as a result of above.
Thank you. It seems to be very nice idea.
I'll try that.
[snip]
> --Vardhan
ilya <············@example.com> wrote in message news:<······················@lnews.actcom.co.il>...
> Vardhan Varma wrote:
> >>>Is there a way to learn to find the abstractions?
> >>
> >>Practice.
> >
> >
> > I am also trying to learn the 'abstraction' finding algo (-;
> >
> > My best shot is: do whatever to make the function I'm
> > writing as small as close to natural language as
> > possible. Then worry about all the functions which i need
> > as a result of above.
>
> Thank you. It seems to be very nice idea.
> I'll try that.
To find abstractions you have to look to the problem domain. If you
understand the problem domain, chances are that the abstractions are
already obvious. Then it's a matter of transferring the abstractions
to the programming solution. This means implementing a language whose
syntax and semantics allows the user to express himself as closely as
possible using the ideal abstractions in the problem domain.
For example, if the problem domain is solving logical problems, then
your abstractions are concepts like: rule of inference, statement of
fact, belief, probability, quantifier, predicate, set and so forth.
The abstractions in a logic programming system pop out from these.
Finding good abstractions isn't all that hard if you commit to the
problem domain. Where people go astray is trying to implement the
behaviors in the programming language to make the abstractions
well-behaved. So they look for shortcuts---intermediate
pseudo-abstractions to simplify programming but are not directly
related to the problem domain.
This is where programming patterns come into play. For example, object
oriented programming is a set of intermediate abstractions, which are
supposed to be capable of translating *any* problem domain into the
object-oriented domain. One just has to do the following
transformation: identify entities in the original problem domain which
are instantiable from the abstractions of the OO domain: class,
method, behavior, state. The fallacy in OO is that the instantiations
*are* abstractions from the problem domain, which is false: classes
are just instances of the class abstraction from the object-oriented
programming domain, just like declarations of facts and rules are
instances of abstractions from the logic programming domain, or
definitions of scores, staves and notes are instances of an
abstractions from the music programming domain, and so forth.
So when OO programmers say that they are having problems coming up
with an abstraction, they often really mean that they simply have
trouble finding a translation which will represent their problem
domain in the OO domain such that the result still vaguely resembles
the problem domain. :)
Kaz Kylheku wrote:
[snip]
> To find abstractions you have to look to the problem domain. If you
> understand the problem domain, chances are that the abstractions are
> already obvious. Then it's a matter of transferring the abstractions
> to the programming solution. This means implementing a language whose
> syntax and semantics allows the user to express himself as closely as
> possible using the ideal abstractions in the problem domain.
[snip]
I think i've got the point.
Thank you.