I am relatively new to lisp and learned there are three layers of
abstraction. These are (from lowest to highest): imperative (or procedural)
programming (nearly all common known languages), functional programming
(lisp and friends) and logic programming (prolog only afaik).
Thus, if I concentrate only on imperative programming style for example C++
and Java ain't I'm loosing at least one layer of abstraction? Isn't this
comparable to ignoring OO programming (considering OO programming as
abstraction layer)?
Andreas
"Andreas Thiele" <··········@nospam.com> wrote in message
····················@news.t-online.com...
> I am relatively new to lisp and learned there are three layers of
> abstraction. These are (from lowest to highest): imperative (or
procedural)
> programming (nearly all common known languages), functional programming
> (lisp and friends) and logic programming (prolog only afaik).
>
> Thus, if I concentrate only on imperative programming style for example
C++
> and Java ain't I'm loosing at least one layer of abstraction? Isn't this
> comparable to ignoring OO programming (considering OO programming as
> abstraction layer)?
Nope, you're not losing anything. You're just saving it for later.
Since Lisp is a "multi-paradigm" language you can use whatever facilitates
your goals best at the time. Mix and match as appropriate, shake and stir to
enjoy! It's why CL is a very PRACTICAL language. It's "easy" to retrofit
older code with newer bits. No reason to eat the entire CL elephant in one
bite.
I'm one of those who doesn't think "Writing FORTRAN in Lisp" is necessarily
that bad.
For one thing, it's better than writing FORTRAN in FORTRAN. The reason being
is that it is very difficult to let the other attributes of Lisp sneak into
a FORTRAN program written in FORTRAN, but having written FORTRAN in Lisp,
you have an environment ripe for infestation of sneaky little Lisp idioms.
Eventually, you'll start writing LispTRAN, and that may well be as far as
you need to go to get your task done. No dishonor in that.
Write what you like, do what you do. There won't be a quiz afterward.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> schrieb im Newsbeitrag
···················@uni-berlin.de...
> "Andreas Thiele" <··········@nospam.com> wrote in message
> ····················@news.t-online.com...
> > I am relatively new to lisp and learned there are three layers of
> > abstraction. These are (from lowest to highest): imperative (or
> procedural)
> > programming (nearly all common known languages), functional programming
> > (lisp and friends) and logic programming (prolog only afaik).
> >
> > Thus, if I concentrate only on imperative programming style for example
> C++
> > and Java ain't I'm loosing at least one layer of abstraction? Isn't this
> > comparable to ignoring OO programming (considering OO programming as
> > abstraction layer)?
>
> Nope, you're not losing anything. You're just saving it for later.
I'm not loosing anything if I ignore lisp at all???
Sorry, my english must be poor. I meant: wouldn't I loose a 'layer of
abstraction' if I'd ignore lisp at all!
>
> Since Lisp is a "multi-paradigm" language you can use whatever facilitates
> your goals best at the time. Mix and match as appropriate, shake and stir
to
> enjoy! It's why CL is a very PRACTICAL language. It's "easy" to retrofit
> older code with newer bits. No reason to eat the entire CL elephant in one
> bite.
>
> I'm one of those who doesn't think "Writing FORTRAN in Lisp" is
necessarily
> that bad.
>
> For one thing, it's better than writing FORTRAN in FORTRAN. The reason
being
> is that it is very difficult to let the other attributes of Lisp sneak
into
> a FORTRAN program written in FORTRAN, but having written FORTRAN in Lisp,
> you have an environment ripe for infestation of sneaky little Lisp idioms.
> Eventually, you'll start writing LispTRAN, and that may well be as far as
> you need to go to get your task done. No dishonor in that.
>
> Write what you like, do what you do. There won't be a quiz afterward.
>
> Regards,
>
> Will Hartung
> (·····@msoft.com)
>
>
--=-=-=
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
"Andreas Thiele" <··········@nospam.com> writes:
> "Will Hartung" <·····@msoft.com> schrieb im Newsbeitrag
> ···················@uni-berlin.de...
>> "Andreas Thiele" <··········@nospam.com> wrote in message
>> ····················@news.t-online.com...
>> > Thus, if I concentrate only on imperative programming style for example
>> > C++
>> > and Java ain't I'm loosing at least one layer of abstraction? Isn't th=
is
>> > comparable to ignoring OO programming (considering OO programming as
>> > abstraction layer)?
>>
>> Nope, you're not losing anything. You're just saving it for later.
>
> I'm not loosing anything if I ignore lisp at all???
> Sorry, my english must be poor. I meant: wouldn't I loose a 'layer of
> abstraction' if I'd ignore lisp at all!
Your english seems good enough to me :) I think the real issue here is
that you tend to mistake two different notions, as others already
pointed out : a programming paradigm "functional, OO, ..." is a
completely different concept than that of a layer of abstraction.
You can build abstraction layers using one (or several) programming
paradigm(s), but a programming paradigm doesn't seem to be considered a
layer of abstraction by itself.
If you're wondering what you'd lose if you were to ignore Lisp and
concentrate on C++, then my answer (beware: i've only a few months of
experience) would be that you would be forced to use a limited number
of programming paradigms, but that you'd still be able to build you own
layers of abstractions, but using *only* those paradigms that are
allowed by your "target" language.
If you were to choose to stay with Lisp, then you'd gain a great
advantage : not only would you be able to build your own abstractions
layers, but you'd also be able to build them using *any* programming
paradigm, including those allowed by your possible "target" language. As
Pascal Costanza (i believe) already pointed out, you'd even be able to
mix different paradigms in order to build your abstraction layers.
If you feel like wanting to know more about "layers of abstraction", i
strongly advice you to read "Structure and Interpretation of Computer
Programs" at http://mitpress.mit.edu/sicp/
Hope this quasi-newbie's point of view helps !
=2D-=20
Pierre-Fran=E7ois Gomez
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iEYEABECAAYFAkDlnIAACgkQS7yD/WgCQMicGACeJ3k5zS0QbHZeEXP20sJXMRl1
7moAn3OcLnWyQfaZVOqurUgw7VyiYEIP
=fbmG
-----END PGP SIGNATURE-----
--=-=-=--
"Pierre-Fran�ois Gomez" <········@free.fr> schrieb im Newsbeitrag
···················@eithel.famille.local...
>"Andreas Thiele" <··········@nospam.com> writes:
>
>> "Will Hartung" <·····@msoft.com> schrieb im Newsbeitrag
>> ···················@uni-berlin.de...
>>> "Andreas Thiele" <··········@nospam.com> wrote in message
>>> ····················@news.t-online.com...
>>> > Thus, if I concentrate only on imperative programming style for
example
>>> > C++
>>> > and Java ain't I'm loosing at least one layer of abstraction? Isn't
this
>>> > comparable to ignoring OO programming (considering OO programming as
>>> > abstraction layer)?
>>>
>>> Nope, you're not losing anything. You're just saving it for later.
>>
>> I'm not loosing anything if I ignore lisp at all???
>> Sorry, my english must be poor. I meant: wouldn't I loose a 'layer of
>> abstraction' if I'd ignore lisp at all!
>
>Your english seems good enough to me :) I think the real issue here is
>that you tend to mistake two different notions, as others already
>pointed out : a programming paradigm "functional, OO, ..." is a
>completely different concept than that of a layer of abstraction.
>
>You can build abstraction layers using one (or several) programming
>paradigm(s), but a programming paradigm doesn't seem to be considered a
>layer of abstraction by itself.
OK, I think I understand this now. Imperative, functional and logical
programming styles are paradigms and not layers of abstraction.
>
>If you're wondering what you'd lose if you were to ignore Lisp and
>concentrate on C++, then my answer (beware: i've only a few months of
>experience)
I also :-)
>would be that you would be forced to use a limited number
>of programming paradigms, but that you'd still be able to build you own
>layers of abstractions, but using *only* those paradigms that are
>allowed by your "target" language.
>
>If you were to choose to stay with Lisp, then you'd gain a great
>advantage : not only would you be able to build your own abstractions
>layers, but you'd also be able to build them using *any* programming
>paradigm, including those allowed by your possible "target" language. As
>Pascal Costanza (i believe) already pointed out, you'd even be able to
>mix different paradigms in order to build your abstraction layers.
>
>If you feel like wanting to know more about "layers of abstraction", i
>strongly advice you to read "Structure and Interpretation of Computer
>Programs" at http://mitpress.mit.edu/sicp/
I just bought it but did not yet find the time for indepth study. Its in my
shelf :-)
>
>Hope this quasi-newbie's point of view helps !
Yes. Talking helps me.
>
>--
>Pierre-Fran�ois Gomez
>
"Andreas Thiele" <··········@nospam.com> wrote in message news:<···············@news.t-online.com>...
> I am relatively new to lisp and learned there are three layers of
> abstraction. These are (from lowest to highest): imperative (or procedural)
> programming (nearly all common known languages), functional programming
> (lisp and friends) and logic programming (prolog only afaik).
Well, the above statement is a broad-brush big-picture type of
statement. It is correct in the most general sense, but perhaps
incorrect or misleading when scaled down to specific domains. Lisp is
a multi-paradigmatic language, meaning you can program imperatively,
functionally, or even, to a lesser extent, with logic/inference.
But be careful when talking about these things because the meanings
are sometimes loaded. For instance, Haskell is a _pure_ functional
programming language, meaning that it cannot (or at least cannot
easily) program imperatively and this is by design. And conversely,
one can write C programs in a functional style without too much extra
effort.
Lisp has a lot of hallmarks of a functional language (nearly every
built-in function returns a value, functions are first order) and its
dynamic interative nature encourages and rewards a functional style of
programming, but it is not limited to that. It is a common
misconception that Lisp is "only" a functional programming language. I
program imperative Lisp code all the time - sometimes that's just the
best solution to a particular problem. As for logic/inference
programming, I've only done a little of that myself with Lisp, but
check out Peter Norvigs "Paradigms of Artificial Intelligence
Programming". It's a great book on Lisp and he implements a Prolog
language using Lisp as one of the chapters.
Lastly, functional programming by itself is not necessarily more or
less abstract than programming imperatively. Though it is the case
that the traditionally functional languages (Haskell, Clean, ML, etc.)
and the Lisp family of languages (Scheme, Common Lisp) are more
abstract or have many more mechanisms for abstraction than their more
imperative counterparts (C C++ Java, etc.). And a functional
programming style has several advantages that are separate from simply
being abstract (reliability, ease of testing, simplified debugging,
automatic optimization)
>
> Thus, if I concentrate only on imperative programming style for example C++
> and Java ain't I'm loosing at least one layer of abstraction? Isn't this
> comparable to ignoring OO programming (considering OO programming as
> abstraction layer)?
Yes, this is a good comparison, though "losing a layer of abstraction"
isn't necessarily exactly accurate. Note that C++ and Java are both
good languages to know and you are sure to run across them over and
over again. And, in general, learning new languages, especially
divergent ones, can only serve to make you a better programmer and a
better judge of programming languages.
Good luck with Lisp. If you need to read more about it, here are a
few URLs:
http://www.alu.org
http://www.cliki.net/
Chris Perkins
"Andreas Thiele" <··········@nospam.com> wrote in message news:<···············@news.t-online.com>...
> I am relatively new to lisp and learned there are three layers of
> abstraction. These are (from lowest to highest): imperative (or procedural)
> programming (nearly all common known languages), functional programming
> (lisp and friends) and logic programming (prolog only afaik).
Well, the above statement is a broad-brush big-picture type of
statement. It is correct in the most general sense, but perhaps
incorrect or misleading when scaled down to specific domains. Lisp is
a multi-paradigmatic language, meaning you can program imperatively,
functionally, or even, to a lesser extent, with logic/inference.
But be careful when talking about these things because the meanings
are sometimes loaded. For instance, Haskell is a _pure_ functional
programming language, meaning that it cannot (or at least cannot
easily) program imperatively and this is by design. And conversely,
one can write C programs in a functional style without too much extra
effort.
Lisp has a lot of hallmarks of a functional language (nearly every
built-in function returns a value, functions are first order) and its
dynamic interative nature encourages and rewards a functional style of
programming, but it is not limited to that. It is a common
misconception that Lisp is "only" a functional programming language. I
program imperative Lisp code all the time - sometimes that's just the
best solution to a particular problem. As for logic/inference
programming, I've only done a little of that myself with Lisp, but
check out Peter Norvigs "Paradigms of Artificial Intelligence
Programming". It's a great book on Lisp and he implements a Prolog
language using Lisp as one of the chapters.
Lastly, functional programming by itself is not necessarily more or
less abstract than programming imperatively. Though it is the case
that the traditionally functional languages (Haskell, Clean, ML, etc.)
and the Lisp family of languages (Scheme, Common Lisp) are more
abstract or have many more mechanisms for abstraction than their more
imperative counterparts (C C++ Java, etc.). And a functional
programming style has several advantages that are separate from simply
being abstract (reliability, ease of testing, simplified debugging,
automatic optimization)
>
> Thus, if I concentrate only on imperative programming style for example C++
> and Java ain't I'm loosing at least one layer of abstraction? Isn't this
> comparable to ignoring OO programming (considering OO programming as
> abstraction layer)?
Yes, this is a good comparison, though "losing a layer of abstraction"
isn't necessarily exactly accurate. Note that C++ and Java are both
good languages to know and you are sure to run across them over and
over again. And, in general, learning new languages, especially
divergent ones, can only serve to make you a better programmer and a
better judge of programming languages.
Good luck with Lisp. If you need to read more about it, here are a
few URLs:
http://www.alu.org
http://www.cliki.net/
Chris Perkins
"Andreas Thiele" <··········@nospam.com> writes:
> I am relatively new to lisp and learned there are three layers of
> abstraction. These are (from lowest to highest): imperative (or procedural)
> programming (nearly all common known languages), functional programming
> (lisp and friends) and logic programming (prolog only afaik).
>
> Thus, if I concentrate only on imperative programming style for example C++
> and Java ain't I'm loosing at least one layer of abstraction? Isn't this
> comparable to ignoring OO programming (considering OO programming as
> abstraction layer)?
OO is only syntactical sugar and a software structuring pattern.
You can have imperative OO, functional OO or logic programming OO.
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
"Pascal Bourguignon" <····@thalassa.informatimago.com> schrieb im
Newsbeitrag ···················@thalassa.informatimago.com...
> "Andreas Thiele" <··········@nospam.com> writes:
>
> > I am relatively new to lisp and learned there are three layers of
> > abstraction. These are (from lowest to highest): imperative (or
procedural)
> > programming (nearly all common known languages), functional programming
> > (lisp and friends) and logic programming (prolog only afaik).
> >
> > Thus, if I concentrate only on imperative programming style for example
C++
> > and Java ain't I'm loosing at least one layer of abstraction? Isn't this
> > comparable to ignoring OO programming (considering OO programming as
> > abstraction layer)?
>
> OO is only syntactical sugar and a software structuring pattern.
> You can have imperative OO, functional OO or logic programming OO.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> There is no worse tyranny than to force a man to pay for what he does not
> want merely because you think it would be good for him. -- Robert Heinlein
OK, but this is not in contradiction to my question/statement. OO was just
an example because it is emphasized so much in business application
development (where I work).
So, if I'd exclude lisp from my thinking, I would loose a degree of
abstraction, which is even much worth then just loosing OO?
Andreas
From: Christian Hofer
Subject: Re: Lisp an abstraction layer?
Date:
Message-ID: <86u0wm3yrw.fsf@chris.wg>
"Andreas Thiele" <··········@nospam.com> writes:
> So, if I'd exclude lisp from my thinking, I would loose a degree of
> abstraction, which is even much worth then just loosing OO?
In comparison to an imperative language, a functional language
(including multi-paradigm languages like Lisp) allows for higher-order
procedures. I thought of this, as I read your question. See Abelson,
Sussman, SICP, p. 57: "Often the same programming pattern will be used
with a number of different procedures. To express such patterns as
concepts, we will need to construct procedures that can accept
procedures as arguments or return procedures as values. Procedures
that manipulate procedures are called /higher-order procedures/. This
section shows how higher-order procedures can serve as powerful
abstraction mechanisms, vastly increasing the expressive power of our
language."
It is the feature I am missing the most, when I have to program in an
imperative language, and I tend to create "interpreter" and
"strategy" patterns in Java all the time...
Maybe this is what you meant? Although: The first two of five chapters
in SICP are "Building Abstractions with Procedures" and "Building
Abstractions with Data", and HOFs are only an aspect of the former
(and there is only a single footnote about macros - another powerful
mechanism, and the most distinguishing feature of Lisp - in the whole
book).
Chris
Andreas Thiele <··········@nospam.com> wrote:
> programming (nearly all common known languages), functional programming
> (lisp and friends) and logic programming (prolog only afaik).
Instead of "logic programming" I would rather talk about "declarative
programming". Here you might also include SQL.
- Alex
--
Software Lab. Alexander Burger
Bahnhofstr. 24a, D-86462 Langweid
···@software-lab.de, http://www.software-lab.de, +49 821 9907090
Andreas Thiele wrote:
> I am relatively new to lisp and learned there are three layers of
> abstraction. These are (from lowest to highest): imperative (or procedural)
> programming (nearly all common known languages), functional programming
> (lisp and friends) and logic programming (prolog only afaik).
>
> Thus, if I concentrate only on imperative programming style for example C++
> and Java ain't I'm loosing at least one layer of abstraction? Isn't this
> comparable to ignoring OO programming (considering OO programming as
> abstraction layer)?
Your use of "abstraction layer" seems strange to me. An abstraction
takes several concrete things, factors out their similarities and leaves
out distracting details. In my understanding, the programming styles you
mention above are not abstractions as such, but only means to achieve
abstraction.
The term that is usually used is "programming paradigm". Again, this is
not a good term in my opinion. The term paradigm is meant to denote
strictly incompatible world views (like, say, Newtonian physics and
relativity theory). If you can make different paradigms work well
together, then they are not paradigms.
I am, and presumably most Common Lispers are, convinced that
multi-paradigm programming is The Right Thing (tm), because each
programming style has its own specific strengths and weaknesses. There
are several pure languages out there with supporters who claim that
their preferred style is best suited for everything. However, if you
look close enough you will notice that in large programs they start to
simulate other paradigms. (In Haskell, imperative programming is
relegated to Monads; in Smalltalk, higher-order functions are available
in the form of blocks; in Prolog, the cut leads to an imperative
programming style; and so on.)
The common theme here is that in large programs, certain idioms start to
emerge that consist of regular patterns that are used over and over
again. A language support for such an idiom just means that you can
declaratively state that you want to use that idiom as a higher
abstraction when needed. This is the gist of programming languages - for
example, the idiom of pushing values to a stack, jumping somewhere and
returning from there with a return value later on is nothing but an
idiom in assembly language, but can be formed into a procedure call
abstraction in a higher-level language. Likewise, the idiom of looking
up a procedure in a table that matches a specific request can be turned
into an object-oriented abstraction.
The nature of Lisp is not that it provides a number of prefabricated
means of abstraction in a ready-to-use way - although concrete Lisp
dialects and implementations do come with libraries of those that have
been proven in practice - but instead, you can always build your own
abstractions by way of higher-order functions and macros as if they had
been part of your programming language from the very start. In fact, the
Common Lisp Object System, the loop macro in Common Lisp for expressing
advanced iterations, the Screamer package for doing non-deterministic
programming, and so on, are essentially nothing but advanced macro
packages built on a small set of fundamental operators built into "core"
Lisp.
If you want to learn about how to build your own domain-specific
abstractions, or for example, how to embed a compiler for a logic
programming language directly into Lisp, you can read either "On Lisp"
by Paul Graham, or "Paradigms of Artifical Intelligence Programming" by
Peter Norvig. The former can be downloaded for free at Paul Graham's
website while the latter is available as a printed book.
Back to your original question. You're not necessarily losing anything
when you don't know about some concrete programming styles, but you are
probably missing opportunities to express solutions for some problems in
more appropriate ways. In the end, everything can be written in
assembler. ;)
I hope this helps.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Hi Andreas Thiele,
> I am relatively new to lisp and learned there are three layers of
> abstraction. These are (from lowest to highest): imperative (or
> procedural) programming (nearly all common known languages), functional
> programming (lisp and friends) and logic programming (prolog only
> afaik).
Here's a fourth: Building a domain-specific language. For example Common
Lisp can perform logic programming via this route. You can build new
syntax and semantics. If you need a new iteration construct you can
seamlessly define one. Compare with Java 5.0 (sic) where it has been
decreed that some `for' loops may be written in an abbreviated syntax.
> Thus, if I concentrate only on imperative programming style for example
> C++ and Java ain't I'm loosing at least one layer of abstraction?
You'll only lose from insufficient abstraction if there is a better way to
express the solution. If the problem domain is naturally imperative then
there is no reason a solution can't be imperative (especially when the
side effects are hidden within macros).
Most Common Lisp imperative constructs have well defined return values
permitting you to build functional looking code that also produces side
effects. Something as simple as INCF may be embedded as a component of an
expression while also incrementing a variable (much like the ++ syntax
you are used to).
Also you still benefit from everything in Common Lisp being an expression.
For example you can always operate upon the return value of IF instead of
needing to switch to `? :' expression notation.
> Isn't this comparable to ignoring OO programming (considering OO
> programming as abstraction layer)?
No. Languages like Java force object-orientated programming even when
the approach provides no additional benefit. Some solutions will be less
clear and more verbose when expressed in an explicit OO style. In such
cases you do not lose abstraction avoiding the style. This cannot be
expressed any cleaner in an OO style:
(let ((counter 0))
(defun latest-count ()
(incf counter)))
(latest-count) => 1
(latest-count) => 2
...
You can go very, very far in Common Lisp without learning the Common Lisp
Object System, including building whole new language domains. Compare with
Java where you can't even print "Hello World!" (you'll also find out that
Java's object system is far less expressive and can only dispatch upon a
single object at run time--this is also a limitation of dot notation).
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> schrieb im Newsbeitrag
···································@consulting.net.nz...
> Hi Andreas Thiele,
>
> > I am relatively new to lisp and learned there are three layers of
> > abstraction. These are (from lowest to highest): imperative (or
> > procedural) programming (nearly all common known languages), functional
> > programming (lisp and friends) and logic programming (prolog only
> > afaik).
>
> Here's a fourth: Building a domain-specific language. For example Common
> Lisp can perform logic programming via this route. You can build new
Can you suggest any reading on logic programming via building a
domain-specific language in Lisp?
> syntax and semantics. If you need a new iteration construct you can
> seamlessly define one. Compare with Java 5.0 (sic) where it has been
> decreed that some `for' loops may be written in an abbreviated syntax.
>
> > Thus, if I concentrate only on imperative programming style for example
> > C++ and Java ain't I'm loosing at least one layer of abstraction?
>
> You'll only lose from insufficient abstraction if there is a better way to
> express the solution. If the problem domain is naturally imperative then
> there is no reason a solution can't be imperative (especially when the
> side effects are hidden within macros).
OK, this primarily means, I can write imperative programs in Lisp. I often
do this (I fear) ;-)
I have to apologize for my poor english. My primary question is, if I can
say that imperative, functional and logic programming are different degrees
of abstraction (or maybe layers of abstraction).
>
> Most Common Lisp imperative constructs have well defined return values
> permitting you to build functional looking code that also produces side
> effects. Something as simple as INCF may be embedded as a component of an
> expression while also incrementing a variable (much like the ++ syntax
> you are used to).
>
> Also you still benefit from everything in Common Lisp being an expression.
> For example you can always operate upon the return value of IF instead of
> needing to switch to `? :' expression notation.
>
> > Isn't this comparable to ignoring OO programming (considering OO
> > programming as abstraction layer)?
>
> No. Languages like Java force object-orientated programming even when
> the approach provides no additional benefit. Some solutions will be less
> clear and more verbose when expressed in an explicit OO style. In such
> cases you do not lose abstraction avoiding the style. This cannot be
> expressed any cleaner in an OO style:
I meant ignoring OO at all. Never use OO. Write all my programs in lets say
C even if they are complex and could nicely be solved using OO strategy. I
thought introducing OO some time ago offered a new way of abstraction
compared to pure C programming. So I thought ignoring OO at all would be
comparable to ignoring lisp _at all_ (because I loose possible abstraction).
>
> (let ((counter 0))
> (defun latest-count ()
> (incf counter)))
>
> (latest-count) => 1
> (latest-count) => 2
> ...
>
> You can go very, very far in Common Lisp without learning the Common Lisp
> Object System, including building whole new language domains. Compare with
> Java where you can't even print "Hello World!" (you'll also find out that
> Java's object system is far less expressive and can only dispatch upon a
> single object at run time--this is also a limitation of dot notation).
>
> Regards,
> Adam
Thanks
Andreas
Andreas Thiele wrote:
> Can you suggest any reading on logic programming via building a
> domain-specific language in Lisp?
Screamer is a perfect example of this. It actually adds a
non-deterministic layer to lisp that can be used for logic
programming. There are a number of papers about Screamer on the web.
For example, there's a paper named "Nondeterministic Lisp as a
Substrate for Constraint Logic Programming". It's by Jeffrey Mark
Siskind and David Allen McAllester.
--
Fred Gilham ······@csl.sri.com
"If I'm going to get paged at 3 in the morning, I'd like it to at
least be my fault, and I'd also like a fighting chance of fixing the
problem." -- Tim Moore, arguing for professional open-source tools
Hi Fred Gilham,
> Andreas Thiele wrote:
>> Can you suggest any reading on logic programming via building a
>> domain-specific language in Lisp?
>
> Screamer is a perfect example of this. [...]
Thanks for the comprehensive replies Fred, Marco and Mario. Before I could
respond to Andreas my Internet access provider experienced serious routing
issues which only came right a minutes ago.
Regards,
Adam
From: Marco Baringer
Subject: Re: Lisp an abstraction layer?
Date:
Message-ID: <m21xjulss6.fsf@convey.it>
"Andreas Thiele" <··········@nospam.com> writes:
> "Adam Warner" <······@consulting.net.nz> schrieb im Newsbeitrag
> ···································@consulting.net.nz...
>> Hi Andreas Thiele,
>>
>> > I am relatively new to lisp and learned there are three layers of
>> > abstraction. These are (from lowest to highest): imperative (or
>> > procedural) programming (nearly all common known languages), functional
>> > programming (lisp and friends) and logic programming (prolog only
>> > afaik).
>>
>> Here's a fourth: Building a domain-specific language. For example Common
>> Lisp can perform logic programming via this route. You can build new
>
> Can you suggest any reading on logic programming via building a
> domain-specific language in Lisp?
http://www.norvig.com/paip.html
> OK, this primarily means, I can write imperative programs in Lisp. I often
> do this (I fear) ;-)
don't fear imperative programming, only be afraid when your putting a
square into a round hole.
> I have to apologize for my poor english. My primary question is, if I can
> say that imperative, functional and logic programming are different degrees
> of abstraction (or maybe layers of abstraction).
i believe "paradigm"s is the proper term.
> I meant ignoring OO at all. Never use OO. Write all my programs in lets say
> C even if they are complex and could nicely be solved using OO strategy. I
> thought introducing OO some time ago offered a new way of abstraction
> compared to pure C programming. So I thought ignoring OO at all would be
> comparable to ignoring lisp _at all_ (because I loose possible abstraction).
ignoring OO means ignoring one way of thinking obut and expressing
your problem. lisp (common lisp at least) is a multi-paradigm
programming language, you can mix and match OO, functional, imperative
(aka prcodeural) in the same program depending on how that particular
part of the program is best expressed. this snipeet contians some OO
code, some procedural code and some functional code:
(defgeneric OO (a))
(defmethod OO ((a klass))
(tagbody
...
(go tag)))
(defun functional (list)
(mapcar #'OO list))
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
"Andreas Thiele" <··········@nospam.com> writes:
> "Adam Warner" <······@consulting.net.nz> schrieb im Newsbeitrag
> ···································@consulting.net.nz...
>> Hi Andreas Thiele,
>>
>> > I am relatively new to lisp and learned there are three layers of
>> > abstraction. These are (from lowest to highest): imperative (or
>> > procedural) programming (nearly all common known languages), functional
>> > programming (lisp and friends) and logic programming (prolog only
>> > afaik).
>>
>> Here's a fourth: Building a domain-specific language. For example Common
>> Lisp can perform logic programming via this route. You can build new
>
> Can you suggest any reading on logic programming via building a
> domain-specific language in Lisp?
Well, the canonical example would be the prolog interpreter
(compiler?) found in "Paradigms of Artificial Inteligence Programming"
by Norvig. It is completely and seamlessly embeded into CL (the book
is good reading anyway. Highly recomendable). There are tons of
further examples like that in On Lisp, a book you can get from Paul
Grahams site. Then there is Axiom, and ACL2. There is also lisa
(google for "lisa" and "lisp").
"We do that all the time, pal." ;-)
> OK, this primarily means, I can write imperative programs in Lisp. I often
> do this (I fear) ;-)
You can, and you can do it without fear. :-)
"Andreas Thiele" <··········@nospam.com> writes:
> I am relatively new to lisp and learned there are three layers of
> abstraction.
Oh?
> These are (from lowest to highest): imperative (or procedural)
> programming (nearly all common known languages), functional programming
> (lisp and friends) and logic programming (prolog only afaik).
These are certainly `paradigms' for programming, but I wouldn't
consider them `layers'. If you can identify abstraction barriers in
your program and there is code that is a client to one abstraction and
it implements another abstraction, then you could consider that a
layer.
> Thus, if I concentrate only on imperative programming style for example C++
> and Java ain't I'm loosing at least one layer of abstraction? Isn't this
> comparable to ignoring OO programming (considering OO programming as
> abstraction layer)?
Considering that most OO programming these days is imperative
programming with delusions of grandeur, I don't think you lose much.
"Joe Marshall" <···@ccs.neu.edu> schrieb im Newsbeitrag
·················@ccs.neu.edu...
> "Andreas Thiele" <··········@nospam.com> writes:
>
> > I am relatively new to lisp and learned there are three layers of
> > abstraction.
>
> Oh?
I understood it that way. Now, it seems more or less wrong. I had to talk in
front of some university professors, their students and some insurance
managers (potential customers for me :-)) and consultants and I presented
this 'idea'. Nobody said _anything_ against it, although I know that at
least one of the professors has profound lisp knowledge. Obviously for him
there was some political reason, not to critisize me :-). Yes, he wants to
teach or introduce lisp but his college professors don't consider lisp a
focus for a technical university. Industry doesn't want or need lisp (they
think). So he did not say anything against my 'heroic' speech on lisp. But I
felt something could be wrong with this 'idea'.
>
> > These are (from lowest to highest): imperative (or procedural)
> > programming (nearly all common known languages), functional programming
> > (lisp and friends) and logic programming (prolog only afaik).
>
> These are certainly `paradigms' for programming, but I wouldn't
> consider them `layers'. If you can identify abstraction barriers in
> your program and there is code that is a client to one abstraction and
> it implements another abstraction, then you could consider that a
> layer.
>
> > Thus, if I concentrate only on imperative programming style for example
C++
> > and Java ain't I'm loosing at least one layer of abstraction? Isn't
this
> > comparable to ignoring OO programming (considering OO programming as
> > abstraction layer)?
>
> Considering that most OO programming these days is imperative
> programming with delusions of grandeur, I don't think you lose much.
Andreas Thiele wrote:
> I am relatively new to lisp and learned there are three layers of
> abstraction. These are (from lowest to highest): imperative (or procedural)
> programming (nearly all common known languages), functional programming
> (lisp and friends) and logic programming (prolog only afaik).
>
> Thus, if I concentrate only on imperative programming style for example C++
> and Java ain't I'm loosing at least one layer of abstraction?
Frederick Brooks in "No Silver Bullet" said this about languages and
abstraction: "What does a high-level language accomplish? It frees a
program from much of its accidental complexity. An abstract program
consists of conceptual constructs: operations, datatypes, sequences, and
communication. The concrete machine program is concerned with bits,
registers, conditions, branches, channels, disks, and such. To the
extent that the high-level language embodies the constructs wanted in
the abstract program and avoids all lower ones, it eliminates a whole
level of complexity that was never inherent in the program at all."
Lisp programmers are able to work at a level of abstraction much closer
to the problem they are solving, because unlike C++ and Java developers
we are not forever jumping through hoops to make our compilers happy.
So, yes, one loses a layer of abstraction when not using Lisp, but as
others have noted this is not about paradigms.
otoh, my Cells project supports a declarative programming style, with an
underlying engine animating the declaration suite. the programmer is
spared the burden of propagating change cpmpletely and in the right
order, just as HLL spared programmers in the 60s from the burden of
assembly language.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
I'd like to thank you all for your comprehensive answers. Let me try to
conclude.
I should not consider imperative, functional and logic programming 'layers
of abstraction'. They are programming 'paradigms'. This word is actually a
little difficult, because paradigms should be expected to exclude each
other. Lisp is not functional, it can be functional but also imperative and
logic programming as well. Lisp offers more means for abstraction then any
imperative language, but it has got nothing to do with those paradigms.
The error arose when I read a lecture on these paradigms. The lecture had
examples. A program to find the greatest common division (GCD). GCD was
written in C as example for imperative programming in Lisp and in Prolog.
While the C example had some line of code the Lisp example had only few
lines and Prolog reduced to I think one or two lines. So I though it gets
more and more abstract.
I should have known at least Paul Grahams Prolog compiler, because I read On
Lisp, but I did not yet find the time for an in depth study :-).
I sometimes have to argue on lisp because IT manager do not always
appreciate Lisp. Here are two examples I heard from university degree
managers: "I don't wanna see your Lisp bullshit" and "I was forced to learn
Lisp at the university and never really understood it. I will certainly not
buy a Lisp based product". These are real live examples if you work in the
field of business application.
Facing such sentences perhaps I should pay attention not to get dogmatic on
Lisp :-). Your answers helped me not to run in the wrong direction with my
arguments.
Thanks
Andreas
"Kenny Tilton" <·······@nyc.rr.com> schrieb im Newsbeitrag
··························@twister.nyc.rr.com...
>
>
> Andreas Thiele wrote:
>
> > I am relatively new to lisp and learned there are three layers of
> > abstraction. These are (from lowest to highest): imperative (or
procedural)
> > programming (nearly all common known languages), functional programming
> > (lisp and friends) and logic programming (prolog only afaik).
> >
> > Thus, if I concentrate only on imperative programming style for example
C++
> > and Java ain't I'm loosing at least one layer of abstraction?
>
> Frederick Brooks in "No Silver Bullet" said this about languages and
> abstraction: "What does a high-level language accomplish? It frees a
> program from much of its accidental complexity. An abstract program
> consists of conceptual constructs: operations, datatypes, sequences, and
> communication. The concrete machine program is concerned with bits,
> registers, conditions, branches, channels, disks, and such. To the
> extent that the high-level language embodies the constructs wanted in
> the abstract program and avoids all lower ones, it eliminates a whole
> level of complexity that was never inherent in the program at all."
>
> Lisp programmers are able to work at a level of abstraction much closer
> to the problem they are solving, because unlike C++ and Java developers
> we are not forever jumping through hoops to make our compilers happy.
>
> So, yes, one loses a layer of abstraction when not using Lisp, but as
> others have noted this is not about paradigms.
>
> otoh, my Cells project supports a declarative programming style, with an
> underlying engine animating the declaration suite. the programmer is
> spared the burden of propagating change cpmpletely and in the right
> order, just as HLL spared programmers in the 60s from the burden of
> assembly language.
>
> kt
>
> --
> Home? http://tilton-technology.com
> Cells? http://www.common-lisp.net/project/cells/
> Cello? http://www.common-lisp.net/project/cello/
> Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
> Your Project Here! http://alu.cliki.net/Industry%20Application
>
In article <···············@news.t-online.com>, Andreas Thiele wrote:
>
> I sometimes have to argue on lisp because IT manager do not always
> appreciate Lisp. Here are two examples I heard from university degree
> managers: "I don't wanna see your Lisp bullshit" and "I was forced to learn
> Lisp at the university and never really understood it. I will certainly not
> buy a Lisp based product". These are real live examples if you work in the
> field of business application.
In many cases, a system will not be appreaciated unless it is sufficient buzzword
compliant. That is, using Java and all the latest XML "technonlogies" and EJB etc.
While all of this is supposed to increasing productivity and interopability, they
are often so convoluted to use, that you may save time (and money) doing some of
these things form scratch. Even more mainstream languages like Perl and Python get
the same kind of reaction as you describe above in some cases.
If you are in a situation where you can choose your tools, almost anything will be
forgiven if you deliver as good or better functionality as specified, and on time.
Lisp is often a good choice for developing code fast.
> Facing such sentences perhaps I should pay attention not to get dogmatic on
> Lisp :-). Your answers helped me not to run in the wrong direction with my
> arguments.
Never be dogmatic. Not even lisp is best for everything.
--
Gisle S�lensminde
Computational biology unit, University of Bergen, Norway
Email: ·····@cbu.uib.no
"Andreas Thiele" <··········@nospam.com> writes:
> [...]
> "[...] I will certainly not
> buy a Lisp based product". These are real live examples if you work in the
> field of business application.
We should label our products with a big: "Made with plain binary bits",
and speak of lisp only within the knowledgable circle...
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein