mathementical/formal foundations of computing ?

2 independant issues here:

1. I'm still searching for material re. "the mathementical/formal
foundation[s] of computing" to help move programming away from an
art towards a science. Patterns seem to be a heuristic step in that
direction ?

Here's some text re. the language :joy
http://www.latrobe.edu.au/philosophy...oy/j00ovr.html
> Overview of the language JOY
> Two other functional languages are the combinatory logic of Curry and
> the FP language of Backus. They are not based on the lambda calculus,
> they eliminate abstraction completely and hence do not have to deal
> with substitution and environments. As a result these languages can be
> manipulated using simple algebraic techniques
> ........Backus acknowledges a dept to
> combinatory logic, but his aim was to produce a variable free notation
> that is amenable to simple algebraic manipulation by people. Such ease
> should produce clearer and more reliable programs. .........
> Paulson remarked that "Programming and pure mathematics are
> difficult to combine into one formal framework". Joy attempts this task.

2. the second issue is about how NOT to write tutors.
The correct way is to chain-backwards from the goal.
Ie. put the 'bottom line' first, so the reader knows if he wants
to invest the labour to 'build forward' towards the goal.

I've been reading pages of the details of 'joy', without knowing
if & when & how it will claim to allow manipulation of 'joy code'
in a formal, mathematical way.

Q - does anybody know if joy can help me reach that goal ?

I don't want to learn another language which is a hybrid of forth, lisp
& pop-11 just to repeat "hello world: 2+3=5".

The correct way to present the capabilities which I/we seek is:

1. In order to simplify/formalise/be-able-to-prove-XYZ, we
need to have the 'format ABC'.

2. This is acheived by transforming .....

3. On the basis of proven rules & manipulations ...

Ie. don't start with pages of rules & manipulations, where the
reader doesn't know if the effort will take him towards his goal.


== Chris Glur.

news{}absamail.co.za wrote:

> I don't want to learn another language which is a hybrid of forth, lisp
> & pop-11 just to repeat "hello world: 2+3=5".

pop-11 is /already/ viewable as a hybrid of forth and lisp.

--
Chris "electric hedgehog" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/

On Feb 22, 9:50 am, n...{}absamail.co.za wrote:
> 1. I'm still searching for material re. "the mathementical/formal
> foundation[s] of computing" to help move programming away from an
> art towards a science. Patterns seem to be a heuristic step in that
> direction ?

This may be the boy scout who helped the little old lady across the
street who did not want to cross the street.

The target of moving some aspects of programming from an art (ie,
craft) to a science is not to move all of programming to a science,
but to clear clutter from the palette to provide more leverage to the
craft of design.

Its like the move from pen to typewriter to word processor ... the
goal is not to eliminate the writer from the act of writing, it is to
reduce the effort of recording and editing the written word so that
attention can be focused on the actual composition.

On Feb 22, 7:50 am, n...{}absamail.co.za wrote:
> 2 independant issues here:
>
> 1. I'm still searching for material re. "the mathementical/formal
> foundation[s] of computing" to help move programming away from an
> art towards a science. Patterns seem to be a heuristic step in that
> direction ?
>
> Here's some text re. the language :joyhttp://www.latrobe.edu.au/philosophy/phimvt/joy/j00ovr.html
>
> > Overview of the language JOY
> > Two other functional languages are the combinatory logic of Curry and
> > the FP language of Backus. They are not based on the lambda calculus,
> > they eliminate abstraction completely and hence do not have to deal
> > with substitution and environments. As a result these languages can be
> > manipulated using simple algebraic techniques
> > ........Backus acknowledges a dept to
> > combinatory logic, but his aim was to produce a variable free notation
> > that is amenable to simple algebraic manipulation by people. Such ease
> > should produce clearer and more reliable programs. .........
> > Paulson remarked that "Programming and pure mathematics are
> > difficult to combine into one formal framework". Joy attempts this task.
>
> 2. the second issue is about how NOT to write tutors.
> The correct way is to chain-backwards from the goal.
> Ie. put the 'bottom line' first, so the reader knows if he wants
> to invest the labour to 'build forward' towards the goal.
>
> I've been reading pages of the details of 'joy', without knowing
> if & when & how it will claim to allow manipulation of 'joy code'
> in a formal, mathematical way.
>
> Q - does anybody know if joy can help me reach that goal ?
>
> I don't want to learn another language which is a hybrid of forth, lisp
> & pop-11 just to repeat "hello world: 2+3=5".
>
> The correct way to present the capabilities which I/we seek is:
>
> 1. In order to simplify/formalise/be-able-to-prove-XYZ, we
> need to have the 'format ABC'.
>
> 2. This is acheived by transforming .....
>
> 3. On the basis of proven rules & manipulations ...
>
> Ie. don't start with pages of rules & manipulations, where the
> reader doesn't know if the effort will take him towards his goal.
>
> == Chris Glur.

Responding to News...

> 1. I'm still searching for material re. "the mathementical/formal
> foundation[s] of computing" to help move programming away from an
> art towards a science. Patterns seem to be a heuristic step in that
> direction ?

I don't think the mathematics of computing is the way to move software
development from art to science. That's already been done with the
hardware computational models and the graph/set theory that underlies
all 3GLs. The computing domain is already quite rigorously defined.

Today the art lies in mapping the informally defined customer space into
the formally defined computing space and the black art lies in project
management of all the processes that /surround/ the intellectual
activities of creating software.

Forty-odd years ago I saw estimates that it would take 1000 developers
10 years to develop a 1 MLOC application. Today a 1 MLOC application is
considered small and a 100 KLOC application is a toy. So I think we have
pretty much made a science of creating applications.

One way that is manifested is the advent of practical general purpose
4GLs and semantic model frameworks like MDA in the late '90s. When we
compile such computing-independent 4GLs we are well on the way to
completely automating the entire computing space. One simply can't have
translation-based development if the computing space was not already
defined rigorously.

Mathematics and other scientific approaches will undoubtedly play a part
in making requirements specification and software project management
sciences. But I think those approaches will be quite different than
those underlying the computing space. So I don't think looking at
computer languages like Joy is likely to move art to science quickly.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl{}pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info{}pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

> 1. I'm still searching for material re. "the mathementical/formal
> foundation[s] of computing" to help move programming away from an
> art towards a science.

ever tried algorithms ?

ever tried Google with keyword: Lisp (where functions are data)

also, http://www.cs.mu.oz.au/research/mercury/

> Patterns seem to be a heuristic step in that direction ?


you mean Desgn-Patterns ?


> Here's some text re. the language :joyhttp://www.latrobe.edu.au/philosophy/phimvt/joy/j00ovr.html
>
> > Overview of the language JOY
> > Two other functional languages are the combinatory logic of Curry and
> > the FP language of Backus. They are not based on the lambda calculus,
> > they eliminate abstraction completely and hence do not have to deal
> > with substitution and environments. As a result these languages can be
> > manipulated using simple algebraic techniques
> > ........Backus acknowledges a dept to
> > combinatory logic, but his aim was to produce a variable free notation
> > that is amenable to simple algebraic manipulation by people. Such ease
> > should produce clearer and more reliable programs. .........
> > Paulson remarked that "Programming and pure mathematics are
> > difficult to combine into one formal framework". Joy attempts this task.
>
> 2. the second issue is about how NOT to write tutors.
> The correct way is to chain-backwards from the goal.
> Ie. put the 'bottom line' first, so the reader knows if he wants
> to invest the labour to 'build forward' towards the goal.
>
> I've been reading pages of the details of 'joy', without knowing
> if & when & how it will claim to allow manipulation of 'joy code'
> in a formal, mathematical way.
>
> Q - does anybody know if joy can help me reach that goal ?
>
> I don't want to learn another language which is a hybrid of forth, lisp
> & pop-11 just to repeat "hello world: 2+3=5".
>
> The correct way to present the capabilities which I/we seek is:
>
> 1. In order to simplify/formalise/be-able-to-prove-XYZ, we
> need to have the 'format ABC'.
>
> 2. This is acheived by transforming .....
>
> 3. On the basis of proven rules & manipulations ...
>
> Ie. don't start with pages of rules & manipulations, where the
> reader doesn't know if the effort will take him towards his goal.
>
> == Chris Glur.

i can not understand that as my a programming Newbie.

news{}absamail.co.za schrieb:
> 1. I'm still searching for material re. "the mathementical/formal
> foundation[s] of computing" to help move programming away from an
> art towards a science.

First, programming is a craft, not an art (though it *can* be art, just
as craft can be art).
Second, mathematics alone isn't going to help programming move along. It
won't help with getting customer requirements into something that can be
programmed (mathematics could even be an obstacle here), and it won't
help with getting bugs out of programs (which is a question of human
error, and quality testing: again, the obstacles here are more human
than technological, and mathematics isn't going to help with that).

That doesn't mean that mathematics is unimportant in programming, just
as an architect needs mathematics to do his work when calculating loads
and stability. However, it's just a tool, not an end to be pursued.

That said, "functional programming languages" are "more mathematical" in
some sense, and they do have properties that make it easier to avoid the
technical bugs, and a portion of the customer requirements bugs, too.
That's not because it's mathematics, it's because being nearer to
mathematics simplifies the semantics of these languages...

> Patterns seem to be a heuristic step in that direction ?

No. Patterns are just like tricks of the trade: helpful if you know what
you're doing, nonsensical if you don't.

> Here's some text re. the language :joy

Language rationales list what the designers had in mind.
I have observed that few if any languages actually do as the designer
intended. Most underperform; a few overperform (Lisp and PHP being the
cases where the difference is most marked). Fewer perform as expected
(Haskell, I think).

> 2. the second issue is about how NOT to write tutors.
> The correct way is to chain-backwards from the goal.
> Ie. put the 'bottom line' first, so the reader knows if he wants
> to invest the labour to 'build forward' towards the goal.

An interesting thought, though I can't tell whether that style will be
successful. It's good to determine whether a language (or other
technology) fits your needs, but it doesn't help with actually learning
it, so I fear this style won't become very popular.

Regards,
Jo

Joachim Durchholz <jo{}durchholz.org> writes:
> > 2. the second issue is about how NOT to write tutors.
> > The correct way is to chain-backwards from the goal.
> > Ie. put the 'bottom line' first, so the reader knows if he wants
> > to invest the labour to 'build forward' towards the goal.
>
> An interesting thought, though I can't tell whether that style will be
> successful. It's good to determine whether a language (or other
> technology) fits your needs, but it doesn't help with actually
> learning it, so I fear this style won't become very popular.

Reading this group makes me feel like the underwear gnomes from South
Park:

1. Abstract category theory, GADT, Curry-Howard isomorphism, etc.
2. ???
3. Software!

I've bought into it enough to be spending time banging my head against
learning Haskell, but it would help a lot if step 2 were explained
better.

news{}absamail.co.za wrote:
> 2 independant issues here:
>
> 1. I'm still searching for material re. "the mathementical/formal
> foundation[s] of computing" to help move programming away from an
> art towards a science. Patterns seem to be a heuristic step in that

That direction is a dead end. It is no more possible to create a
mathematical/formal foundation[s] of computing than it is to create one
of bridge or cathedral design. To be sure, mathematics is a useful tool
in the process, but we would have no Ponte Veccio or Chartres if it were
the foundation.

The foundation is craft. Math builds on that foundation.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

In article <7x7iuarlce.fsf{}ruckus.brouhaha.com>, Paul Rubin wrote:
>
> Reading this group makes me feel like the underwear gnomes from South
> Park:
>
> 1. Abstract category theory, GADT, Curry-Howard isomorphism, etc.
> 2. ???
> 3. Software!
>
> I've bought into it enough to be spending time banging my head
> against learning Haskell, but it would help a lot if step 2 were
> explained better.

Step 2 is:

2. Algebraic structures == insanely effective design patterns for libraries



--
Neel R. Krishnaswami
neelk{}cs.cmu.edu