Re: How suited are purely functional programming languages for I/O-intensive and database-related applications?

[Note: The previous message of identical following content was dated
incorrectly and subsequently rescinded, because I had forgotten to
reset my system clock after changing the settings temporarily. If you
had still received a previous copy of this message with identical
content, please ignore that message, and replace that message with
this message.]

On Thu, 11 Jun 2009 15:40:47 -0700, John Clements
<clements-USm5ewCNdr/ECKqllllIWg@xxxxxxxxxxxxxxxx> wrote:


On Jun 11, 2009, at 1:30 AM, Benjamin L.Russell wrote:


Unfortunately, Smalltalk is an object-oriented language. If possible,
I would like to see something similar in a more functional programming
language such as PLT Scheme.

It's not my intent to dissuade you from contributing to PLT Scheme,
but I would caution you against lumping Smalltalk in with languages
like Java and C++; Smalltalk is the "real" OO (cf. Matthias' talk),
and includes most of the features you'd expect to find in a functional
language. In fact, Smalltalk's syntax for introducing a closure is
lighter-weight than Scheme's, and allows a fairly natural-looking if
that's a function rather than a special form. Honestly, calling a
language "OO" doesn't really mean much, these days (cf. Shriram's
"post-linnean" stuff).

Actually, I never "lump[ed] Smalltalk in with languages like Java and
C++"; in fact, if you read my post "Re: A question regarding a
thesis.," dated "Wed, 10 Jun 2009 21:35:17 +0900," on
comp.lang.functional (see
http://groups.google.co.jp/group/comp.lang.functional/msg/934bbd4d6d550171),
you will see that I have specifically distinguished between Smalltalk
and such languages as Java and C++; _viz._:

[S]ome languages (such as Smalltalk
and Ruby) are pure object-oriented languages, whereas other languages
that claim to be "object-oriented," such as Java and C++, are really
procedural with some object-oriented features (see under the section
"Some Real Life Examples" in "What is Object-Oriented Software? An
Introduction" (http://www.softwaredesign.com/objects.html) for a more
detailed explanation of this difference).

Rather, my concern comes from the fact that, being more used to
thinking functionally than in an object-oriented manner, functional
programming lies more in my comfort zone. The idea of a "comfort
zone" for functional programming is perhaps best expressed by Paul
Hudak in the following portion of his post regarding another
functional programming language, Haskell, in his following post,
entitled "a regressive view of support for imperative programming in
Haskell," dated "Wed Aug 8 14:20:39 EDT 2007," on the Haskell-Cafe
mailing list, as follows (see
http://www.haskell.org/pipermail/haskell-cafe/2007-August/030178.html):

Functions are in my comfort zone; syntax that hides them takes me out of
my comfort zone.

[...]

Well, you could argue, monad syntax is what really made Haskell become
more accepted by the masses, and you may be right (although perhaps
Simon's extraordinary performance at OSCOM is more of what we need). On
the other hand, if we give imperative programmers the tools to do all
the things they are used to doing in C++, then we will be depriving them
of the joys of programming in the Functional Way. How many times have
we seen responses to newbie posts along the lines of, "That's how you'd
do it in C++, but in Haskell here's a better way...".

This issue is not specific to Haskell, but common to other functional
(and semi-functional) programming languages as well. It relates to
being used to thinking in a particular paradigm (even though some may
argue that paradigms in general are silly and meaningless, that issue
is separate from the issue of being used to thinking in one).

Smalltalk, as a pure object-oriented language, indeed has certain
advantages over impure object-oriented languages, such as Java or C++,
but it usually takes more time for a functional programmer who is used
to thinking in purely functional concepts to learn to think in
object-oriented concepts (even pure ones) than to learn a different
functional programming language using functional concepts.

Hence my search for a suitable language that would not require
learning a different paradigm.

-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
.

Relevant Pages

  • Re: UserLinux chooses Python as "interpretive language" of choice
    ... HV> tool available in a programming language? ... intersect with the usual notions of functional programming. ... John> that needs work, and has obviously needed work for a long time. ... Having functions as first-class objects doesn't mean you have to be able to ...
    (comp.lang.python)
  • Re: Amazing LINQ for .Net
    ... >>> dynamic typing, use a different language. ... why even use types at all, if Ruby apparantly is so great? ... functional programming concepts into OOP. ... C#'s new features that help facilitate a more functional approach as ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: What would be the best language to choose after programming Python for several years?
    ... anything not present in Python. ... The language must be opensource and with good reputation in the ... three I have come close to only Erlang, as I am an active CouchDB ... Statically-typed functional programming practitioners ...
    (comp.programming)
  • Re: Hashing and comparing of arrays
    ... language for many of these problems. ... I think a better functional programming support ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: SoA Vs OO
    ... Live with them until I find a better language :-) ... running this with postcondition checking enabled gives us ... but it does have one advantage: if a subclass redefines the ... > Does that mean you don't care for Smalltalk? ...
    (comp.object)
Loading