Discussion:
How suited are purely functional programming languages for I/O-intensive and database-related applications?
(too old to reply)
Benjamin L. Russell
2009-06-11 09:29:22 UTC
Permalink
Today, I came across the following site (in Japanese) in which the
author made two claims about certain tasks that he believes that
purely functional programming languages are weak at. His claims are
interesting, and I would like to evaluate these claims through
discussion here:

Haskell $B$H$O(B ("About Haskell") [Japanese-language site]
http://www.shido.info/hs/haskell1.html

Specifically, he made the following claims concerning Haskell (after
describing that Haskell code is written so as to specify what value to
$B$3$N$3$H$+$i!"2<$G<($9$h$&$J<oN`$N%W%m%0%i%`$G$OM-8z$G$9!#(B
* $B?tCM7W;;(B: Numerical Recipes $B$K:\$C$F$$$k$h$&$J%"%k%4%j%:%`!#(B
* $BC5:w(B: $B5M$a>-4}$J$I$N7PO)$r5a$a$k$h$&$JLdBj!#(B
* $BIQHK$K(B IO $B$r9T$&%W%m%0%i%`(B: IO $B$J$I$NIT=c$J9T0Y$O(B Haskell $B$O6l<j!#(B
* $BBg$-$J%G!<%?%Y!<%9$r07$&%W%m%0%i%`(B: Haskell $B$O=c?h$J4X?t7?$J$N$G!"%G!<%?%Y!<%9$r>/$7$7$+(B
$BJQ99$7$J$$$H$-$G$bA4BN$r99?7$9$kI,MW$,$"$k!#(BIO $B7?$N%G!<%?9=B$$r;H$($P$3$NLdBj$O2sHr$G$-$k$,!"(B $BC1=c$G$O$J$$!#(B
Therefore, it is valid for the following types of programs.
* Numerical calculation: Algorithms such as those listed in Numerical Recipes.
* Searching: Problems in which a path is to be obtained, such as the Shogi Mating Problem.
* Parsing: Haskell's industry-standard compiler, GHC, is written in Haskell. Furthermore, there is a person who has
written Perl 6 in Haskell.
On the other hand, it is not suited for the following types of programs. While these can still be written, it is probably
easier to write them in another language. Furthermore, if such programs are written in Haskell, code similar to that written
in a procedural language will result.
* Programs performing frequent I/O: Haskell is weak at such impure behavior as I/O.
* Programs handling a large database: Since Haskell is purely functional, even if only a small portion of a database
needs to be modified, there is a necessity to update the entirety. If an I/O-type data structure is used, this problem can
be avoided, but it is not simple.

In particular, I would like to investigate his claim concerning
"Programs performing frequent I/O," since currently, my main interest
is in creating a virtual world using a collaborative multi-user online
virtual world application, such as Croquet (see
http://www.opencroquet.org/index.php/Main_Page) or Cobalt (see
http://www.duke.edu/~julian/Cobalt/Home.html). The challenge is to
create an massively multi-player online virtual world in a functional
programming language, because it seems that a multi-user online
virtual world application might be easier to write in a purely
object-oriented programming language such as Smalltalk, rather than in
a purely functional programming language, such as Haskell or Clean.

Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?

(My intuition is that since a purely functional programming language
would try to preserve referential transparency, it would discourage
side-effects, which would be necessitated by most I/O (unless a
special mechanism to preserve functional purity were provided, such as
monads or uniqueness typing), whereas in a purely object-oriented
programming language, even atomic operations would be performed as
messages passed between objects, and that therefore, for this type of
application, a purely object-oriented programming language would be
better suited than a purely functional programming language, but I
could be wrong. If you think that my intuition is mistaken, please
explain your reasoning.)

-- 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^
Ertugrul Söylemez
2009-06-11 14:40:09 UTC
Permalink
Post by Benjamin L. Russell
Today, I came across the following site (in Japanese) in which the
author made two claims about certain tasks that he believes that
purely functional programming languages are weak at. His claims are
interesting, and I would like to evaluate these claims through
Haskell とは ("About Haskell") [Japanese-language site]
http://www.shido.info/hs/haskell1.html
Specifically, he made the following claims concerning Haskell (after
describing that Haskell code is written so as to specify what value to
このことから、下で示すような種類のプログラムでは有効です。
* 数値計算: Numerical Recipes に載っているようなアルゴリズム。
* 探索: 詰め将棋などの経路を求めるような問題。
* 構文解析: Haskell の業界標準コンパイラー GHC は Haskell で書かれている。また、 Perl6 を Haskell で書いた人がいる。
一方、以下の種類のプログラムには向きません。書けないことはありませんが、 他の言語で書いたほうが楽でしょう。また、Haskell
でこれらのプログラムを書くと、 手続き型言語で書いたのと同じようなコードが出来上がります。
* 頻繁に IO を行うプログラム: IO などの不純な行為は Haskell は苦手。
* 大きなデータベースを扱うプログラム: Haskell は純粋な関数型なので、データベースを少ししか
変更しないときでも全体を更新する必要がある。IO 型のデータ構造を使えばこの問題は回避できるが、 単純ではない。
Therefore, it is valid for the following types of programs.
* Numerical calculation: Algorithms such as those listed in
Numerical Recipes.
* Searching: Problems in which a path is to be obtained, such
as the Shogi Mating Problem.
* Parsing: Haskell's industry-standard compiler, GHC, is
written in Haskell. Furthermore, there is a person who has
written Perl 6 in Haskell.
On the other hand, it is not suited for the following types of
programs. While these can still be written, it is probably easier
to write them in another language. Furthermore, if such programs
are written in Haskell, code similar to that written in a procedural
language will result.
* Programs performing frequent I/O: Haskell is weak at such
impure behavior as I/O.
I see no reason for that. In fact, Haskell in particular is very strong
at it, because of its great concurrency system.
Post by Benjamin L. Russell
* Programs handling a large database: Since Haskell is purely
functional, even if only a small portion of a database needs
to be modified, there is a necessity to update the entirety.
If an I/O-type data structure is used, this problem can be
avoided, but it is not simple.
That's completely wrong. One of the great advantages of immutability is
recycling: If you have a large data structure and need a copy of it
with only a tiny part changed, most of the structure is just reused. No
copying involved. Have a look at Data.Map to see this in action. Based
on Data.Map you can write a simple internal database server in a matter
of a few lines. See the example code in [1].

If your database server should exist throughout the entire lifetime of
your application, you can get rid of quitAction and the Quit command,
which saves some code, but usually there is no reason for that.

As you see all code working with the database-internal Map is entirely
pure. The 'modify' function of StateT takes the current state (the
current Map in this case) and passes it to a pure function, which
returns a new state. Yet no large copying is involved.

[1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=5776#a5776
Post by Benjamin L. Russell
In particular, I would like to investigate his claim concerning
"Programs performing frequent I/O," since currently, my main interest
is in creating a virtual world using a collaborative multi-user online
virtual world application, such as Croquet (see
http://www.opencroquet.org/index.php/Main_Page) or Cobalt (see
http://www.duke.edu/~julian/Cobalt/Home.html). The challenge is to
create an massively multi-player online virtual world in a functional
programming language, because it seems that a multi-user online
virtual world application might be easier to write in a purely
object-oriented programming language such as Smalltalk, rather than in
a purely functional programming language, such as Haskell or Clean.
Such a project requires good understanding of how to solve certain
problems in Haskell or Clean. It's well possible, but as a beginner you
may run into some problems because of language semantics, particularly
if you're used to non-functional and/or strict languages.
Post by Benjamin L. Russell
Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?
I would disagree entirely. What is really missing in Haskell is some
object-oriented constructs, but it should be easy to overcome this.
Post by Benjamin L. Russell
(My intuition is that since a purely functional programming language
would try to preserve referential transparency, it would discourage
side-effects, which would be necessitated by most I/O (unless a
special mechanism to preserve functional purity were provided, such as
monads or uniqueness typing), whereas in a purely object-oriented
programming language, even atomic operations would be performed as
messages passed between objects, and that therefore, for this type of
application, a purely object-oriented programming language would be
better suited than a purely functional programming language, but I
could be wrong. If you think that my intuition is mistaken, please
explain your reasoning.)
There is really nothing wrong with message passing and purity. One very
useful concept is functional reactive programming (FRP). That's what
you would typically use for a game server in Haskell. In FRP you
describe the relative dependencies between objects with respect to time.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Benjamin L. Russell
2009-06-11 05:53:27 UTC
Permalink
Post by Ertugrul Söylemez
[...]
That's completely wrong. One of the great advantages of immutability is
recycling: If you have a large data structure and need a copy of it
with only a tiny part changed, most of the structure is just reused. No
copying involved. Have a look at Data.Map to see this in action. Based
on Data.Map you can write a simple internal database server in a matter
of a few lines. See the example code in [1].
If your database server should exist throughout the entire lifetime of
your application, you can get rid of quitAction and the Quit command,
which saves some code, but usually there is no reason for that.
As you see all code working with the database-internal Map is entirely
pure. The 'modify' function of StateT takes the current state (the
current Map in this case) and passes it to a pure function, which
returns a new state. Yet no large copying is involved.
[1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=5776#a5776
Post by Benjamin L. Russell
In particular, I would like to investigate his claim concerning
"Programs performing frequent I/O," since currently, my main interest
is in creating a virtual world using a collaborative multi-user online
virtual world application, such as Croquet (see
http://www.opencroquet.org/index.php/Main_Page) or Cobalt (see
http://www.duke.edu/~julian/Cobalt/Home.html). The challenge is to
create an massively multi-player online virtual world in a functional
programming language, because it seems that a multi-user online
virtual world application might be easier to write in a purely
object-oriented programming language such as Smalltalk, rather than in
a purely functional programming language, such as Haskell or Clean.
Such a project requires good understanding of how to solve certain
problems in Haskell or Clean. It's well possible, but as a beginner you
may run into some problems because of language semantics, particularly
if you're used to non-functional and/or strict languages.
The "non-functional" experience part shouldn't be an issue, since the
other main language in my programming language concept-space is
Scheme, which is a semi-functional language; however, the "strict"
part could be an issue there.
Post by Ertugrul Söylemez
Post by Benjamin L. Russell
Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?
I would disagree entirely. What is really missing in Haskell is some
object-oriented constructs, but it should be easy to overcome this.
That would be nice, but is it really so? This is perhaps the gist of
the issue. Possible, yes, but easy?

To test my understanding, I'm going to see if it really works. Basing
the following example on the client-server example under "Using
Non-Object-Oriented Languages" in "What is Object-Oriented Software?
An Introduction" (see http://www.softwaredesign.com/objects.html),
suppose that I were running one process on a client and another
process on a server, and that the client-process and the
server-process were defining and communicating operations and
arguments to those operations in real-time. For concreteness, suppose
that the operation were '+', but that this operation were extended in
real-time on the client to include more and more types of arguments,
such as musical data, lists of inventory items for avatars, and even
gestures, with more definitions of '+' to be added in real-time by
users writing code on a client in real-time to be run on the server in
real-time.

If my understanding is correct, in a pure object-oriented language
such as Smalltalk, I could probably create a class on the client
called "gesture," as a subclass of another class "action" defined
separately, where "gesture" defines '+' as adding, say, a gesture of
an avatar (say, bowing) after a list of gestures to be executed
sequentially. For example:

a := Gesture fromAction: <some encoding for bowing>.
b := Gesture fromAction: <some encoding for waving>.
c := a + b.

Then c becomes a gesture for bowing followed by a gesture for waving,
to be executed on the server (which knew nothing about the definition
of '+' for gestures until receiving the definition of '+' for gestures
together with the definitions of gestures a and b).

The server then returns a gesture c which is a gesture for bowing
followed by a gesture for waving.

In Haskell, I would probably first think of using type classes to
extend types, but I am not sure whether type classes could be used on
a client in real-time to extend operations to be defined on new types
to be executed in real-time on a server.

Would this be easy to overcome without some object-oriented constructs
in Haskell?
Post by Ertugrul Söylemez
Post by Benjamin L. Russell
(My intuition is that since a purely functional programming language
would try to preserve referential transparency, it would discourage
side-effects, which would be necessitated by most I/O (unless a
special mechanism to preserve functional purity were provided, such as
monads or uniqueness typing), whereas in a purely object-oriented
programming language, even atomic operations would be performed as
messages passed between objects, and that therefore, for this type of
application, a purely object-oriented programming language would be
better suited than a purely functional programming language, but I
could be wrong. If you think that my intuition is mistaken, please
explain your reasoning.)
There is really nothing wrong with message passing and purity. One very
useful concept is functional reactive programming (FRP). That's what
you would typically use for a game server in Haskell. In FRP you
describe the relative dependencies between objects with respect to time.
Thank you for the reference to FRP. I shall look up FRP and see
whether I can use it to to overcome various challenges in
client-server communication concerning objects.

-- 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^
Benjamin L. Russell
2009-06-12 06:08:45 UTC
Permalink
[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
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
[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
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^
Benjamin L. Russell
2009-06-12 06:15:55 UTC
Permalink
[Note: The previous message was correctly dated and was meant to
replace another previous message which had correct content but the
wrong date. However, the replacing message had the correct date but
incorrect content copied from the wrong message. Please replace both
messages with this message.]
Post by Ertugrul Söylemez
[...]
That's completely wrong. One of the great advantages of immutability is
recycling: If you have a large data structure and need a copy of it
with only a tiny part changed, most of the structure is just reused. No
copying involved. Have a look at Data.Map to see this in action. Based
on Data.Map you can write a simple internal database server in a matter
of a few lines. See the example code in [1].
If your database server should exist throughout the entire lifetime of
your application, you can get rid of quitAction and the Quit command,
which saves some code, but usually there is no reason for that.
As you see all code working with the database-internal Map is entirely
pure. The 'modify' function of StateT takes the current state (the
current Map in this case) and passes it to a pure function, which
returns a new state. Yet no large copying is involved.
[1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=5776#a5776
Post by Benjamin L. Russell
In particular, I would like to investigate his claim concerning
"Programs performing frequent I/O," since currently, my main interest
is in creating a virtual world using a collaborative multi-user online
virtual world application, such as Croquet (see
http://www.opencroquet.org/index.php/Main_Page) or Cobalt (see
http://www.duke.edu/~julian/Cobalt/Home.html). The challenge is to
create an massively multi-player online virtual world in a functional
programming language, because it seems that a multi-user online
virtual world application might be easier to write in a purely
object-oriented programming language such as Smalltalk, rather than in
a purely functional programming language, such as Haskell or Clean.
Such a project requires good understanding of how to solve certain
problems in Haskell or Clean. It's well possible, but as a beginner you
may run into some problems because of language semantics, particularly
if you're used to non-functional and/or strict languages.
The "non-functional" experience part shouldn't be an issue, since the
other main language in my programming language concept-space is
Scheme, which is a semi-functional language; however, the "strict"
part could be an issue there.
Post by Ertugrul Söylemez
Post by Benjamin L. Russell
Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?
I would disagree entirely. What is really missing in Haskell is some
object-oriented constructs, but it should be easy to overcome this.
That would be nice, but is it really so? This is perhaps the gist of
the issue. Possible, yes, but easy?

To test my understanding, I'm going to see if it really works. Basing
the following example on the client-server example under "Using
Non-Object-Oriented Languages" in "What is Object-Oriented Software?
An Introduction" (see http://www.softwaredesign.com/objects.html),
suppose that I were running one process on a client and another
process on a server, and that the client-process and the
server-process were defining and communicating operations and
arguments to those operations in real-time. For concreteness, suppose
that the operation were '+', but that this operation were extended in
real-time on the client to include more and more types of arguments,
such as musical data, lists of inventory items for avatars, and even
gestures, with more definitions of '+' to be added in real-time by
users writing code on a client in real-time to be run on the server in
real-time.

If my understanding is correct, in a pure object-oriented language
such as Smalltalk, I could probably create a class on the client
called "gesture," as a subclass of another class "action" defined
separately, where "gesture" defines '+' as adding, say, a gesture of
an avatar (say, bowing) after a list of gestures to be executed
sequentially. For example:

a := Gesture fromAction: <some encoding for bowing>.
b := Gesture fromAction: <some encoding for waving>.
c := a + b.

Then c becomes a gesture for bowing followed by a gesture for waving,
to be executed on the server (which knew nothing about the definition
of '+' for gestures until receiving the definition of '+' for gestures
together with the definitions of gestures a and b).

The server then returns a gesture c which is a gesture for bowing
followed by a gesture for waving.

In Haskell, I would probably first think of using type classes to
extend types, but I am not sure whether type classes could be used on
a client in real-time to extend operations to be defined on new types
to be executed in real-time on a server.

Would this be easy to overcome without some object-oriented constructs
in Haskell?
Post by Ertugrul Söylemez
Post by Benjamin L. Russell
(My intuition is that since a purely functional programming language
would try to preserve referential transparency, it would discourage
side-effects, which would be necessitated by most I/O (unless a
special mechanism to preserve functional purity were provided, such as
monads or uniqueness typing), whereas in a purely object-oriented
programming language, even atomic operations would be performed as
messages passed between objects, and that therefore, for this type of
application, a purely object-oriented programming language would be
better suited than a purely functional programming language, but I
could be wrong. If you think that my intuition is mistaken, please
explain your reasoning.)
There is really nothing wrong with message passing and purity. One very
useful concept is functional reactive programming (FRP). That's what
you would typically use for a game server in Haskell. In FRP you
describe the relative dependencies between objects with respect to time.
Thank you for the reference to FRP. I shall look up FRP and see
whether I can use it to to overcome various challenges in
client-server communication concerning objects.

-- 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^
Ertugrul Söylemez
2009-06-12 23:51:46 UTC
Permalink
Post by Benjamin L. Russell
Post by Ertugrul Söylemez
Post by Benjamin L. Russell
Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?
I would disagree entirely. What is really missing in Haskell is
some object-oriented constructs, but it should be easy to overcome
this.
That would be nice, but is it really so? This is perhaps the gist of
the issue. Possible, yes, but easy?
To test my understanding, I'm going to see if it really works. Basing
the following example on the client-server example under "Using
Non-Object-Oriented Languages" in "What is Object-Oriented Software?
An Introduction" (see http://www.softwaredesign.com/objects.html),
suppose that I were running one process on a client and another
process on a server, and that the client-process and the
server-process were defining and communicating operations and
arguments to those operations in real-time. For concreteness, suppose
that the operation were '+', but that this operation were extended in
real-time on the client to include more and more types of arguments,
such as musical data, lists of inventory items for avatars, and even
gestures, with more definitions of '+' to be added in real-time by
users writing code on a client in real-time to be run on the server in
real-time.
If my understanding is correct, in a pure object-oriented language
such as Smalltalk, I could probably create a class on the client
called "gesture," as a subclass of another class "action" defined
separately, where "gesture" defines '+' as adding, say, a gesture of
an avatar (say, bowing) after a list of gestures to be executed
a := Gesture fromAction: <some encoding for bowing>.
b := Gesture fromAction: <some encoding for waving>.
c := a + b.
Then c becomes a gesture for bowing followed by a gesture for waving,
to be executed on the server (which knew nothing about the definition
of '+' for gestures until receiving the definition of '+' for gestures
together with the definitions of gestures a and b).
The server then returns a gesture c which is a gesture for bowing
followed by a gesture for waving.
In Haskell, I would probably first think of using type classes to
extend types, but I am not sure whether type classes could be used on
a client in real-time to extend operations to be defined on new types
to be executed in real-time on a server.
Would this be easy to overcome without some object-oriented constructs
in Haskell?
AFAIK currently you cannot implement behaviours on the client side to be
executed on the server side. This is not a limitation of the language,
but of the run-time system. For this to be reliable, either you need
some sort of RPC or an intermediate language (bytecode). There is
Glasgow Parallel Haskell (GPH), but it's based on a rather old version
of GHC and does this sort of thing transparently, not much what you
wanted.

I also haven't seen this being done in real game server (or server in
general) implementations. Not only would it be unnecessarily slow, but
it would also come with certain security problems.

Of course besides implementing behaviours remotely you can do it easily.
In many cases what would be objects in most languages would be
represented by other abstractions in Haskell. For example to represent
a client I always use a lightweight thread and StateT. To represent
game world objects I would use a thread, which manages a Map of those,
very similar to the one I posted. For some performance boost you can
use IntMap instead of Map.
Post by Benjamin L. Russell
Post by Ertugrul Söylemez
Post by Benjamin L. Russell
(My intuition is that since a purely functional programming
language would try to preserve referential transparency, it would
discourage side-effects, which would be necessitated by most I/O
(unless a special mechanism to preserve functional purity were
provided, such as monads or uniqueness typing), whereas in a purely
object-oriented programming language, even atomic operations would
be performed as messages passed between objects, and that
therefore, for this type of application, a purely object-oriented
programming language would be better suited than a purely
functional programming language, but I could be wrong. If you
think that my intuition is mistaken, please explain your
reasoning.)
There is really nothing wrong with message passing and purity. One
very useful concept is functional reactive programming (FRP).
That's what you would typically use for a game server in Haskell.
In FRP you describe the relative dependencies between objects with
respect to time.
Thank you for the reference to FRP. I shall look up FRP and see
whether I can use it to to overcome various challenges in
client-server communication concerning objects.
I found FRP difficult to get started with, because there are only few
concrete implementations, which are all useless for serious apps. First
of all they use GLUT, which is already death sentence. But it seems
like doing it yourself isn't that hard. You can use Frag [1] code as an
example of this.

[1] http://haskell.org/haskellwiki/Frag


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Adrian Hey
2009-06-12 13:16:52 UTC
Permalink
Hello Benjamin,

Despite my recent gripes about Haskell I must say I do have a hard time
following this Japanese guys logic. Perhaps something's got lost in
translation?

Would Timber be of interest: http://www.timber-lang.org/

It's basically a Haskell derivative that has gone back to strict
semantics (sensibly IMO), but also a concurrent OO language based on
"reactive objects". It's also probably better suited to real time
applications as time semantics are part of the language and I believe
the plan is use "earliest deadline first" scheduling policy (which is
another good thing).

I think it's very early days for timber and there doesn't seem to be
proper document that even defines the language, so maybe it's not a
realistic option yet.

The other (bad) thing I would say is that AFAICS timbers design has also
been influenced by the all conquering "global variables are evil" meme
:-(

If I'm right about that side of Timber that seems like a shame, but as
it's still not documented properly I may well be wrong (might have
missed something).

Regards
--
Adrian Hey
Vend
2009-06-16 12:49:02 UTC
Permalink
Post by Benjamin L. Russell
Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?
I agree.

While it's possible to do interactive I/O in purely functional
languages, it's not convenient.

Essentially it's a form of abstraction inversion: purely functional
languages abstract away the stateful nature of the underlaying system,
to produce a stateless functional system. IO monands or IO unique
objects reintroduce state on the top of the stateless functional
system.
They are a dirty hack, it's ok as long as you use them rarely, but if
you use them intensively then you are programmin in an ugly imperative
language implemented on top of a functional language.

Moreover, I'm not sure but I think that I/O sequencing using monads or
unique objects interacts poorly with concurrency, since you specify a
total ordering of I/O operations, while in many multi-user
applications only a partial ordering is required (I suppose it's
possible to implement partial ordering in purely functional languages,
but I don't know whether Haskell or Clean provide it).
Paul Rubin
2009-06-16 15:57:58 UTC
Permalink
Post by Vend
Moreover, I'm not sure but I think that I/O sequencing using monads or
unique objects interacts poorly with concurrency, since you specify a
total ordering of I/O operations, while in many multi-user
applications only a partial ordering is required (I suppose it's
possible to implement partial ordering in purely functional languages,
but I don't know whether Haskell or Clean provide it).
GHC has lightweight threads that are quite efficient, and parallelism
combinators that are simple to use.
Ertugrul Söylemez
2009-06-16 16:39:24 UTC
Permalink
Post by Vend
Post by Benjamin L. Russell
Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?
I agree.
While it's possible to do interactive I/O in purely functional
languages, it's not convenient.
Essentially it's a form of abstraction inversion: purely functional
languages abstract away the stateful nature of the underlaying system,
to produce a stateless functional system. IO monands or IO unique
objects reintroduce state on the top of the stateless functional
system.
They are a dirty hack, it's ok as long as you use them rarely, but if
you use them intensively then you are programmin in an ugly imperative
language implemented on top of a functional language.
Or you just didn't understand the abstraction correctly, also you didn't
even bother to learn it properly before making such unfounded claims.
They are no dirty hack. They are a clean and very well-throught idea,
which is not only applicable to I/O. The state monads, which IO is
based on, is so convenient once you get used to it, that I have
implemented it in almost all languages (the ones, that support
parametric polymorphism) I'm using.

There are also many other monads like lists for non-deterministic code,
Maybe for a clean encoding of 'no result' (a special case of lists
actually), Cont for CPS-style code, possibly with escape continuations,
Parser (which is actually just a state monad) as a DSL for parsing
stuff, ST for pure destructive updates, etc.

Particularly interesting are monad transformers, which allow you to
combine monads arbitrarily. Stick together the list monad and a state
monad, then you've got non-deterministic state (code, which may have
multiple state/result threads). Stick together a CPS monad and IO, then
you've got IO with convenient continuations as well as call/cc.

Conclusion: Firstly monads are used a lot in Haskell and there is
nothing wrong with that, as they are very convenient both for elegance,
saving a lot of code and proving correctness. Also consider that most
languages support one or the other monad, just that they are named
differently, are far less convenient to use and you can't write your own
monads. Every code that uses exceptions actually executes in a CPS
monad. Haskell just makes them explicit.

Finally even Microsoft seems to disagree with you. They implemented
monads in F#, just that they don't give them the name 'monad'. As far
as I've seen, they didn't give them any name at all. Monadic
expressions are called 'computation expressions' or 'workflows' in F#.
Most people use those terms as aliases for monads.
Post by Vend
Moreover, I'm not sure but I think that I/O sequencing using monads or
unique objects interacts poorly with concurrency, since you specify a
total ordering of I/O operations, while in many multi-user
applications only a partial ordering is required (I suppose it's
possible to implement partial ordering in purely functional languages,
but I don't know whether Haskell or Clean provide it).
That's what threads are good for. There is no language, which does not
sequence I/O operations. Haskell uses lightweight threads, as Paul
pointed out. Clean certainly supports something similar. The original
idea comes from Erlang, I believe. Inter-thread communication is done
through some convenient abstractions like MVars, Chans and semaphores,
possibly combined with STM, if you need it.


Greets,
Ertugrul.
Vend
2009-06-16 17:16:25 UTC
Permalink
Post by Ertugrul Söylemez
Post by Vend
Post by Benjamin L. Russell
Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?
I agree.
While it's possible to do interactive I/O in purely functional
languages, it's not convenient.
Essentially it's a form of abstraction inversion: purely functional
languages abstract away the stateful nature of the underlaying system,
to produce a stateless functional system. IO monands or IO unique
objects reintroduce state on the top of the stateless functional
system.
They are a dirty hack, it's ok as long as you use them rarely, but if
you use them intensively then you are programmin in an ugly imperative
language implemented on top of a functional language.
Or you just didn't understand the abstraction correctly, also you didn't
even bother to learn it properly before making such unfounded claims.
They are no dirty hack.  They are a clean and very well-throught idea,
which is not only applicable to I/O.  The state monads, which IO is
based on, is so convenient once you get used to it, that I have
implemented it in almost all languages (the ones, that support
parametric polymorphism) I'm using.
Or you could just try to read for comprehension.
I didn't claim that monads are hacks. I claimed that I/O monads are
hacks.

<snip irrelevant stuff>
Post by Ertugrul Söylemez
Post by Vend
Moreover, I'm not sure but I think that I/O sequencing using monads or
unique objects interacts poorly with concurrency, since you specify a
total ordering of I/O operations, while in many multi-user
applications only a partial ordering is required (I suppose it's
possible to implement partial ordering in purely functional languages,
but I don't know whether Haskell or Clean provide it).
That's what threads are good for.  There is no language, which does not
sequence I/O operations.  Haskell uses lightweight threads, as Paul
pointed out.  Clean certainly supports something similar.  The original
idea comes from Erlang, I believe.  Inter-thread communication is done
through some convenient abstractions like MVars, Chans and semaphores,
possibly combined with STM, if you need it.
Ok.
Ertugrul Söylemez
2009-06-16 18:26:13 UTC
Permalink
Post by Vend
Post by Ertugrul Söylemez
Or you just didn't understand the abstraction correctly, also you
didn't even bother to learn it properly before making such unfounded
claims. They are no dirty hack.  They are a clean and very
well-throught idea, which is not only applicable to I/O.  The state
monads, which IO is based on, is so convenient once you get used to
it, that I have implemented it in almost all languages (the ones,
that support parametric polymorphism) I'm using.
Or you could just try to read for comprehension.
I didn't claim that monads are hacks. I claimed that I/O monads are
hacks.
Same thing: Still wrong.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Adrian Hey
2009-06-16 21:47:36 UTC
Permalink
Post by Ertugrul Söylemez
Post by Vend
I didn't claim that monads are hacks. I claimed that I/O monads are
hacks.
Same thing: Still wrong.
Adrian Hey
2009-06-16 22:12:28 UTC
Permalink
Post by Ertugrul Söylemez
Post by Vend
I didn't claim that monads are hacks. I claimed that I/O monads are
hacks.
Same thing: Still wrong.
Whoops, hit send before I'd written anything...

Describing IO monad as dirty hack is probably a bit OTT. As
formalisation of good old fashioned procedural programming it
works OK, more or less. But therein lies the problem too, which is what
Vend is getting at. Why should IO be done this way?

Using a monad does over determine execution order. This is the objection
of the Clean designers. I don't personally agree with their solution
of "deterministic concurrency", but the objection is a valid one IMO.

The idea of "threads" sequencing potentially blocking IO operations and
the use of forkIO as workaround for the inherent "sequentiality" of all
this seems pretty ugly to me too. The ideas behind O'Haskell and now
Timber are much more appealing.

Regards
--
Adrian Hey
Paul Rubin
2009-06-17 01:02:49 UTC
Permalink
Post by Adrian Hey
Using a monad does over determine execution order. This is the objection
of the Clean designers.
Oleg also says something like that:
http://lambda-the-ultimate.org/node/2749#comment-41078
Ertugrul Söylemez
2009-06-18 08:08:52 UTC
Permalink
Post by Adrian Hey
Describing IO monad as dirty hack is probably a bit OTT. As
formalisation of good old fashioned procedural programming it
works OK, more or less. But therein lies the problem too, which is what
Vend is getting at. Why should IO be done this way?
Using a monad does over determine execution order. This is the objection
of the Clean designers. I don't personally agree with their solution
of "deterministic concurrency", but the objection is a valid one IMO.
There is some truth about 'overdetermining' execution order. However, I
don't think this is a problem related to monads in general, but to the
IO monad. State monads, for example, are as pure (and therefore as
non-strict) as non-monadic code.

However, I haven't seen a case, where this overdetermination makes a
problem or an inconvenience.
Post by Adrian Hey
The idea of "threads" sequencing potentially blocking IO operations
and the use of forkIO as workaround for the inherent "sequentiality"
of all this seems pretty ugly to me too. The ideas behind O'Haskell
and now Timber are much more appealing.
The idea of forkIO-concurrency is flawed in many ways, and the ideas of
Timber are really appealing. You can do this in Haskell, too, using FRP
libraries, but that's probably something you wouldn't want to do.
However, Haskell's idea of IO and concurrency is currently much better
than any of the mainstream languages. Instead of making new languages
that nobody uses, improving Haskell appears to be more promising to me.

I was referring to this problem in another thread: Haskell development
progresses too slowly. I see this as the main problem with Haskell.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Paul Rubin
2009-06-18 10:51:13 UTC
Permalink
Post by Ertugrul Söylemez
There is some truth about 'overdetermining' execution order. However, I
don't think this is a problem related to monads in general, but to the
IO monad. State monads, for example, are as pure (and therefore as
non-strict) as non-monadic code.
I thought that the whole invention of arrows had something to do with
certain monadic parsing schemes being inefficient because of that
overdetermination.
Ertugrul Söylemez
2009-06-18 14:17:05 UTC
Permalink
Post by Paul Rubin
Post by Ertugrul Söylemez
There is some truth about 'overdetermining' execution order. However, I
don't think this is a problem related to monads in general, but to the
IO monad. State monads, for example, are as pure (and therefore as
non-strict) as non-monadic code.
I thought that the whole invention of arrows had something to do with
certain monadic parsing schemes being inefficient because of that
overdetermination.
The problem with the usual monadic approach in parsing is late failing.
Consider a parser for numeric words 'one', 'two' and 'three'. A
monadic parser would try to parse 'one', fail, then 'two', fail, then
'three'. An arrow parser can fail already by finding that the first
character is neither 'o', nor 't'. It could sort out 'one' by finding
that the first character is a 't'. That saves a lot of backtracking.

You can build such a more intelligent parser with monads, too, but it
requires more work. Arrows make it much easier.


Greets,
Ertugrul.
Paul Rubin
2009-06-17 01:02:49 UTC
Permalink
Post by Adrian Hey
Using a monad does over determine execution order. This is the objection
of the Clean designers.
Oleg also says something like that:
http://lambda-the-ultimate.org/node/2749#comment-41078
Vend
2009-06-17 09:15:32 UTC
Permalink
Post by Vend
Post by Ertugrul Söylemez
Or you just didn't understand the abstraction correctly, also you
didn't even bother to learn it properly before making such unfounded
claims.  They are no dirty hack.  They are a clean and very
well-throught idea, which is not only applicable to I/O.  The state
monads, which IO is based on, is so convenient once you get used to
it, that I have implemented it in almost all languages (the ones,
that support parametric polymorphism) I'm using.
Or you could just try to read for comprehension.
I didn't claim that monads are hacks. I claimed that I/O monads are
hacks.
Same thing:  Still wrong.
Unsupported assertion.
Jon Harrop
2009-06-17 21:12:46 UTC
Permalink
Post by Vend
Post by Vend
Post by Ertugrul Söylemez
Or you just didn't understand the abstraction correctly, also you
didn't even bother to learn it properly before making such unfounded
claims.  They are no dirty hack.  They are a clean and very
well-throught idea, which is not only applicable to I/O.  The state
monads, which IO is based on, is so convenient once you get used to
it, that I have implemented it in almost all languages (the ones,
that support parametric polymorphism) I'm using.
Or you could just try to read for comprehension.
I didn't claim that monads are hacks. I claimed that I/O monads are
hacks.
Same thing:  Still wrong.
Unsupported assertion.
I don't know if you've noticed but Ertugrul is still posting noob questions.
You might want to take his authoritative-sounding stances with regard to
non-trivial subjects with a pinch of salt...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Ertugrul Söylemez
2009-06-18 08:26:30 UTC
Permalink
Post by Jon Harrop
I don't know if you've noticed but Ertugrul is still posting noob
questions. You might want to take his authoritative-sounding stances
with regard to non-trivial subjects with a pinch of salt...
I'm posting noob F# questions, because I _am_ a noob in F#. What's your
point? Doesn't seem like you know the answers to my questions either,
even though you praise F# to the skies, so what?

You only meddle when there is some Haskell (or other language you don't
like) to slur, in fact almost any language besides OCaml and F#.


Greets,
Ertugrul.
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/
Jon Harrop
2009-06-18 14:58:52 UTC
Permalink
Post by Ertugrul Söylemez
Post by Jon Harrop
I don't know if you've noticed but Ertugrul is still posting noob
questions. You might want to take his authoritative-sounding stances
with regard to non-trivial subjects with a pinch of salt...
I'm posting noob F# questions, because I _am_ a noob in F#. What's your
point?
You make little attempt to justify your beliefs but, instead, state them as
if we are supposed to accept them based solely upon your body of experience
with regard to functional programming. Meanwhile, in other threads you ask
basic questions about functional programming (not specific to F#) that make
it clear that you have no such experience. So, if you cannot provide a
logical justification, there is no point in discussing your beliefs because
they will almost certainly change once you've mastered the basics.
Post by Ertugrul Söylemez
Doesn't seem like you know the answers to my questions either,
even though you praise F# to the skies, so what?
You only meddle when there is some Haskell (or other language you don't
like) to slur, in fact almost any language besides OCaml and F#.
There is something inherently funny about childish insults when they are
written in pidgin English. Perhaps you should avoid them.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Ertugrul Söylemez
2009-06-18 14:30:38 UTC
Permalink
Post by Jon Harrop
Post by Ertugrul Söylemez
Post by Jon Harrop
I don't know if you've noticed but Ertugrul is still posting noob
questions. You might want to take his authoritative-sounding stances
with regard to non-trivial subjects with a pinch of salt...
I'm posting noob F# questions, because I _am_ a noob in F#. What's your
point?
You make little attempt to justify your beliefs but, instead, state them as
if we are supposed to accept them based solely upon your body of experience
with regard to functional programming. Meanwhile, in other threads you ask
basic questions about functional programming (not specific to F#) that make
it clear that you have no such experience. So, if you cannot provide a
logical justification, there is no point in discussing your beliefs because
they will almost certainly change once you've mastered the basics.
Ok, master Dr. Harrop. I'll do my best.

But as a side note: Just like you make mistakes in Haskell because
you're used to strict semantics, I make mistakes in other languages,
because I'm used to non-strict semantics. There is an interesting
symmetry here: you think that Haskell sucks and I think that other
languages suck, although I admit that F# is not as bad as I thought.
However, I would still prefer Haskell over F#.
Post by Jon Harrop
Post by Ertugrul Söylemez
Doesn't seem like you know the answers to my questions either,
even though you praise F# to the skies, so what?
You only meddle when there is some Haskell (or other language you don't
like) to slur, in fact almost any language besides OCaml and F#.
There is something inherently funny about childish insults when they are
written in pidgin English. Perhaps you should avoid them.
No insults there.


Greets,
Ertugrul.
Ertugrul Söylemez
2009-06-18 14:30:38 UTC
Permalink
Post by Jon Harrop
Post by Ertugrul Söylemez
Post by Jon Harrop
I don't know if you've noticed but Ertugrul is still posting noob
questions. You might want to take his authoritative-sounding stances
with regard to non-trivial subjects with a pinch of salt...
I'm posting noob F# questions, because I _am_ a noob in F#. What's your
point?
You make little attempt to justify your beliefs but, instead, state them as
if we are supposed to accept them based solely upon your body of experience
with regard to functional programming. Meanwhile, in other threads you ask
basic questions about functional programming (not specific to F#) that make
it clear that you have no such experience. So, if you cannot provide a
logical justification, there is no point in discussing your beliefs because
they will almost certainly change once you've mastered the basics.
Ok, master Dr. Harrop. I'll do my best.

But as a side note: Just like you make mistakes in Haskell because
you're used to strict semantics, I make mistakes in other languages,
because I'm used to non-strict semantics. There is an interesting
symmetry here: you think that Haskell sucks and I think that other
languages suck, although I admit that F# is not as bad as I thought.
However, I would still prefer Haskell over F#.
Post by Jon Harrop
Post by Ertugrul Söylemez
Doesn't seem like you know the answers to my questions either,
even though you praise F# to the skies, so what?
You only meddle when there is some Haskell (or other language you don't
like) to slur, in fact almost any language besides OCaml and F#.
There is something inherently funny about childish insults when they are
written in pidgin English. Perhaps you should avoid them.
No insults there.


Greets,
Ertugrul.

Vend
2009-06-16 17:16:25 UTC
Permalink
Post by Ertugrul Söylemez
Post by Vend
Post by Benjamin L. Russell
Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?
I agree.
While it's possible to do interactive I/O in purely functional
languages, it's not convenient.
Essentially it's a form of abstraction inversion: purely functional
languages abstract away the stateful nature of the underlaying system,
to produce a stateless functional system. IO monands or IO unique
objects reintroduce state on the top of the stateless functional
system.
They are a dirty hack, it's ok as long as you use them rarely, but if
you use them intensively then you are programmin in an ugly imperative
language implemented on top of a functional language.
Or you just didn't understand the abstraction correctly, also you didn't
even bother to learn it properly before making such unfounded claims.
They are no dirty hack.  They are a clean and very well-throught idea,
which is not only applicable to I/O.  The state monads, which IO is
based on, is so convenient once you get used to it, that I have
implemented it in almost all languages (the ones, that support
parametric polymorphism) I'm using.
Or you could just try to read for comprehension.
I didn't claim that monads are hacks. I claimed that I/O monads are
hacks.

<snip irrelevant stuff>
Post by Ertugrul Söylemez
Post by Vend
Moreover, I'm not sure but I think that I/O sequencing using monads or
unique objects interacts poorly with concurrency, since you specify a
total ordering of I/O operations, while in many multi-user
applications only a partial ordering is required (I suppose it's
possible to implement partial ordering in purely functional languages,
but I don't know whether Haskell or Clean provide it).
That's what threads are good for.  There is no language, which does not
sequence I/O operations.  Haskell uses lightweight threads, as Paul
pointed out.  Clean certainly supports something similar.  The original
idea comes from Erlang, I believe.  Inter-thread communication is done
through some convenient abstractions like MVars, Chans and semaphores,
possibly combined with STM, if you need it.
Ok.
Loading...