Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > the perens in lisp dilects is there for a reson... macros.

Reply
Thread Tools

the perens in lisp dilects is there for a reson... macros.

 
 
M. Edward (Ed) Borasky
Guest
Posts: n/a
 
      08-10-2006
My apologies if someone has posted this already -- I just received it:

http://www.americanscientist.org/tem.../assetid/51982

"


The Semicolon Wars


Every programmer knows there is one true programming language. A new
one every week

Brian Hayes
<http://www.americanscientist.org/template/AuthorDetail/authorid/490;jsessionid=baagDBWk-NRVHf>"

 
Reply With Quote
 
 
 
 
M. Edward (Ed) Borasky
Guest
Posts: n/a
 
      08-10-2006
M. Edward (Ed) Borasky wrote:
> My apologies if someone has posted this already -- I just received it:
>
> http://www.americanscientist.org/tem.../assetid/51982
>
> "
>
>
> The Semicolon Wars
>
>
> Every programmer knows there is one true programming language. A new
> one every week
>
> Brian Hayes
> <http://www.americanscientist.org/template/AuthorDetail/authorid/490;jsessionid=baagDBWk-NRVHf>"
>
>
>

Yet another mirroring of our discussions on languages. This one has
some good things to say about Ruby

http://t-a-w.blogspot.com/2006/07/pr...e-of-2010.html



 
Reply With Quote
 
 
 
 
Francis Cianfrocca
Guest
Posts: n/a
 
      08-10-2006
Chad Perrin wrote:
> On Wed, Aug 09, 2006 at 11:57:03PM +0900, Francis Cianfrocca wrote:
>>
>> I've often been mystified when people talk about Ruby's metaprogramming,
>> closures, lambdas, etc. as constituting a "functional" programming
>> style. Your comment is striking because it made me realize that perhaps
>> many people who learn languages like Scheme are actually trying to apply
>> the imperative, Turing-style computational model to languages that don't
>> support them. And that reinforces all the more my intuition that pure FP
>> is not well-suited for mainstream professional programming.

>
> 1. A functional "style" is not the same as a functional "language".
> The adoption of certain coding techniques that arose in functional
> languages for use in a language that is more object oriented and
> imperative in syntax in no way changes the fact that those techniques
> come from a programming style that arose due in large part to a
> functional syntax.
>
> 2. I agree that *pure* functional programming is not well-suited to
> mainstream professional computing, but then, neither is *pure*
> imperative programming. That doesn't change the fact that a whole lot
> of functional programming syntactic characteristics can be crammed into
> a language before passing the point of diminishing returns. In fact, I
> think that something as simple as teaching students to use prefix
> arithmetic notation in grade school would turn the tables such that
> functional programming syntax would probably be by far the "most
> natural" to nascent programmers by quite a wide margin.



This thread has probably gone on long enough but as I read it, what
you're saying here amounts simply to "let's take what's good from each
approach and apply it generally." Can't argue with that.

I find it very revealing that you see the primary (borrowable) value in
functional languages as coming primarily from *syntactic* elements.
Again I may be misreading you, but you can get syntactic innovations
from anywhere. The thing that really distinguishes functional programs
is that you can reason mathematically (and one hopes, automatically)
about their correctness. Rather than being stuck with the whole sorry
round of unit-test/debug/regress/repeat that we use with Ruby and every
other non-functional language. Apart from the reference to Ada/Diana (a
sub-language with a rigorous formal semantics), I haven't heard anyone
on this thread try to relate this benefit of functional languages to
non-functional ones.

To answer someone else, the ability to automatically process programs is
why I'm interested in mini-languages (DSLs) written in Ruby that are
non-Turing complete, because they may be decidable, if designed
properly. That opens the way (in theory) to the kind of automatic
correctness analyzers that you see in pure functional programming. The
potential economic benefit is staggering. What proportion of your
programming time do you spend debugging today?

If people see the distinctions between "functional" and "non-functional"
languages purely in syntactic terms, then this whole discussion is
really no deeper than yet another Ruby vs. Python debate.

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Simen Edvardsen
Guest
Posts: n/a
 
      08-10-2006
On 8/10/06, Francis Cianfrocca <(E-Mail Removed)> wrote:
> This thread has probably gone on long enough


Probably.

>
> I find it very revealing that you see the primary (borrowable) value in
> functional languages as coming primarily from *syntactic* elements.
> Again I may be misreading you, but you can get syntactic innovations
> from anywhere. The thing that really distinguishes functional programs
> is that you can reason mathematically (and one hopes, automatically)
> about their correctness. Rather than being stuck with the whole sorry
> round of unit-test/debug/regress/repeat that we use with Ruby and every
> other non-functional language. Apart from the reference to Ada/Diana (a
> sub-language with a rigorous formal semantics), I haven't heard anyone
> on this thread try to relate this benefit of functional languages to
> non-functional ones.
>


You can reason mathematically about the correctness of a pure FP
program, but not about the time and effort it took to create it. I see
productivity and maintainability as better arguments for using
functional languages.

> To answer someone else, the ability to automatically process programs is
> why I'm interested in mini-languages (DSLs) written in Ruby that are
> non-Turing complete, because they may be decidable, if designed
> properly.


Any internal DSL has access to the whole of the parent language, and
so it can not be non-Turing complete as long as the parent language
is. Restricting access to features of the parent language to get this
automatical correctness tester or whatever to work seems plain silly.
Besides, there's no mathematical notation for a programmers intent,
and probably never will be, so a processor will probably never be able
to prove that a program does what its author intended to do.

> If people see the distinctions between "functional" and "non-functional"
> languages purely in syntactic terms, then this whole discussion is
> really no deeper than yet another Ruby vs. Python debate.


True.

--
- Simen

 
Reply With Quote
 
M. Edward (Ed) Borasky
Guest
Posts: n/a
 
      08-10-2006
Simen Edvardsen wrote:
> On 8/10/06, Francis Cianfrocca <(E-Mail Removed)> wrote:
>> This thread has probably gone on long enough

>
> Probably.

Well ... I've sort of stood back the past day, except for spotting some
semi-hemi-demi-quasi relevant web links courtesy of the ACM and
del.icio.us. But the fundamental discussion here is highly
interesting, and certainly relevant if Ruby is to be a "significantly
better language" than its scripting cousins Perl, Python and PHP, or
other programming languages in general. Among the *popular* languages,
Ruby seems to be more "computer-science-aware" than any of the others.

As I've noted, I got interested in proving programs correct in the early
1970s, when I was in graduate school but not as a computer science
student. I continued that interest, collecting books on the subject and
attempting to introduce the concepts at my workplace when I became a
professional programmer again upon my escape from graduate school. I
still have most of the books, although I haven't looked at them recently.

I still look at the literature on this subject occasionally, although
I'm much more interested in the literature on the Markov/queuing/Petri
net/performance modeling arena of computer science now than the
"correctness" arena.


>> The thing that really distinguishes functional programs
>> is that you can reason mathematically (and one hopes, automatically)
>> about their correctness. Rather than being stuck with the whole sorry
>> round of unit-test/debug/regress/repeat that we use with Ruby and every
>> other non-functional language. Apart from the reference to Ada/Diana (a
>> sub-language with a rigorous formal semantics), I haven't heard anyone
>> on this thread try to relate this benefit of functional languages to
>> non-functional ones.

I don't think it's necessarily either functional syntax or semantics
that makes this possible, but restrictions on the size of programs,
strong and static typing, restrictions on non-reversible operations like
assignment, etc. Yes, Dijkstra's maxim, "Testing can only show the
presence of defects, never their absence," is true. But I have seen
(tiny) FORTRAN programs proved correct, (tiny) Lisp programs proved
correct, and as I noted a post or two ago, I think the original effort
applied to a program expressed as a (small) flowchart.
>> To answer someone else, the ability to automatically process programs is
>> why I'm interested in mini-languages (DSLs) written in Ruby that are
>> non-Turing complete, because they may be decidable, if designed
>> properly.

>
> Any internal DSL has access to the whole of the parent language, and
> so it can not be non-Turing complete as long as the parent language
> is. Restricting access to features of the parent language to get this
> automatical correctness tester or whatever to work seems plain silly.
> Besides, there's no mathematical notation for a programmers intent,
> and probably never will be, so a processor will probably never be able
> to prove that a program does what its author intended to do.

Well ...

1. No programmer I've ever known has stood by idly while someone took
Turing completeness away from him or her, either deliberately or
accidentally.
2. Part of the whole "science" of proving programs correct is designing
ways for the customer to formally specify what a program must do to be
correct. A processor not only has to know what the programmer intended
but what the customer wanted as well.

In any event, the academic thread that appears to have the strongest
legs these days in the whole realm of proving reliability of our
software is the Pi-calculus. Most of what I've seen (which is the
abstract of one paper!) is in reference to Erlang. See
http://www.erlang.se/workshop/2006/. I'm not at all familiar with Erlang
the language, although I'm quite familiar with Erlang the queueing
theorist. I downloaded and installed it, though.

 
Reply With Quote
 
Francis Cianfrocca
Guest
Posts: n/a
 
      08-10-2006
On 8/10/06, M. Edward (Ed) Borasky <(E-Mail Removed)> wrote:
> 1. No programmer I've ever known has stood by idly while someone took
> Turing completeness away from him or her, either deliberately or
> accidentally.
> 2. Part of the whole "science" of proving programs correct is designing
> ways for the customer to formally specify what a program must do to be
> correct. A processor not only has to know what the programmer intended
> but what the customer wanted as well.



Ed, the biggest problem with abstruse conversations like this is when
you get two or three guys who enable each other and keep it going .

To take a step back from CS, here's the high-level thing that really
troubles me: why is there such an impedance mismatch between the
things we need to achieve in software and the available tools? Why do
I always feel like it takes mountains of "code" to do things that can
be described without too much difficulty? I'm not saying that
genuinely complex problems should be reducible beyond what makes
sense. I'm also not underrating the difficulty of good software design
or the difficulty of communicating well with the clients. But I'd
rather that *most* of the effort go into those areas. As things stand,
I have to solve a lot of computer-language-generated problems that do
not contribute value to the solution. It's like our machines have too
much friction.


I would *gladly* give up Turing-completeness in order to get a
(domain-specific) language that was more expressive (less
"frictional") in terms of the problems I need to solve. I've been
trying to present an intuition (which I don't know how to prove or
disprove) that the practical power required to solve circumscribed
problems does not come from Turing completeness, which of course *is*
required to solve general computing problems. Much depends on how you
define (and constrain) the problem space, and we need to get better
and more disciplined about that.

If this sounds like the old Lisp mantra of "design a language to fit
your problem and then just use that language," well, yes. How does one
do it effectively, though? You mentioned techniques for making
general-purpose programs easier to reason about, and they boiled down
to making them "smaller" in multiple dimensions. But our problem
domains are big and getting bigger. So something is missing. Back to
impedance mismatch again.

I'm going to try to have the discipline to stand back from this thread
now because until I can prove some of this crap I've been spouting, I
don't think I'm adding much value.

 
Reply With Quote
 
Chad Perrin
Guest
Posts: n/a
 
      08-10-2006
On Thu, Aug 10, 2006 at 05:12:37PM +0900, Francis Cianfrocca wrote:
>
> This thread has probably gone on long enough but as I read it, what
> you're saying here amounts simply to "let's take what's good from each
> approach and apply it generally." Can't argue with that.


Yeah, that one's usually difficult to argue. Since the first time I
started working with a language that allowed (actually encouraged)
prefix notation, I've wished for other languages I've used to allow it
as well (such as Perl, et cetera -- though I suppose I could write a
module to handle that, or possibly even find one in CPAN).


>
> I find it very revealing that you see the primary (borrowable) value in
> functional languages as coming primarily from *syntactic* elements.
> Again I may be misreading you, but you can get syntactic innovations
> from anywhere. The thing that really distinguishes functional programs
> is that you can reason mathematically (and one hopes, automatically)
> about their correctness. Rather than being stuck with the whole sorry
> round of unit-test/debug/regress/repeat that we use with Ruby and every
> other non-functional language. Apart from the reference to Ada/Diana (a
> sub-language with a rigorous formal semantics), I haven't heard anyone
> on this thread try to relate this benefit of functional languages to
> non-functional ones.


My commentary about a functional "style" being largely centered around
syntax wasn't meant to indicate that only the syntax of functional
programming should be borrowed. In fact, while there are certain
syntactic features that might be borrowed from functional languages for
certain purposes in Ruby, I think Ruby's syntax is pretty much perfect
for it as it is. It might be nice to borrow a little more from its
semantic structure, too, though.

I'm not really sure how that could be accomplished without causing
problems for some of the excellent characteristics already embodied by
Ruby, though. If we made Ruby too "functional", it would just be a Lisp
dialect anyway -- and while Lisp is great, so is Ruby.


>
> To answer someone else, the ability to automatically process programs is
> why I'm interested in mini-languages (DSLs) written in Ruby that are
> non-Turing complete, because they may be decidable, if designed
> properly. That opens the way (in theory) to the kind of automatic
> correctness analyzers that you see in pure functional programming. The
> potential economic benefit is staggering. What proportion of your
> programming time do you spend debugging today?


That certainly sounds useful.


>
> If people see the distinctions between "functional" and "non-functional"
> languages purely in syntactic terms, then this whole discussion is
> really no deeper than yet another Ruby vs. Python debate.


I'm really not a fan of Python. It's just . . .

Oh, wait, scratch that -- I don't want to start a flame war.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham

 
Reply With Quote
 
Chad Perrin
Guest
Posts: n/a
 
      08-10-2006
On Thu, Aug 10, 2006 at 11:26:01PM +0900, Francis Cianfrocca wrote:
>
> To take a step back from CS, here's the high-level thing that really
> troubles me: why is there such an impedance mismatch between the
> things we need to achieve in software and the available tools? Why do
> I always feel like it takes mountains of "code" to do things that can
> be described without too much difficulty? I'm not saying that
> genuinely complex problems should be reducible beyond what makes
> sense. I'm also not underrating the difficulty of good software design
> or the difficulty of communicating well with the clients. But I'd
> rather that *most* of the effort go into those areas. As things stand,
> I have to solve a lot of computer-language-generated problems that do
> not contribute value to the solution. It's like our machines have too
> much friction.
>
>
> I would *gladly* give up Turing-completeness in order to get a
> (domain-specific) language that was more expressive (less
> "frictional") in terms of the problems I need to solve.


For that, you pretty much have to choose the language that is least
"frictional" for the specific task you've undertaken. For certain web
development tasks, nothing beats PHP -- PHP programming mostly consists
of looking up already extant core language functions and gluing them
together with some control structures. For something that doesn't
neatly, and roughly exactly, fit the mold of any of PHP's core
functions, you tend to find yourself battling the language quite a lot,
fighting with its half-baked semantic structure and trying to squeeze
blood from its very anemic syntax. Perl provides a (slightly less, but
still) very accessible analog to the PHP core function bucket in the
form of CPAN, but you have to choose our modules wisely -- meanwhile,
Perl's semantic structure is better designed and more enabling, while
its syntax is far, far richer, but you have to be careful about how you
write programs so that you don't do something you won't understand later
(like, tomorrow) and be unable to maintain. It's easy to write
maintainable Perl, contrary to the common "wisdom", but it takes
attention to detail to do so.

Lisp is about the best language you'll ever find for metaprogramming.
If you're going to be working on a large project with many people,
you're better off using a language that handles OOP better than Perl's
tacked-on object model. Ruby manages this excellently, as does
Smalltalk. There are other reasons to use each as well, but I'm getting
tired of describing languages, so I'll keep this short.

The point is that you're probably best served for any nontrivial
programming task by choosing the right language for the job from among
Turing-equivalent/Turing-complete languages that already exist. Each
has its own benefits in terms of enabling easier solutions for the
problems at hand, and to get some of that enabling you have to trade off
with other enabling (at least, you do if you want your language
interpreter to finish parsing code this century).

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors. A program
is what you give the audience." - Larry Wall

 
Reply With Quote
 
Chad Perrin
Guest
Posts: n/a
 
      08-10-2006
On Wed, Aug 09, 2006 at 01:41:32PM +0900, M. Edward (Ed) Borasky wrote:
> Chad Perrin wrote:
> >perception that has grown from "we did it first" syndrome. I think it
> >boils down to the fact of Greenspun's Tenth Rule:
> >
> > Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C
> > or Fortran program contains an ad-hoc, informally-specified bug-ridden
> > slow implementation of half of Common Lisp."
> >

> Well ... I think I disagree with this, having written some moderately
> complicated FORTRAN programs and having read through many more. What
> they all almost always contain, however, is a domain-specific language
> that controls where they find their inputs, what processing the do on
> them, where they put their outputs and in what formats, etc., on what we
> used to call "control cards". Some of the parsers and DSLs of this
> nature are quite complex and rich, but they are in no sense of the word
> "Lisp".


I'm not really sure how to address this in a manner that gets my
understanding of Greenspun's Tenth Rule across (that's why it has taken
me this long to reply). I guess, to solve the problem of figuring out
what's going on with the complicated FORTRAN problems you indicate, you
could hand them to a long-time Lisp programmer who also knows some
FORTRAN and ask him or her to point out any Lisplike semantics you've
implemented in the process of developing fully-contained domain specific
languages as part of solving your problem, assuming there are any such
examples of Greenspun's Tenth Rule in action. Perhaps there aren't.

Maybe we should ask Greenspun.


>
> Curiously enough, if you read Chuck Moore's description of the evolution
> of FORTH, you'll find something similar -- every sufficiently
> complicated FORTRAN program contained a huge "case" statement which was
> a "language interpreter".


Not to be insulting, or anything, but perhaps Greenspun's Tenth Rule
should have specified that these FORTRAN programs were "well-written".
If you're implementing a nontrivial domain-specific language within a
program entirely by way of case/switch statements, I shudder to
contemplate the source code. Then again, I've never written a complex
program in FORTRAN, nor bothered to figure out how I might do so --
perhaps that's the only way to do it.


>
> By the way, one of the classic "demonstrations of Artificial
> Intelligence", ELIZA, was written not in Lisp but in a list-processing
> language patterned on Lisp but implemented in (pregnant pause) FORTRAN.
> But the SLIP interpreter, rather than being "sufficiently complicated"
> was in fact "delightfully simple."


I'm pretty sure Greenspun didn't mean to say that creating a (partial)
Lisp implementation was itself complicated -- only that the problems
that necessitate doing so are complicated.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."

 
Reply With Quote
 
M. Edward (Ed) Borasky
Guest
Posts: n/a
 
      08-13-2006
Francis Cianfrocca wrote:
> Ok, so how about this for a hypothesis?


> So here's my hypothesis: find a radically different discpline for building
> large systems in which "components" are developed using non-FP languages
> like Java and Ruby and even C++. These components are much coarser-grained
> than the ones you normally think of from object-orientation. They are more
> like relatively large subsystems, but self-contained and fully
> unit-testable. The idea is that the upper size limit for these functional
> blocks is correlated with the point at which (speaking informally) they
> become "too hard" to debug.
>
> Now take these components, which have side effects like writing databases,
> sending purchase orders, etc etc, and knit them together into larger
> systems
> using a pure functional language. This captures the intuition that no
> program should ever get too "large" in terms of function points, but also
> the distinction between functional components (which are most easily
> written
> imperatively) and large-scale process definitions (which are most easily
> written functionally).


1. Hmmm ... can/should the "top-level" part of this be done in Ruby as well?

2. "Can your programming language do this?"

http://www.joelonsoftware.com/items/2006/08/01.html

3. Can "MapReduce" be implemented in Ruby?

http://labs.google.com/papers/mapreduce.html


Why the heck should *Erlang* programmers have all the fun?



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Nice historical Musical - VERY RELAXING - about LISP history -fundamental ideas of LISP nanothermite911fbibustards C++ 0 06-16-2010 09:47 PM
pat-match.lisp or extend-match.lisp in Python? ekzept Python 0 08-10-2007 06:08 PM
the perens in lisp dilects is there for a reson... macros. atbusbook@aol.com Python 1 08-05-2006 04:30 PM
the perens in lisp dilects is there for a reson... macros. atbusbook@aol.com Perl Misc 0 08-05-2006 06:42 AM
Bruce Perens: The Emerging Economic Paradigm of Open Source Have A Nice Cup of Tea NZ Computing 0 04-12-2006 07:06 AM



Advertisments