Why are functional programs shorter/faster to develop? 
Author Message
 Why are functional programs shorter/faster to develop?

Quote:

> Any language can be safe
> in the sense that if you pass the wrong value in at runtime, it aborts
> with an error message.  Perl and python both qualify by that
> definition.

i'd understood that perl did not do this, but would silently coerce
types to "help" the programmer.  it's been a long time since i gave
up perl for other languages, so perhaps this has changed.

--
Garry Hodgson                   Let my inspiration flow
Senior Hacker                      in token rhyme suggesting rhythm
Software Innovation Services    that will not forsake me
AT&T Labs                          'til my tale is told and done.



Tue, 26 Oct 2004 03:11:34 GMT  
 Why are functional programs shorter/faster to develop?
Thanks! (I can relate to JCL...)

If I understood your explanation, it seems to me that "scripting" is a
kind of historical or poetic/metaphorical notion.  It used to be the
stuff that glued together or directed the `real' programs that
actually `did' things, but nowadays it does those things as well; it
used to be textual, and interpreted, but nowadays it's at least
semi-compiled.  Maybe it was once type-free, or string based, and a
nice medium for quickly hacking up one-off, stream-of-consciousness
programs; but nowadays it's typed, with decent data-structures. It has
just about sunk into the ooze and slime of general programming, but
there's a lingering scent of where it came from: not from the machine
level, but the top, job-oriented level.

Not the sort of thing one can nail down with a hard definition.
Is that something like it?

Peter Hancock



Tue, 26 Oct 2004 04:36:19 GMT  
 Why are functional programs shorter/faster to develop?

Quote:

> Function references is not the same as higher order functions.  But if
> you also have closures, then it would be a (totally) different story.

Please, this is confounding definitions.
Higher-order functions are functions that take other functions as
parameters. A language with function references allows writing
higher-order functions. (Witness the Standard Template Library in C++,
which uses higher-order functions on a regular basis.)
Of course, HOFs really start to fly if you have closures as well. They
are a desirable companion of HOF, but not a part of their definition.

Regards,
Joachim
--
This is not an official statement from my employer.



Tue, 26 Oct 2004 04:39:27 GMT  
 Why are functional programs shorter/faster to develop?

[...]

Quote:
> >>>OO is side-effect based: inheritance doesn't go along with returning the
> >>> modified object (eg: you can't specialize move :: A -> A with move :: A'
> >>> -> A' where A' subclass of A).
> >>>There are solutions (cf OCaml), but it's not an easy evolution for OO.
> >>>Fortunately, for dynamically typed languages, such typing problems do
> >>>not matter,

> >>On the contrary: if the dynamically typed program has such a type error,
> >>you'll get misbehaviour. It's just that the compiler will not complain, and if
> >>the misbehaviour is anticipated or reported as a bug, the programmer will drop
> >>in a type check.
> > I agree that it is unsafe. But i don't agree with the conclusion. The
> > main problem is that the OO-static-typing corset is unfit for the kind
> > of overloading you use in haskell.

> Well... agreed if you mean OO typing without parametric types (generics,
> templates).
> Most OO languages do have this though, and even Java will acquire it in the
> next version. So I don't think that this criticism of the "typical OO
> language" still holds.

it took me some time to answer this. I wanted to try this in various
languages to feel what they can achieve.

http://merd.net/pixel/language-study/various/non-mutable-objects-and-...

As far i've managed the C++ version, I can't manage to have
polymorphism between the functional objects.

- OCaml solves this for a->a functional objects (translate in my
example) using parametric polymorphism with bounded quantification (?)

- Haskell solves using existential types (syntax burden is quite high,
maybe my solution is not simplest)

i've also included less typed versions, and typical functional
version, but:

   #4 Haskell and #4 OCaml are the cleanest/simplest, but are not
objects
   and do not allow to separate Point2d and Point3d the OO way. The
   only way to have a special function working only on Point3d's is to
   raise an error when that function is called with a Point2d:

     get_z (Point2d _) = error "get_z called with a point2d"
     get_z (Point3d(_,_,z)) = z

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG



Tue, 26 Oct 2004 06:23:06 GMT  
 Why are functional programs shorter/faster to develop?

Quote:

>  > Not having this corset allow you to use non-mutable objects.

> Actually it's the other way round: With this corset, you cannot subtype
> mutable objects (which, in an OO language that's worth its name, means you
> can't *have* mutable objects).

hum, the object { x : ref double ; y : ref double ; z : ref double }
*is* a subtype of { x : ref double ; y : ref double }

what is wrong is
  mutable List(Point3d) < mutable List(Point2d)
but
  List(mutable Point3d) < List(mutable Point2d)
is true (see example below)

the subtyping problem with non-mutable objects I was talking about is:
 translate :: Point2d, Double -> Point2d
 translate :: Point3d, Double -> Point3d
where the second translate is not a subtype of the first, the OCaml
solution is:
 translate :: a, Double -> a  where a < Point2d
 translate :: a, Double -> a  where a < Point3d
where the first one explictly allow subsumption on the return type

example:
 l :: mutable List(Point3d)
 add :: mutable List(Point2d), Point2d -> ()
 add l point2d
 => l now contains a Point2d whereas its type is mutable List(Point3d)

whereas doing
 l :: List(mutable Point3d)
 moveit :: mutable Point2d -> ()
 moveit = fun p -> (p.x <- p.x + 1)
 iter moveit l
is ok

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG



Tue, 26 Oct 2004 06:25:10 GMT  
 Why are functional programs shorter/faster to develop?

Quote:


>> > Not having this corset allow you to use non-mutable objects.

>>Actually it's the other way round: With this corset, you cannot subtype
>>mutable objects (which, in an OO language that's worth its name, means you
>>can't *have* mutable objects).

> hum, the object { x : ref double ; y : ref double ; z : ref double }
> *is* a subtype of { x : ref double ; y : ref double }

The best way to handle this case isn't subtyping, it is a conversion
function
   Point3d :: Point2d -> Point3d
that wraps the Point2d into a Point3d that has a z component of 0.0 and
delegates all accesses to x and y to the embedded Point2d object.

Anyway. You're right, SOME mutable type pairs CAN be in a subtype
relationship. But there is  a large and interesting class of subtype
relationships that break down as soon as mutability is added. (Circle <
Ellipse for example.)

Quote:
> what is wrong is
>   mutable List(Point3d) < mutable List(Point2d)

Agreed.

Quote:
> but
>   List(mutable Point3d) < List(mutable Point2d)
> is true (see example below)

Agreed under the assumption that Point3d < Point2d.

Quote:
> the subtyping problem with non-mutable objects I was talking about is:
>  translate :: Point2d, Double -> Point2d
>  translate :: Point3d, Double -> Point3d
> where the second translate is not a subtype of the first,

Agreed (again assuming Point3d < Point2d for the sake of the argument).
However, this can be easily evaded: Let the second translate be
   translate :: Point2d, Double -> Point3d
and add a new function
   translate3d :: Point3d, Double -> Point3d
Agreed, it's not nice, and translate3d isn't polymorphic - but then
translate3d cannot be polymorphic anyway.

The issues become a little bit clearer if you use
   transform :: Point2d, Matrix2d -> Point2d
Now you have two different types of transforms: those that are parallel
to the XY plane (and represented by Matrix2d), which is the subtype of
the above transform. And a threedimensional transform that uses a
Matrix3d and is a quite different animal that wouldn't even make sense
to a Point2d.

 > the OCaml solution is:

Quote:
>  translate :: a, Double -> a  where a < Point2d
>  translate :: a, Double -> a  where a < Point3d
> where the first one explictly allow subsumption on the return type

Hmm... I think you mean "<=" where you wrote "<". (I'm not familiar with
OCaml anyway, so I don't really have an idea what this means or proves.)

Regards,
Joachim
--
This is not an official statement from my employer.



Tue, 26 Oct 2004 09:11:32 GMT  
 Why are functional programs shorter/faster to develop?

Quote:

> Is that something like it?

It's exactly what it is.
And that's why nobody agrees on a definition of what a scripting
language is. It's a distinction that doesn't make much sense anymore,
even though it's a handy pejorative against some historic languages.

Regards,
Joachim
--
This is not an official statement from my employer.



Tue, 26 Oct 2004 09:13:10 GMT  
 Why are functional programs shorter/faster to develop?
Re "what is a scripting language" - I personally think any useful
meaning has been lost as it has come to be used for almost any
interpreted language.  But one interesting classic meaning, esp.
as in "application scripting language", is apparently being
ressurrected in FP form - http://wouter.fov120.com/sheep/index.html




Tue, 26 Oct 2004 12:43:46 GMT  
 Why are functional programs shorter/faster to develop?

Quote:

> Higher-order functions are functions that take other functions as
> parameters. A language with function references allows writing
> higher-order functions. (Witness the Standard Template Library in C++,
> which uses higher-order functions on a regular basis.)

The definition in FOLDOC says that

  A function that can take one or more functions as argument and/or
  return a function as its value.

By this (and your) definition, a C function taking a function pointer
and returning that pointer untouched would be a HOF.  Okay, so you
are right about the definition, but then supporting higher-order
functions would be a no-brainer for a low level language.

That means I have even seen assembly libraries full of HOFs.  Wow.

--
Chuan-kai Lin



Tue, 26 Oct 2004 19:28:38 GMT  
 Why are functional programs shorter/faster to develop?

Quote:

>Please, this is confounding definitions.
>Higher-order functions are functions that take other functions as
>parameters. A language with function references allows writing
>higher-order functions. (Witness the Standard Template Library in C++,
>which uses higher-order functions on a regular basis.)
>Of course, HOFs really start to fly if you have closures as well. They
>are a desirable companion of HOF, but not a part of their definition.

May I ask you *where* you got that definition? My definition of HOF is
absolutely tied to the concept of closures. You wonder why? Well, first,
you should ask yourself *what* a function is. All (formal) language
semantics definition will tell you that a function *is* a closure (where,
it all depends "how" you read the semantics of course). It is definitely
not just a function pointer!! (which as any real HO-programmer will tell
you is a poor man's definition). Of course, everyone can make their own
definition, but Lord help us when C++ is called a functional programming
language.

Saying that the STL is HO, is almost an insult to the foundations of
functional programming. If FP is anything at all (that what most people
here will agree on, by which I mean not lazyness or even ref. trans.), it
is first-class functions.

        Kinds Regards,

        Simon



Tue, 26 Oct 2004 19:37:38 GMT  
 Why are functional programs shorter/faster to develop?

Quote:

>>>>>>Yes, it's string-based, and crusty, and not typesafe, and probably
>>>>>>fairly slow - but that's the normal tradeoff with scripting
>>>>>>languages.

>>>so if i declare that all scripting languages contain list
>>>comprehensions, i'd be correct,
>>You would need to show that your definition matches the
>>commonly-accepted idea of a scripting language, by looking at some
>>example languages and seeing whether they match.
>so the argument is "language X has these characteristics, like all
>Y languages, where i define Y languages as those which have these
>characteristics".

No.  The argument is (IIRC):

I define Y languages as those which have these characteristics - and
look, my definition seems to be generally correct, because most
languages in the set Y fit the definition, and those outside do not.

The characteristics I mentioned were not arbitrary, they are typical
of what *other people* call scripting languages.  If you disagree,
please mention some languages which are:

- generally considered 'scripting', but do not fit the description; or

- do fit the description, but are not usually thought of as 'scripting
  languages'.

If there aren't any, can we assume that the things I mentioned do
define what is a scripting language and what isn't - by most people's
modern-day reckoning of the term?

--

Finger for PGP key



Tue, 26 Oct 2004 20:52:20 GMT  
 Why are functional programs shorter/faster to develop?

Quote:

>>Any language can be safe in the sense that if you pass the wrong
>>value in at runtime, it aborts with an error message.  Perl and
>>Python both qualify by that definition.

>i'd understood that perl did not do this, but would silently coerce
>types to "help" the programmer.

Well there are some things which are coerced.  For example if you take
the string '55' and try to add 1 to it, it will be coerced into a
number.  The opposite coercion happens by taking 3.142 and appending
'hello' to it.  A third coercion is numbers and strings to booleans.

And there are some things which are not coerced, such as taking a
string and trying to call methods on it, or taking a reference to an
array and trying to do hash lookups on it.  These give a runtime
error.

Where you draw the line between these two varies from one language to
another, but all scripting languages have a bit of both.  Python for
example will silently coerce numbers and strings to booleans (as will
many compiled languages like C).

--

Finger for PGP key



Tue, 26 Oct 2004 20:59:01 GMT  
 
 [ 322 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software