Why are functional programs shorter/faster to develop - choose better examples! 
Author Message
 Why are functional programs shorter/faster to develop - choose better examples!

  A> Wings3D is a good example of one class of example that Erlang et
  A> al need - but what's needed specifically to answer questions
  A> posed in this thread title are answers to questions like:

  A> 1. What applications are better written in language X than
  A> Java/C++/C#/VB (note, not 'what problems are better solved'), and
  A> what does 'better' mean.

Certainly any applications that require lots of concurrency and/or
distribution are much better written in Erlang than any of those
languages. Also, really complex applications are better written in
a functional language for all the reasons mentioned previously:
More concise programs, easier to reason about behaviour, etc.

Java is certainly the only choice for applet programming, and has
better graphics libraries. VB is good for slapping together useful
small apps in a Windows environment. C# is just scary, in my opinion.

  A> 2. How does language X allow faster/better development than
  A> any alternative.

Any alternative? You will never get any concensus on that one.
After all, software development is still very much a craft, and
different SW craftsmen seem to favour different tools. This probably
has something to do with the fact that there are many programming
styles, ranging from very analytical to highly experimental.

  A> 3. What mindset/paradigms/knowledge do you need to be on top of
  A> to use language X.

For Erlang, it helps if you have a solid understanding of concurrency.
Too much experience with OO (or rather, {*filter*}ion to OO) seems to be
more of a hindrance. ;)

Beyond that, most people pick it up after a few days of training,
and become productive within weeks. The middleware takes longer to
learn than the language itself.

  A> <Diversion> On a different point, I think the code snippet from
  A> Wings3D supports one of my arguments - the compactness of the
  A> code is a result of the semantic density of the constructs. There
  A> is a significantly higher barrier to entry for such languages,

All our experience of teaching Erlang indicates that the barrier to
entry is not high with Erlang. Some of the constructs that may seem
daunting at first take a few hours of getting used to. After a few
weeks/months of practice, they become almost second nature.

Personally, I'm disturbed by the endless parentheses of Lisp, the
lack of such in Haskell, and the constant jumping around when reading
Java code. But I realise that much of that comes from not spending
enough time in those environments in order to get used to the specific
feel of each language. Things like that do not have to be (and do not
appear to be) significant barriers in practice, except perhaps when
reading code snippets in newsgroups ;)

  A> </Diversion>

  A> I presume your point is about the feature to size/effort ratio.

Yes. A distributed database management system is a very complex
application with rather extreme demands on reliability.
An expressive and safe programming language helps tremendously.

Size _does_ matter... It's a lot easier to ponder over 20,000 lines
of code than over 1 million: it's easier to grasp the structure, easier
to spot the bugs, and easier to find bottlenecks. There is an obvious
correlation between code size and productivity/quality, even though
there is probably a limit to how dense you can make your programs before
they become illegible.

  A> BTW, the Mnesia FAQ says

  A> -------------------------------------------------
  A> 11.6. How much data can be stored in Mnesia?

  A> Dets uses 32 bit integers for file offsets, so the largest
  A> possible mnesia table (for now) is 4Gb. There are no doubt ways
  A> to work around this restriction.

  A> In practice your machine will slow to a crawl way before you
  A> reach this limit.

  A> -------------------------------------------------

  A> *way before* - That's not a criticism, but by analogy I think
  A> it's absolutely critical that the question of when *not* to use
  A> language is highlighted. One story of failure can destroy many
  A> stories of success.

The above is not a language issue. Mnesia was designed as a real-time
embedded DBMS for telecoms systems. We've designed some pretty large
systems with Mnesia and haven't even been close to that limit.
If you need a DBMS that's designed for storing gigabytes of data, you
can certainly buy one (there are several on the market), and interface
to it from your favourite language.

Having said that, I agree that it's important to also state what a
certain language implementation is less suitable for. I write "language
implementation" because it's quite often implementation details of
the VM, compiler or support libraries that get in the way.

The current Erlang implementations are not suited for hard real-time,
or for handling massive amounts of text. Nor are they well suited for
things like matrix inversion, or math-intensive applications in general.
If you want to write an application with a {*filter*} cross-plattform GUI,
you should probably at least do the GUI parts in some other language.

All these things are of course subject to change, but I will not ask
you to hold your breath -- simply pointing out that such statements
need to be revisited from time to time.

/Uffe



Sun, 12 Sep 2004 20:45:22 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!
Ulf,
     You don't need to convince me :) I've use(d) a variety of
languages, from assembler(s) to COBOL to C++ to APL to Java to Smalltalk
to Haskell etc, and I've read the Erlang manuals (pity about the string
handling!). I even wrote an GUI accounting package in TurboProlog in
'85. We are in {*filter*} agreement, but talking at cross purposes. My
concerns are with the practical matter of making languages better
known/more widely used in applications that will receive attention from
the 'great unwashed' i.e. dissemination and envangalism. I don't believe
that assertions from true believers do that - it's an old-fashioned
marketing problem.

Having said that ...

Quote:


>   A> 2. How does language X allow faster/better development than
>   A> any alternative.

> Any alternative? You will never get any concensus on that one.
> After all, software development is still very much a craft, and
> different SW craftsmen seem to favour different tools. This probably
> has something to do with the fact that there are many programming
> styles, ranging from very analytical to highly experimental.

Sorry, ambiguous - I didn't mean 'any' in that sense, I just meant that
for my purposes languages are best presented comparatively i.e. Erlang
compared to C++ or Haskell compared to Java etc. Not a 'Common Lisp is
bettter than every language every invented' argument. And by 'compared'
I mean everything from flavour to appearence to available libraries,
tools etc.

Quote:
>   A> 3. What mindset/paradigms/knowledge do you need to be on top of
>   A> to use language X.

> For Erlang, it helps if you have a solid understanding of concurrency.
> Too much experience with OO (or rather, {*filter*}ion to OO) seems to be
> more of a hindrance. ;)

> Beyond that, most people pick it up after a few days of training,
> and become productive within weeks. The middleware takes longer to
> learn than the language itself.

For people who are motivated to learn, you can get going in just about
any language pretty quickly. I've done it. My focus/argument is about
the approaches needed to get Jill/Joe average programmer casually
surfing the web to give it a go. Suck them in and show them something
interesting that they may try.

-------------------------
Antony Blakey

Linkuistics Pty Ltd
Adelaide, South Australia



Sun, 12 Sep 2004 21:10:31 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!

Quote:
> quicksort [] = []
> quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
> y>=x]

> This is obviously very short code! BUT, that is a consequence of
> Haskells built-in LPF (list processing functions/capacities). Ok, it's
> not a library but it boils down to the same.

I don't think it does. It is not some domain specific library. That was the
point of the orginal poster who mentioned some PLs beeing particulary good
in some domains due to specific domain libraries.

Quote:
> A good starting point was that article "Why functional programming
> matters". Basically it centered around using higher order functions to
> provide a new kind of glue to reuse program code. Ok, that was not
> bad, but I wonder if this is all?

Probably not all, but I'd say it's one of the most important features
becouse all FPL have it :-)
Pattern matching is great too.
Thinking about haskell other things come to mind like lazy evaluation which
is interesting, tail recursion etc...

I particulary like the way you can manipulate expressions ?algebraicly?
(this word does not exists does it?) to prove correctness of functions or
derive more efficient algorithms.

Quote:
> As far as I remember most examples
> dealed with list processing again. The few times I use lists is
> usually to just have a List of Objects in Java and then access them
> sequentially.

Yes, and probably most examples you see will deal with lists. That's like
saying some imperative code dealed with arrays... even though I've only
actually used Haskell as a FPL, from what I've seen lists is to FPL just
like arrays are to imperative lang.
There are also arrays in Haskell and I just use them in some more specific
situations (like when I won't do many updates but need fast index based
access), which is what you do in JAVA with lists.

Quote:
> I mean I don't think that higher order functions are
> that valuable in practice. At least in my coding experience it happens
> only few times where I think: "here a higher order function would come
> in handy." But maybe thats just the case because I have the wrong
> approach in my programs...

Of course! Now if you do learn FP style, you'll begin to see oportunities
to use HO functions *everywhere* when developing algorithms. I remember one
friend of mine who was not a big haskell fan telling me how much
he missed sometimes maps and folds and all that stuff in JAVA :-)
I know I do miss high order functions when I don't have them available.

J.A.



Sun, 12 Sep 2004 21:50:59 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!

  A> For people who are motivated to learn, you can get going in just
  A> about any language pretty quickly. I've done it. My
  A> focus/argument is about the approaches needed to get Jill/Joe
  A> average programmer casually surfing the web to give it a go. Suck
  A> them in and show them something interesting that they may try.

Agreed, that's a challenge.

Our experience of teaching Erlang has mainly been with Jill/Joe
Ericsson, who've been more or less ordered to learn Erlang. Not an ideal
situation, but experiences have been good overall.

As for how to get casual surfers interested, I don't know if anything
short of massive hype will do the trick.

/Uffe



Sun, 12 Sep 2004 22:35:05 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!

Quote:

> <Off topic even more>
> I'm sure that the biggest gains to be made in software engineering are
> in tool support for things like refactoring, pattern-directed
> programming, component composition and reuse etc, rather than languages.

I completely disagree on this point. Almost all "development tools"
that have ever come across in the commercial world give you the feel
of being productive without actually being it. Know why? - Because
the languages that they were operating on could not be easily reasoned
about and transformed automatically. It's interesting why people get
the feeling of being productive when they have successfully performed
a myriad of steps that could have been done by a machine as well.

Regards,
Markus Mottl

--

Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus



Mon, 13 Sep 2004 06:56:33 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!

Quote:
> Almost all "development tools"
> that have ever come across in the commercial world give you the feel
> of being productive without actually being it. Know why? - Because
> the languages that they were operating on could not be easily reasoned
> about and transformed automatically.

Quite the contrary, at least in the case of Smalltalk's Refactoring
Browser -- performing automatic transformations is exactly what the tool is
doing.  Smalltalk's simple syntax and semantics make it easy to perform
these transformations and make such a tool practical.

Quote:
> It's interesting why people get
> the feeling of being productive when they have successfully performed
> a myriad of steps that could have been done by a machine as well.

What tools do you have in mind that encourage people to carry out mindless
tasks?  If such tools exist, I'd say they are in need of being improved to
do such tasks automatically.  This just establishes Antony Blakey's point
even more strongly: good tools affect productivity perhaps even more than
choice of language.

If your point is that better languages *enable* the creation of better
tools, then I (and the Smalltalk community) certainly agree.



Mon, 13 Sep 2004 07:15:30 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!

: quicksort [] = []
: quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
: y>=x]
: This is obviously very short code! BUT, that is a consequence of
: Haskells built-in LPF

Not necessarily: replace "[y|y<-xs,y<=x]" with "(filter (<=x) xs)".
That's still list processing, but it's no longer built-in semantics.

-Greg



Mon, 13 Sep 2004 11:35:47 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!

Quote:

> What tools do you have in mind that encourage people to carry out mindless
> tasks?

I remember some OO-tools (toys) for "automatic" pattern recognition,
extraction and the like.

Quote:
> If such tools exist, I'd say they are in need of being improved to
> do such tasks automatically.

Maybe on more suitable languages...

Quote:
> This just establishes Antony Blakey's point even more strongly: good
> tools affect productivity perhaps even more than choice of language.

You haven't provided evidence for your claim. Just saying that your
development tools in Smalltalk make you very productive doesn't prove
that this makes them more important than the language. Indeed, if I were
evil, I could interpret this as Smalltalk being so bad that only tools
make you productive in it, but I won't do this... ;)

Quote:
> If your point is that better languages *enable* the creation of better
> tools, then I (and the Smalltalk community) certainly agree.

Languages are still the core of programming, no matter what tools you
use. Otherwise, we'd be working with code generators only by now.

Regards,
Markus Mottl

--

Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus



Mon, 13 Sep 2004 17:17:08 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!

....  If you stress non-imperativity too

Quote:
> much, you make it totally mysterious how (running) a functional
> program makes a difference to the world.

....

Quote of the year ?
I love it.

 Very true. I like to think about it this way:
Lazy programming is very usefull.
You cant figure out when things get evaluated in lazy programming...
this matters for side-effects (interacting with the outside
world).  You had better find
some way to control that... enter Monads, ("declaring the imperative"),
a sort of first class 'statement'.

...  (and other ways.. linear/unique types,  streams, contiuations, etc)

CHeers!



Mon, 13 Sep 2004 22:29:34 GMT  
 Why are functional programs shorter/faster to develop - choose better examples!

Quote:




>: quicksort [] = []
>: quicksort (x:xs) = quicksort [y|y<-xs, y<=x]++[x]++quicksort [y|y<-xs,
>: y>=x]
>: This is obviously very short code! BUT, that is a consequence of
>: Haskells built-in LPF

>Not necessarily: replace "[y|y<-xs,y<=x]" with "(filter (<=x) xs)".
>That's still list processing, but it's no longer built-in semantics.

I will play devil's advocate here and argue that functional programs
are not necessarily shorter and faster to develop. What are the
space and time performance of the above algorithm? How does
that compare to a quicksort in an imperative language?

My experience is that one can make prototype programs much faster
in a functional language than in any other language, Smalltalk
included. But *sometimes* one then has to spend a lot of time getting
the kind of time and space performance one gets from a standard
imperative language like C et al.

graham



Mon, 13 Sep 2004 23:45:19 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