Discussion:
Erlang for desktop applications?
(too old to reply)
unknown
2006-08-06 14:39:46 UTC
Permalink
Hi everybody:
I am new to functional programming (just some very little experience
with Lisp). I got interested in functional programming because of the
performance related to multiproccessors or multicore systems. And I got
interested in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to Haskell or
others.
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications? I know it wasn't designed for this, and
that there are very important actions like string functions which are
slow in Erlang... but then I also ran into EX11 and similar projects
which seem like a little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not, could you
recommend other functional languages that fit best that objective?
I'm looking forward to efficiency on future multicore processors and
easy concurrency management.

Thanks all.
unknown
2006-08-06 21:06:53 UTC
Permalink
Have a look a F# - OCaml on .NET.

Also check out wings3d - a "desktop appliation" written in Erlang.

The real problems behind writing a desktop app I think have to do with
UI and GUI issues. For example, TK is an ugly UI on any system - and
its the widly available default UI.

What I really want is Cocoa bindings. Maybe I should write that.

-ryan


On 8/6/06, Jacobo Garc?a de Polavieja Aguilera
Post by unknown
I am new to functional programming (just some very little experience
with Lisp). I got interested in functional programming because of the
performance related to multiproccessors or multicore systems. And I got
interested in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to Haskell or
others.
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications? I know it wasn't designed for this, and
that there are very important actions like string functions which are
slow in Erlang... but then I also ran into EX11 and similar projects
which seem like a little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not, could you
recommend other functional languages that fit best that objective?
I'm looking forward to efficiency on future multicore processors and
easy concurrency management.
Thanks all.
unknown
2006-08-06 23:19:55 UTC
Permalink
Cocoa bindings would only be good for mac. I think there needs to be
GTK bindings or a new GUI built around erlang. I beleave erlang could
be used now for desktops apps, only if there GUI where there. But a few
fixes to how it handles strings and floating point numbers would make
for an even better enverment to work in.
Post by unknown
Have a look a F# - OCaml on .NET.
Also check out wings3d - a "desktop appliation" written in Erlang.
The real problems behind writing a desktop app I think have to do with
UI and GUI issues. For example, TK is an ugly UI on any system - and
its the widly available default UI.
What I really want is Cocoa bindings. Maybe I should write that.
-ryan
On 8/6/06, Jacobo Garc?a de Polavieja Aguilera
Post by unknown
I am new to functional programming (just some very little experience
with Lisp). I got interested in functional programming because of the
performance related to multiproccessors or multicore systems. And I got
interested in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to Haskell or
others.
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications? I know it wasn't designed for this, and
that there are very important actions like string functions which are
slow in Erlang... but then I also ran into EX11 and similar projects
which seem like a little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not, could you
recommend other functional languages that fit best that objective?
I'm looking forward to efficiency on future multicore processors and
easy concurrency management.
Thanks all.
unknown
2006-08-07 03:16:18 UTC
Permalink
Ironically GTK doesn't really address the realistic needs of a desktop
application. Printing? Maybe things are better than the last time I
looked at it, but I don't care as much about Linux on the desktop.

I heard that wxWindows is not so great for large apps. I don't know
why, but I suspect it may have to do with the class structure or
something.

As for OSX, sounds good to me :-)
Post by unknown
Cocoa bindings would only be good for mac. I think there needs to be
GTK bindings or a new GUI built around erlang. I beleave erlang could
be used now for desktops apps, only if there GUI where there. But a few
fixes to how it handles strings and floating point numbers would make
for an even better enverment to work in.
Post by unknown
Have a look a F# - OCaml on .NET.
Also check out wings3d - a "desktop appliation" written in Erlang.
The real problems behind writing a desktop app I think have to do with
UI and GUI issues. For example, TK is an ugly UI on any system - and
its the widly available default UI.
What I really want is Cocoa bindings. Maybe I should write that.
-ryan
On 8/6/06, Jacobo Garc?a de Polavieja Aguilera
Post by unknown
I am new to functional programming (just some very little experience
with Lisp). I got interested in functional programming because of the
performance related to multiproccessors or multicore systems. And I got
interested in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to Haskell or
others.
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications? I know it wasn't designed for this, and
that there are very important actions like string functions which are
slow in Erlang... but then I also ran into EX11 and similar projects
which seem like a little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not, could you
recommend other functional languages that fit best that objective?
I'm looking forward to efficiency on future multicore processors and
easy concurrency management.
Thanks all.
unknown
2006-08-07 10:26:34 UTC
Permalink
Depends on what you mean by "desktop services" :) Printing? Qt has it.
Graphics? Also there (fast 2-D, SVG and OpenGL).

Moreover, the Qt for Java is a proof-of-concept by Trolltech to show
that bindings to Qt can by successfully created for other languages,
not only for C++ (there is also a pyQt binding for Python).

What I'm saying is - Qt is as good a framework to build upon as any.
Not interested in java things. I won't even consider it - waste of
time/resources imho.
I'm familiar with QT, but still it doesnt really address my bottom
line... its just a UI toolkit, it doesnt provide desktop services,
does it?
-ryan
What about Qt? They recently released a proof-of-concept Java binding
(http://www.trolltech.com/developer/downloads/qt/qtjambi-techpreview).
And their signal/slot concept could fit into Erlang's messaging model.
It is cross-platform, too.
Post by unknown
Ironically GTK doesn't really address the realistic needs of a desktop
application. Printing? Maybe things are better than the last time I
looked at it, but I don't care as much about Linux on the desktop.
I heard that wxWindows is not so great for large apps. I don't know
why, but I suspect it may have to do with the class structure or
something.
As for OSX, sounds good to me :-)
unknown
2006-08-07 11:06:43 UTC
Permalink
Post by unknown
Ironically GTK doesn't really address the realistic needs of a desktop
application. Printing? Maybe things are better than the last time I
looked at it, but I don't care as much about Linux on the desktop.
I heard that wxWindows is not so great for large apps. I don't know
why, but I suspect it may have to do with the class structure or
something.
As for OSX, sounds good to me :-)
Post by unknown
Cocoa bindings would only be good for mac. I think there needs to be
GTK bindings or a new GUI built around erlang. I beleave erlang could
be used now for desktops apps, only if there GUI where there. But a few
fixes to how it handles strings and floating point numbers would make
for an even better enverment to work in.
Post by unknown
Have a look a F# - OCaml on .NET.
Also check out wings3d - a "desktop appliation" written in Erlang.
The real problems behind writing a desktop app I think have to do with
UI and GUI issues. For example, TK is an ugly UI on any system - and
its the widly available default UI.
What I really want is Cocoa bindings. Maybe I should write that.
-ryan
On 8/6/06, Jacobo Garc?a de Polavieja Aguilera
Post by unknown
I am new to functional programming (just some very little experience
with Lisp). I got interested in functional programming because of the
performance related to multiproccessors or multicore systems. And I
got
Post by unknown
Post by unknown
interested in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to Haskell or
others.
But, do you see Erlang suitable for developing future (more than 5
years
Post by unknown
Post by unknown
from now) desktop applications? I know it wasn't designed for this,
and
Post by unknown
Post by unknown
that there are very important actions like string functions which are
slow in Erlang... but then I also ran into EX11 and similar projects
which seem like a little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not, could
you
Post by unknown
Post by unknown
recommend other functional languages that fit best that objective?
I'm looking forward to efficiency on future multicore processors and
easy concurrency management.
Thanks all.
Please don't turn this into a Cocoa VS GTK or OSX VS Linux debate ;-).
WxWindows is not suitable for large application because it's a subset of
all de backends it supports (GTK, WindowsForms, etc), so it gets
complicated to do a big and nice GUI. It's usually pretty limited.

What I'm trying to address here is... if there was a nice GUI
(whichever) for Erlang... would Erlang be a nice option to develop
desktop applications seeing dual and quadcore processors are coming?
Even more... would it be suitable to develop its own GUI?

Thanks for all the answers.
unknown
2006-08-07 12:14:36 UTC
Permalink
Yeah, if you want to roll your own wrapper to just about any GUI API,
erlang is very straightforward and there are existing libs to give
you guidance. Erlang's generic and OTP management (Supervisor/
worker) of processes are both very suitable to mapping directly to
typical GUI object and event-driven idioms. As far as scalability
goes, the erlang vm scales well and latest publishing's of multi-proc
erlang tests look very promising.
Good luck, ke han
Post by unknown
Please don't turn this into a Cocoa VS GTK or OSX VS Linux debate ;-).
WxWindows is not suitable for large application because it's a
subset of all de backends it supports (GTK, WindowsForms, etc), so
it gets complicated to do a big and nice GUI. It's usually pretty
limited.
What I'm trying to address here is... if there was a nice GUI
(whichever) for Erlang... would Erlang be a nice option to develop
desktop applications seeing dual and quadcore processors are coming?
Even more... would it be suitable to develop its own GUI?
Thanks for all the answers.
unknown
2006-08-07 14:02:38 UTC
Permalink
Post by unknown
Please don't turn this into a Cocoa VS GTK or OSX VS Linux debate ;-).
WxWindows is not suitable for large application because it's a subset
of all de backends it supports (GTK, WindowsForms, etc), so it gets
complicated to do a big and nice GUI. It's usually pretty limited.
What I'm trying to address here is... if there was a nice GUI
(whichever) for Erlang... would Erlang be a nice option to develop
desktop applications seeing dual and quadcore processors are coming?
This boils down to two options
a) creating a GUI well fitting to Erlang (which is distributed, message
passing and functional)
b) interfacing an existing GUI to Erlang

I would like see a) of course. But except that every standard GUI is
event driven, which could be mapped to
Erlang processes, I have yet to see a nice functional approach to
creating a GUI.
Haskell with its monads, which is kind of a imperative DSL within Haskell
seems to be a bit further ahead conceptually. But even those folks stick
to a GTK binding
when doing GUIs, if I see it correctly.

Developing something like GTK or any other portable GUI toolkit, is a
major pain
in the behind, and the folks who want to do Erlang usually don't want to
take off
a few years to develop and maintain such a huge subsystem.

But if you like, go for it. :-)

Regards,
Marc
unknown
2006-08-06 22:24:35 UTC
Permalink
Post by unknown
Have a look a F# - OCaml on .NET.
Also check out wings3d - a "desktop appliation" written in Erlang.
The real problems behind writing a desktop app I think have to do with
UI and GUI issues. For example, TK is an ugly UI on any system - and
its the widly available default UI.
What I really want is Cocoa bindings. Maybe I should write that.
-ryan
On 8/6/06, Jacobo Garc?a de Polavieja Aguilera
Post by unknown
I am new to functional programming (just some very little experience
with Lisp). I got interested in functional programming because of the
performance related to multiproccessors or multicore systems. And I got
interested in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to Haskell or
others.
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications? I know it wasn't designed for this, and
that there are very important actions like string functions which are
slow in Erlang... but then I also ran into EX11 and similar projects
which seem like a little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not, could you
recommend other functional languages that fit best that objective?
I'm looking forward to efficiency on future multicore processors and
easy concurrency management.
Thanks all.
Actually, I'd love to see a port of wxWindows for Erlang ... it's slots
& signals methodology should work well with Erlangs comms style.

jd
unknown
2006-08-07 03:43:17 UTC
Permalink
Jacobo =?ISO-8859-1?Q?Garc=EDa?= de Polavieja Aguilera
<jacobopolavieja> asked:

But, do you see Erlang suitable for developing future (more than
5 years from now) desktop applications? I know it wasn't
designed for this, and that there are very important actions
like string functions which are slow in Erlang...

ARE they? Have you measured them?

We had a lengthy thread not so long ago where I pointed out that
there is more than one way to represent a string, and that for
many applications the traditional packed-array-of-bytes is a rather bad
representation. (For example, for Information Retrieval a list of
word numbers may be better.) And it is much easier to experiment with
unusual text representations in a language like Erlang than in a language
like C++ or Java.

A colleague and I are teaching a 4th year "advanced object oriented
programming" paper. He and I agree about lots of things, some of which
other people in the department don't agree about. One of them is that
in 10 years time if you can't write reliable highly concurrent code you
will probably be out of business. (Assume Moore's Law keeps going, but
with respect to total performance of multicore systems rather than
per-core performance, and in 10 years time we'll see kilocore machines
on the desk top. They will probably be running some sort of virtual
reality sex game.) So last week he spent a lecture on Occam (which to
my pleased surprise is still around even though Transputers are dead;
KROC is even freely downloadable and installed without any problems).
This week I'm going to spend a lecture on Erlang.

Let's assume an 18-month doubling time, and let's take 4 cores as the
starting point. (I have a copy of "Dual-Core Update to the Intel(R)
Itanium(R) 2 Processor Reference Manual, and Sun's Niagara is 8-core,
so I'm taking 4 cores as a sort of midpoint.) In five years, we'll
expect there to be desktop machines with 32 cores.

(Ooh, I just noticed this from InfoWorld back in 2004: NEC developed
a cellphone chip, the MP211, with three ARM cores plus a DSP, so that's
a four-core chip in your hand. Hmm. There's an "image processor" on
the chip as well, according to the NEC web site. What I can't find is
a price for these things.)

but then I also ran into EX11 and similar projects which seem
like a little light for my future purpose. Could be erlang efficient
with desktop related stuff?

It all depends on what you do on your desktop. Did you see the
article someone mentioned recently about decoding some sort of video
format in Erlang? If you are doing something like music or video
editing on your desktop, perhaps what really matters for performance
is the DSP or GP, not the "steering" code. If you are doing information
retrieval or data mining, heck, people even do that in Java (although
I do *wish* that the NCSA ALG group would spend some time producing
usable documentation for their program; I would cheerfully accept something
10 times as slow with a manual just 2 times as big if it had the right
stuff in the manual), because if you have good data structures it's
probably I/O bandwidth that matters rather than CPU speed. (We have
a student looking at information retrieval on a multicore machine, and
it's not clear that there's going to be a result other than "I/O
concurrency is the right kind".)

If not, could you recommend other
functional languages that fit best that objective? I'm looking
forward to efficiency on future multicore processors and easy
concurrency management.

There's always ML. As a happy Haskeller, I do find the syntax of SML
clunky, and O'CAML even worse. Sadly, O'CAML is one of the fastest
systems around. Although Mlton (no typing mistake, it really is m l
t o n) is a darned good batch compiler for SML. And although concurrency
isn't officially standard in ML, both SML/NJ and Mlton support the CML
extensions. The SML Basis Library includes particularly good support for
substrings, if string hacking is important in what you do.

There are also concurrent versions of Haskell, and Haskell these days is
doing some *awesome* things with generic programming (think "type safe
programming ON the language IN the language" and "automatic derivation of
large chunks of code"). Clean generates pretty darned good code, and a
somewhat different version of generic programming, but they've dropped
concurrency support, for now at least.

Then there's Mercury, which gives you logic programming and (strict)
functional programming and constraint programming all in one strictly
typed and heavily checked box. (The compiler will even try to figure out
whether procedures must always terminate, although the Halting Problem
result means that it can't always be sure.) People are using that for
desktop stuff.

Given Erlang's support for interfaces (CORBA, ASN.1, C, Java, you name
it) it's difficult to think of any likely desktop application where
Erlang couldn't have _some_ practical use.
unknown
2006-08-08 10:34:51 UTC
Permalink
Post by unknown
Jacobo =?ISO-8859-1?Q?Garc=EDa?= de Polavieja Aguilera
But, do you see Erlang suitable for developing future (more than
5 years from now) desktop applications? I know it wasn't
designed for this, and that there are very important actions
like string functions which are slow in Erlang...
ARE they? Have you measured them?
We had a lengthy thread not so long ago where I pointed out that
there is more than one way to represent a string, and that for
many applications the traditional packed-array-of-bytes is a rather bad
representation. (For example, for Information Retrieval a list of
word numbers may be better.) And it is much easier to experiment with
unusual text representations in a language like Erlang than in a language
like C++ or Java.
A colleague and I are teaching a 4th year "advanced object oriented
programming" paper. He and I agree about lots of things, some of which
other people in the department don't agree about. One of them is that
in 10 years time if you can't write reliable highly concurrent code you
will probably be out of business. (Assume Moore's Law keeps going, but
with respect to total performance of multicore systems rather than
per-core performance, and in 10 years time we'll see kilocore machines
on the desk top. They will probably be running some sort of virtual
reality sex game.) So last week he spent a lecture on Occam (which to
my pleased surprise is still around even though Transputers are dead;
KROC is even freely downloadable and installed without any problems).
This week I'm going to spend a lecture on Erlang.
Let's assume an 18-month doubling time, and let's take 4 cores as the
starting point. (I have a copy of "Dual-Core Update to the Intel(R)
Itanium(R) 2 Processor Reference Manual, and Sun's Niagara is 8-core,
so I'm taking 4 cores as a sort of midpoint.) In five years, we'll
expect there to be desktop machines with 32 cores.
(Ooh, I just noticed this from InfoWorld back in 2004: NEC developed
a cellphone chip, the MP211, with three ARM cores plus a DSP, so that's
a four-core chip in your hand. Hmm. There's an "image processor" on
the chip as well, according to the NEC web site. What I can't find is
a price for these things.)
but then I also ran into EX11 and similar projects which seem
like a little light for my future purpose. Could be erlang efficient
with desktop related stuff?
It all depends on what you do on your desktop. Did you see the
article someone mentioned recently about decoding some sort of video
format in Erlang? If you are doing something like music or video
editing on your desktop, perhaps what really matters for performance
is the DSP or GP, not the "steering" code. If you are doing information
retrieval or data mining, heck, people even do that in Java (although
I do *wish* that the NCSA ALG group would spend some time producing
usable documentation for their program; I would cheerfully accept something
10 times as slow with a manual just 2 times as big if it had the right
stuff in the manual), because if you have good data structures it's
probably I/O bandwidth that matters rather than CPU speed. (We have
a student looking at information retrieval on a multicore machine, and
it's not clear that there's going to be a result other than "I/O
concurrency is the right kind".)
If not, could you recommend other
functional languages that fit best that objective? I'm looking
forward to efficiency on future multicore processors and easy
concurrency management.
There's always ML. As a happy Haskeller, I do find the syntax of SML
clunky, and O'CAML even worse. Sadly, O'CAML is one of the fastest
systems around. Although Mlton (no typing mistake, it really is m l
t o n) is a darned good batch compiler for SML. And although concurrency
isn't officially standard in ML, both SML/NJ and Mlton support the CML
extensions. The SML Basis Library includes particularly good support for
substrings, if string hacking is important in what you do.
There are also concurrent versions of Haskell, and Haskell these days is
doing some *awesome* things with generic programming (think "type safe
programming ON the language IN the language" and "automatic derivation of
large chunks of code"). Clean generates pretty darned good code, and a
somewhat different version of generic programming, but they've dropped
concurrency support, for now at least.
Then there's Mercury, which gives you logic programming and (strict)
functional programming and constraint programming all in one strictly
typed and heavily checked box. (The compiler will even try to figure out
whether procedures must always terminate, although the Halting Problem
result means that it can't always be sure.) People are using that for
desktop stuff.
Given Erlang's support for interfaces (CORBA, ASN.1, C, Java, you name
it) it's difficult to think of any likely desktop application where
Erlang couldn't have _some_ practical use.
Your message was very clarifying, thanks.

ARE they? Have you measured them?

We had a lengthy thread not so long ago where I pointed out that
there is more than one way to represent a string, and that for
many applications the traditional packed-array-of-bytes is a rather
bad representation. (For example, for Information Retrieval a list
of word numbers may be better.) And it is much easier to experiment
with unusual text representations in a language like Erlang than in a
language like C++ or Java.

I just put the slow "fact" based on what is said on the FAQ:
http://www.erlang.org/faq/x1088.html#AEN1288
As I said I don't have any programming experience with Erlang so I'm
trying to see if it could fit my interest in developing desktop apps.
I'll look for that thread you've mentioned :).


One of them is that in 10 years time if you can't write reliable
highly concurrent code you will probably be out of business.

That's my main point of view and what drove me to consider a better
language for programming concurrency. I truly believe is going to be
like that in the future. So, do you see Erlang is the/one of the most
best positioned to take advantage of that future fact?


Given Erlang's support for interfaces (CORBA, ASN.1, C, Java, you
name it) it's difficult to think of any likely desktop application
where Erlang couldn't have _some_ practical use.

You said it, "some". But how about being the main or unique language in
desktop developing apps?
My main fear is that, as I have very little experience, I can't thing of
many "actions" taken in desktop apps that are very concurrent or just
concurrent. I mean... all I can think about that could benefit from
Erlang's concurrency is a mail application (to retrieve mail), P2P
application (interconnect users)... which are very "networky" (where
Erlang is strong).
I just don't now if a chat program, or a web browser, or a file manager,
or a document viewer, a game, a multimedia player and all the usual
desktop applications need lots of concurrency and can benefit from
Erlang or if it would be better to use some thing like C# with the
little concurrency it implements.

I think I'll have to learn Erlang and finish my PThreads studying, make
typical desktop programs with both... and then compare :-|.
Ocaml is a candidate too from what I've heard.

Thanks for all the patience with the newbie...

Cheers.
unknown
2006-08-07 09:09:23 UTC
Permalink
I think your question isn't so straightforward.
Lets ignore erlang's lack of certain UI library wrappers for a moment
to think about what a desktop apps' UI will look like in 5 years.
Post by unknown
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications?
A "desktop app" in 5 years will most likely fall into one of 2
categories:
1 - Traditional GUI app...highly integrated UI and domain logic for
graphics intensive apps (think Photoshop).
2 - 2-tier: View separated from domain logic. Think of just about
every next-gen web app being written today (this includes
replacements for fairly complex and expressive UIs such as Word and
Excel)

So, unless you are creating things like Photoshop (I bet we'll see a
web service replacement for 80% of its' features in the next 5 years)
or Wings3D, think of the "App UI", not the "Desktop UI". There are
many variations on a meme for creating App UIs (in browser, Flash,
"smart components which talk to servers (local and remote".)
If your app fits into this later category, I'd say erlang is a better
fit than many languages for the domain part of the app. The View
part will be HTML, Javascript, Haxe, Flash, VRML, who knows...this
new App UI infrastructure stuff "sits on top of / integrated into"
your Desktop GUI, so the App developer is not concerned at this level.

Adding erlang wrappers to various GUI libraries (GTK, Win32, Cocoa)
is a straightforward matter. "How do you really want to build a new
desktop app (regardless of language)?" is the hard part.

There has been some talk on the yaws list and some here regarding
dynamic Web UIs. This is the general direction app developers are
taking and there will exist / do exist methods to make these apps
"work like / install like" the desktop apps you are accustomed.

regards, ke han
Post by unknown
I am new to functional programming (just some very little experience
with Lisp). I got interested in functional programming because of the
performance related to multiproccessors or multicore systems. And I got
interested in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to Haskell or
others.
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications? I know it wasn't designed for this, and
that there are very important actions like string functions which are
slow in Erlang... but then I also ran into EX11 and similar projects
which seem like a little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not, could you
recommend other functional languages that fit best that objective?
I'm looking forward to efficiency on future multicore processors and
easy concurrency management.
Thanks all.
unknown
2006-08-08 15:48:09 UTC
Permalink
Post by unknown
I think your question isn't so straightforward.
Lets ignore erlang's lack of certain UI library wrappers for a moment to
think about what a desktop apps' UI will look like in 5 years.
Post by unknown
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications?
1 - Traditional GUI app...highly integrated UI and domain logic for
graphics intensive apps (think Photoshop).
2 - 2-tier: View separated from domain logic. Think of just about every
next-gen web app being written today (this includes replacements for
fairly complex and expressive UIs such as Word and Excel)
So, unless you are creating things like Photoshop (I bet we'll see a web
service replacement for 80% of its' features in the next 5 years) or
Wings3D, think of the "App UI", not the "Desktop UI". There are many
variations on a meme for creating App UIs (in browser, Flash, "smart
components which talk to servers (local and remote".)
If your app fits into this later category, I'd say erlang is a better
fit than many languages for the domain part of the app. The View part
will be HTML, Javascript, Haxe, Flash, VRML, who knows...this new App UI
infrastructure stuff "sits on top of / integrated into" your Desktop
GUI, so the App developer is not concerned at this level.
Adding erlang wrappers to various GUI libraries (GTK, Win32, Cocoa) is a
straightforward matter. "How do you really want to build a new desktop
app (regardless of language)?" is the hard part.
There has been some talk on the yaws list and some here regarding
dynamic Web UIs. This is the general direction app developers are
taking and there will exist / do exist methods to make these apps "work
like / install like" the desktop apps you are accustomed.
regards, ke han
Post by unknown
I am new to functional programming (just some very little experience
with Lisp). I got interested in functional programming because of the
performance related to multiproccessors or multicore systems. And I got
interested in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to Haskell or
others.
But, do you see Erlang suitable for developing future (more than 5 years
from now) desktop applications? I know it wasn't designed for this, and
that there are very important actions like string functions which are
slow in Erlang... but then I also ran into EX11 and similar projects
which seem like a little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not, could you
recommend other functional languages that fit best that objective?
I'm looking forward to efficiency on future multicore processors and
easy concurrency management.
Thanks all.
I don't know if I have fully understood all of the things, so sorry if
you see I didn't get the complete meaning of some part (sorry... not a
native English speaker).

Although I agree with you applications will get more "separated" from
the UI part, I don't quite see it as a whole server+UI thing, at least
as I understand that... Well I really had the (completely hypothetical)
idea of making a UI which the same code could be exported to desktop UI
(like GTK or whatever), web (with XML11) and console. So, in some way,
the implementation would be with the UI code, but that UI would be
accessible in the main three ways (desktop, web, and console).
For that idea... Mono has lots of things to offer, but I'm pretty much
concerned about the performance it can be achieved with Mono when
running on multicore architectures and the ease of the coding to get a
good performance.

Think that when I say desktop apps I refer to a whole bunch of typical
apps you can see in a desktop, not just one app I could have in mind
right now. Think of filemanagers, games, media players and that sort of
apps... And as I've just said to Richard A. O'Keefe, I don't know if
Erlang is also strong in those kind of developments (I don't know if any
of those apps need a lot of concurrency where Erlang could be superior
to C/C++/C#).

Sorry if I'm being a little pain in the neck making so many questions...

Thanks for everything.
Cheers.
unknown
2006-08-08 17:07:41 UTC
Permalink
Post by unknown
Think that when I say desktop apps I refer to a whole bunch of typical
apps you can see in a desktop, not just one app I could have in mind
right now. Think of filemanagers, games, media players and that sort of
apps... And as I've just said to Richard A. O'Keefe, I don't know if
Erlang is also strong in those kind of developments (I don't know if any
of those apps need a lot of concurrency where Erlang could be superior
to C/C++/C#).
Don't make the mistake to think that concurrency in Erlang is just
good for increasing computational throughput. Processes are also
useful in a purely software engineering way: they provide isolation
between independant tasks.

A modern GUI is typically very concurrent, the user expect to be able
to jump between programs or views within programs (think tabbed
browsing). Imagine if when firefox hit a site that exposed some bug in
the renderer it would not all crash, just that tab, wouldnt it be
nice? Browsers whose GUI lock up while a domain name is being
resolved feel quite ancient too, dont they?

As for media players, sure, erlang might not be the best choice to
implement a video decoder (though computers are so scarily fast now i
would not be surprised if erlang could achive full framerate).
However, during playing I expect to be able to pick a new file to play
without stopping the current one, and also interrupt myself from file
browsing and adjust the volume then continue browsing for that cool
Erlang video.
unknown
2006-08-08 17:51:35 UTC
Permalink
Post by unknown
Post by unknown
Think that when I say desktop apps I refer to a whole bunch of typical
apps you can see in a desktop, not just one app I could have in mind
right now. Think of filemanagers, games, media players and that sort of
apps... And as I've just said to Richard A. O'Keefe, I don't know if
Erlang is also strong in those kind of developments (I don't know if any
of those apps need a lot of concurrency where Erlang could be superior
to C/C++/C#).
Don't make the mistake to think that concurrency in Erlang is just
good for increasing computational throughput. Processes are also
useful in a purely software engineering way: they provide isolation
between independant tasks.
A modern GUI is typically very concurrent, the user expect to be able
to jump between programs or views within programs (think tabbed
browsing). Imagine if when firefox hit a site that exposed some bug in
the renderer it would not all crash, just that tab, wouldnt it be
nice? Browsers whose GUI lock up while a domain name is being
resolved feel quite ancient too, dont they?
As for media players, sure, erlang might not be the best choice to
implement a video decoder (though computers are so scarily fast now i
would not be surprised if erlang could achive full framerate).
However, during playing I expect to be able to pick a new file to play
without stopping the current one, and also interrupt myself from file
browsing and adjust the volume then continue browsing for that cool
Erlang video.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Speaking of decoders, here (http://www.dadgum.com/james/performance.html)
is the article that got me started using Erlang shortly after I read it.
I was reading up on (of all things) performance and came across 'Erlang'.
Further investigation got me hooked.

~Michael
unknown
2006-08-07 13:27:18 UTC
Permalink
Erlang is fine for desktop applications--fantastic, even. Just make
good use of the easy concurrency and integrated TCP support to
communicate with external processes and make good use of languages
with solid GUI libraries.

Or, more succinctly, write the GUI portion of an application in
Objective C (on the Mac) or C# (under Windows) and transfer data back
and forth through a port.

'twould be nice to have solid GUI support in Erlang--wxWindows makes a
lot of sense--but you can get along fine without it. Possibly a
better option is to run your app as a local webserver and use a
browser for the GUI.
unknown
2006-08-08 18:28:36 UTC
Permalink
--- "Jacobo G. Polavieja" <jacobopolavieja>
Post by unknown
Think of filemanagers, games, media players and that
sort of apps... And as I've just said to Richard A.
O'Keefe, I don't know if Erlang is also strong in
those kind of developments
You will definitely be an early adopter if you develop
desktop apps in Erlang; as usual, early adoption means
things haven't been smoothed by a thousand people
before you. Also, being an early adopter, most of the
existing desktop developers will be elsewhere. Being a
trailblazer is more work.

That said, I think general desktop apps still have
some way to go. They often irritatingly freeze up when
blocking for some resource, and they are often
unsophisticated about accessing network resources, for
example. Erlang could help.
Post by unknown
(I don't know if any of those apps need a lot of
concurrency where Erlang could be superior
to C/C++/C#).
Wasn't your initial point that you wanted to exploit
multicore systems? When the clock rate is constant,
your future speedup is determined by available
parallelism, which means you may have to design your
system and algorithms for parallel execution.

Low amounts of parallelism (e.g., today's apps) means
your app will hit the roof pretty soon, and
furthermore won't be improved by future processor
generations.

(This assumes that the number of cores will start to
double every N months; I'm not entirely convinced that
that will happen for an extended period of time,
though.)

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
unknown
2006-08-10 06:33:16 UTC
Permalink
Post by unknown
Wasn't your initial point that you wanted to exploit
multicore systems? When the clock rate is constant,
your future speedup is determined by available
parallelism, which means you may have to design your
system and algorithms for parallel execution.
As an aside, even something as "primitive" as a Nintendo DS, qualifies
as multicore since it has an ARM9 and an ARM7 as well as a graphics chip.

Most of the primitive I/O runs on the ARM7 processor which gets used as
a slave. The heavy computation goes into the ARM9 and the graphics gets
offloaded.

The ARM9 and ARM7 even have a hardware FIFO which triggers interrupts so
that the ARM9 and ARM7 can pass things back and forth asynchronously.

-a
unknown
2006-08-10 12:01:29 UTC
Permalink
Post by unknown
The ARM9 and ARM7 even have a hardware FIFO which triggers interrupts so
that the ARM9 and ARM7 can pass things back and forth asynchronously.
I have a 'tutorial' on programming the DS that covers the FIFO for
those interested:

http://www.double.co.nz/nintendo_ds/nds_develop7.html

With only 4MB of memory I imagine there's not much room for an Erlang
port there?

Chris.
--
http://www.bluishcoder.co.nz
unknown
2006-08-09 07:02:49 UTC
Permalink
there are three GUI bindings (besides GS) that i know of;

wxerlang wxerlang.sourceforge.net
erlgtk erlgtk.sourceforge.net
gtkNode jungerl.sourceforge.net

all of them are (as far as i can tell) beta. however, i personally use both
erlgtk and gtkNode daily (on unix, i dont know about windows/mac).

mats
unknown
2006-08-14 15:04:28 UTC
Permalink
Taking a *deep* breath - refreshed after three weeks on holiday *without* a computer!

Yes, Erlang could be very good for desktop applications.

<aside>
I am not convinced that there will be any desktop apps left
in 5 years - since the trend is "moving into the browser" -
the things you can do in a browser with Ajax, SVG etc. are pretty impressive
so the need for desktop apps is fading away - for this kind of
architecture Erlang is great for the sever side of things
</aside>

I the last dozen years, give of take a decade or so, I have implemented
several GUI interfaces - non of which were very good.

At a certain point in time I always gave up - when I hit an almost impassable
barrier that meant I would have to entirely re-write *everything* to make the next step.

The approach I liked best was ex11 - this is "suspended" rather than abandoned -
ex11 is fine as far as it goes, but the next step involves typography, font rendering etc.

I'd like *correct* (or at least beautiful) kerning of the text in menus,
nice anti-aliased fonts, alpha blending etc. Basically a merge of the ex11 code
with erlguten - this is <<difficult>>.

Having played with just about every free software package for GUIs that I can lay my hands on
I'd say that almost all of them suck. The problem is deep. It has to do with the
architecture of the GUI systems and how they are layered.

Virtually *all* GUIs systems are designed to be used by sequential programming languages,
now GUIs are in their nature "parallel" - so there is a semantic mismatch between the
GUI architecture and the programming language. To fix this the notion of a callback is
used - callbacks are used to provide the illusion of concurrency. With real concurrency
the traditional callback view of the world is not needed.

The Erlang view is this:

Each window is represented by a process
To modify a window I sent it a message
When things happen in a window I get sent messages

The tradition GUI (GTK, wxwindows, etc.) is

Each window is represented by an object
To modify a window I call a functions
When things happen in a window callbacks occur

These two ways of thinking about the world are fundamentally different and
incompatible.

In the Erlang view we have true concurrency, in the tradition GUI view we have
the illusion of concurrency provided by callbacks - superficially these are equivalent
but because the traditional GUI uses a sequential top-loop and dispatcher the
two are very different.

One consequence of the sequential call-back approach is that embedded sub-widgets
with behaviour become painfully difficult to write. You can just suspend filling in a
form here, to go and do something else there...

Now the problem with providing an interface to gtk, tk etc (and yes I, know these exist)
is that you have to learn and use the gtk, tk etc. programming model in Erlang.

If you make a 1:1 correspondence between Erlang and GTK, then you are forced to use the GTK
programming model in Erlang - so now you have to program using some weird half-baked
programming style involving callbacks that sucketh greatly.

Indeed GUI callback programming is so difficult that mere mortals find this
impossibly difficult - witness the GUI builders that try to do the job for you.

The need for the GUI builders arises from the horrendous mess of callback structures
that has to be setup in order to program the simplest of tasks.

<aside>
When I did ex11 I used the X11 protocol *directly* I only needed to implement
60 odd messages, by comparison the Xlib library (which provide a callback structure)
on top of the X11 protocol have c. 800 routines
</aside>

The complexity of GUI programming is a direct consequence of using a sequential programming
language for solving a concurrent problem.

Taking another deep breath ......

Now I've got that off my chest ...

Next problem:

GUI software is not nicely layered - the reason ex11 was *easy* to write was that the
layers were clear. The X11 protocol nicely separates the primitives from the libraries Xlib.

To implement a decent Erlang GUI I need *only* the low level operations -
I don't need buttons, controls, etc. Just the ability to create windows and draw
persistent bitmaps in the window - *nothing else* (well a bit more actually).

Implementing a graphic system on top of GDK might make a lot of sense, but not GTK (for the
reasons above) - BUT GDK and GTK appear to be horribly intertwined.

Next problem:

Cross-platform????

This I believe is the biggest mistake I've every made regarding GUIs - just believing
that cross platform GUIs are possible at all.

They truth is cross platform GUIs just do not look good - period end of story.

Sure I can make a TK thing run on windows and Linux but it just does not look as good
as a native application.

Interestingly the only cross platform apps that seems half acceptable are things like
Photoshop, openoffice, Smalltalk etc. These do not seem to use native widget sets, but
are acceptable anyway since they have outstanding functionality.

So I forgive Photoshop, running on windows, for not having native windows GUI controls
since the program itself is outstanding.

Conclusion: using native widgets only and forget cross platform.

I reality "desktop applications" means window applications.

Unfortunately, I do most of my development in a Linux environment - the
flavour here is irrelevant, today it's ubuntu, yesterday is was red-hat, tomorrow
debian, who cares - the point is that it is *not* windows - and I dislike developing
in windows BUT and here's the kicker - if I develop an application 98% of my potential
users will be running windows.

That's why developers (like me) love the idea of "cross platform" - then I can develop
on Linux, and deploy on windows.

This my friends is an illusion.

Once day I must "bite the bullet" and implement a low-level interface from Erlang to
the windows API - this is a must for windows desktop applications.

/Joe
-----Original Message-----
From: owner-erlang-questions
[mailto:owner-erlang-questions] On Behalf Of
Jacobo Garc?a de Polavieja Aguilera
Sent: den 6 augusti 2006 16:40
To: erlang-questions
Subject: Erlang for desktop applications?
I am new to functional programming (just some very little
experience with Lisp). I got interested in functional
programming because of the performance related to
multiproccessors or multicore systems. And I got interested
in Erlang over other FP languages because its fame for easy
parallelism management and its performance compared to
Haskell or others.
But, do you see Erlang suitable for developing future (more
than 5 years from now) desktop applications? I know it wasn't
designed for this, and that there are very important actions
like string functions which are slow in Erlang... but then I
also ran into EX11 and similar projects which seem like a
little light for my future purpose.
Could be erlang efficient with desktop related stuff? If not,
could you recommend other functional languages that fit best
that objective?
I'm looking forward to efficiency on future multicore
processors and easy concurrency management.
Thanks all.
unknown
2006-08-15 10:34:59 UTC
Permalink
Joe Armstrong (TN/EAB) wrote:

[...]
Post by unknown
Now the problem with providing an interface to gtk, tk etc (and yes I, know these exist)
is that you have to learn and use the gtk, tk etc. programming model in Erlang.
not really.
Post by unknown
If you make a 1:1 correspondence between Erlang and GTK, then you are forced to use the GTK
programming model in Erlang - so now you have to program using some weird half-baked
programming style involving callbacks that sucketh greatly.
but you don't have to "make a 1:1 correspondence". gtkNode (with which i'm
most familiar) exposes less than half of the GTK API, and no callbacks
whatsoever. on the erlang side, everything's done through message passing.
not that there's not a great deal of suckiness, like you say caused mainly by
the C-iness of (in this case) GTK.
Post by unknown
Indeed GUI callback programming is so difficult that mere mortals find this
impossibly difficult - witness the GUI builders that try to do the job for you.
The need for the GUI builders arises from the horrendous mess of callback structures
that has to be setup in order to program the simplest of tasks.
a GUI builder is a must regardless of the callback structure. a fancy GUI is
a very complicated thing (no matter what programming model you're using), and so
you need a powerful tool to design one.
Post by unknown
The complexity of GUI programming is a direct consequence of using a sequential programming
language for solving a concurrent problem.
GUI programming is pretty complicated, because GUIs are complicated.
concurrency is not really the main problem (how often do you really want to
press two buttons at the same time?). as i see it, the complexity is caused by
two things;

solving ANY complicated problem in C/C++ will typically generate suckiness
C/C++ is particularly bad at event-driven programming.
Post by unknown
Cross-platform????
This I believe is the biggest mistake I've every made regarding GUIs - just believing
that cross platform GUIs are possible at all.
They truth is cross platform GUIs just do not look good - period end of story.
well... the desktop apps i use on my wife's windozer are thunderbird, firefox
and the gimp.
all cross-platform (GTK). and they DO look good.
and of course, using a browser (or something like the konfabulator) as the
gui is cross-platform.

mats
unknown
2006-08-15 00:50:37 UTC
Permalink
"Jacobo G. Polavieja" <jacobopolavieja> wrote:

That's my main point of view and what drove me to consider a better
language for programming concurrency. I truly believe is going to be
like that in the future. So, do you see Erlang is the/one of the most
best positioned to take advantage of that future fact?

People have been designing concurrent languages for years.
Burroughs Algol, back in the 60s, had coroutines and concurrent processes
(and even ran on true multiprocessor hardware in the 70s).
Simula 67, famed for introducing Object-Oriented Programming, was
also important for offering (simulated) concurrency.
We've had Concurrent Pascal, Concurrent C, C++ originally came with
a Simula-inspired threads package, Ada, Occam, you name it.

Of the many ways to look at these languages, one of them seems to me
to be the most useful for our present topic:

- is the language "business as usual PLUS threads" (like Java)
- or is it designed from the ground up to support correct concurrent
programming?

This is not quite the same question as "is thread support integrated into
the language" (as it is in Ada) or "is thread support pretty much a bolt-
on-the-side library" (as it arguably is in Java, and if you don't believe
me, browse around in java.util.concurrent some time -- I'm sure tentacled
monstrosities from the outer darkness were involved somewhere there).
The question is rather "was the language so designed that it is easy for
a compiler or other tool to PROVE that a wide range of concurrency problems
simply cannot occur?"

Concurrent Pascal and Occam (up to Occam 2.1, which was the last Occam I
really understood) have rather strong limitations, precisely to make it
easier to reason about concurrent programs and make it obvious that many
problems (notably one thread trampling on another's data, but there are
others) couldn't possibly exist in a program.

While Java looks to have concurrency support built in, it is fatally easy
for two threads to trample on the same data, and it is fatally easy to
_think_ you are protected from this when you aren't. In contrast, in Ada
it's really quite hard to get yourself into that kind of trouble, and if
you stick to the "safe" features of the language, I don't think you can.

C# and the whole .NET framework falls into the same "mostly business as
usual" bucket as Java.

Make no mistake. People have developed useful concurrent applications
using Java and C# and will continue to do so. (Especially if they are
savvy enough to use verification tools like ESC/Java2.)

BUT

"mostly business as usual" language make it easy for people to keep on
thinking and programming sequentially. This makes it harder for them
to exploit multicore machines and easier to make mistakes.

many "actions" taken in desktop apps that are very concurrent or just
concurrent. I mean... all I can think about that could benefit from
Erlang's concurrency is a mail application (to retrieve mail), P2P
application (interconnect users)... which are very "networky" (where
Erlang is strong).

I'm not really sure what a "desktop app" is. I suppose it includes
- e-mail
- word processor
- spread-sheet
- data base
- web browser
- drawing/diagramming tool
- photo display, capture, and edit
- music playing, recording, and editing
- video playing, recording, and editing
- games
- virtual pets
- telephone and fax

Concurrency can be found in surprising places.
For example, consider searching for a word or phrase in a word processor.
Chop the document up into N pieces and have each of N processors look in
its piece. Only really useful for large documents. But change your
perspective: what if a document isn't something nailed to a particular
machine? Think about SubEthaEdit, for example. Collaborative document
editing over the web. That's a desktop application right now.

Data base? The epitome of concurrency.

Photo rendering and editing? Lots of this is embarrassingly parallel.

Games? Thread per player, at least. If it's in a forest, think of
simulating the motion of each tree at the same time (not all trees are
the same). Think of route planning. All sorts of stuff.

I've got an application right now, document clustering, where I could
*easily* exploit 16 processors if I had them.


I just don't now if a chat program, or a web browser, or a file manager,
or a document viewer, a game, a multimedia player and all the usual
desktop applications need lots of concurrency and can benefit from
Erlang or if it would be better to use some thing like C# with the
little concurrency it implements.

I think I'll have to learn Erlang and finish my PThreads
studying, make typical desktop programs with both... and then
compare :-|. Ocaml is a candidate too from what I've heard.

Ah, there's your mistake. TYPICAL desktop programs already exist!
We already have more word processors than the market really wants.
What we need are NOVEL desktop programs; ones that do useful and interesting
things that don't have saturated markets, and that exploit the new machines
to do things that nobody ever thought of before.

If I could think of such things, I wouldn't be scraping a slender living
as a University lecturer.

OK, here's an idea, but I don't think it's a good enough idea to make
money. Think about someone writing the Great New Zealand Novel on their
computer. They have a local copy of the Wikipedia (we do have such a
copy here, as part of our information retrieval work) and everything
from Project Gutenberg (I don't have that, but I could if I wanted to).
While they type, the computer is "mentally" chopping their novel up into
"topical" pieces and adding links to relevant stuff in the Wikipedia and
Project Gutenberg. (We have a masters student who we hope will work on
adding Wikipedia links; this is stuff that can be done *now*.)

The thing here is that the actual text editing doesn't need much computing
power. What we _really_ need here is fault isolation. The information
gleaning stuff is *helpful* to the author but not essential; the one
absolutely crucial thing is that if the helpful stuff crashes, it MUST NOT
take the main stuff with it.

Oh, so here's another thing that's happening at the same time. The changes
are being backed up over the local (wire or wireless) net to one or more
other machines in a P2P sort of way, while the work being done on those
machines is similarly being backed up to this machine. Again, this is
*today's* technology. (I warned you I wasn't much good at thinking up
novel stuff.)

Look for opportunities concurrency and you will find them.

Look for opportunities for fault isolation and you will find them.
unknown
2006-08-15 12:05:57 UTC
Permalink
Post by unknown
GUI programming is pretty complicated, because GUIs are complicated.
concurrency is not really the main problem (how often do you really want to
press two buttons at the same time?).
I agree that writing a GUI is hard. But, in my experience dealing
with the user input side of things is actually quite easy. The hard
part (for me) comes when other events need to get reflected in the
GUI. This is where you end up having real concurrency (or
alternatively you write a cheap GUI that has update buttons :-). You
need to be able to sensibly reflect the users actions, while at the
same time show changes in any underlying models (a noddy example is a
filebrowser, it needs to show the current state of the folders, not
the one that was current when you first opened it).

Conceptually, MVC tries to address some of this. And if you view the
MVC components as parallel entities, the model works quite neatly.

But if you are stuck in a sequential model (even one that can use
threads), then changes to your Model need to be explicitly serialised,
someone needs to make decisions on when to update the View, and so on.
I have so far not come across any nice support in any environment
(even Smalltalk) that would allow the writing of MVC components as
parallel, communicating entities. My guess is that at some stage in
the design of all of these, someone decided to sacrifice elegance and
ease of use to the god of efficiency. I'll stop ranting here.

Robby
unknown
2006-08-15 12:49:30 UTC
Permalink
Have you looked at CoreData on the Mac?

http://developer.apple.com/macosx/coredata.html
Post by unknown
I have so far not come across any nice support in any environment
(even Smalltalk) that would allow the writing of MVC components as
parallel, communicating entities. My guess is that at some stage in
the design of all of these, someone decided to sacrifice elegance and
ease of use to the god of efficiency. I'll stop ranting here.
Robby
--
http://wagerlabs.com/
unknown
2006-08-23 03:46:37 UTC
Permalink
One OS-halfway-independant-way to build desktop applications is to
create Firefox extensions which use XUL (this are just XML documents
and CSS stylesheets) for GUI and XPCOM bindings for programming
language integration. XPCOM bindings exist currently for Javascript
and Python. A good Example for such in-browser XUL apps is upcoming
http://allpeers.com a P2P and Bittorrent client which has its core
code written in C++ and packaged as XPCOM. Another interesting fact
about such firefox extensions is that they can integrate with webites
(any website: the Firebug extension, specific websites: Greasemonkey).

No I am wondering whether anybody has spent thoughts on using XUL as
GUI toolkit for Erlang, to create Erlang powered firefox extensions.
What is necesssary to make that happen ?

- Erlang XPCOM Bindings (need to find out what exactly that means)
- A smart way to package a minimal Erlang Runtime environment into a
frefox extension (*.xpi file) far all the different plattforms

Did I miss something ?

regards
--
Roberto Saccon
unknown
2006-08-23 04:47:20 UTC
Permalink
A few minutes of further research revealed that I missed an important thing:

XUL bindings for Erlang (and they need to go into mozilla trunk, which
is very unrealistic for the not-so-far future)

see link below for an example of Python XUL bindings (which will be
available for Firefox 3):

http://weblogs.mozillazine.org/roadmap/archives/008865.html

Possible workaround: Use Javascript for GUI stuff and go from there
via Erlang XPCOM bindings.
Post by unknown
One OS-halfway-independant-way to build desktop applications is to
create Firefox extensions which use XUL (this are just XML documents
and CSS stylesheets) for GUI and XPCOM bindings for programming
language integration. XPCOM bindings exist currently for Javascript
and Python. A good Example for such in-browser XUL apps is upcoming
http://allpeers.com a P2P and Bittorrent client which has its core
code written in C++ and packaged as XPCOM. Another interesting fact
about such firefox extensions is that they can integrate with webites
(any website: the Firebug extension, specific websites: Greasemonkey).
No I am wondering whether anybody has spent thoughts on using XUL as
GUI toolkit for Erlang, to create Erlang powered firefox extensions.
What is necesssary to make that happen ?
- Erlang XPCOM Bindings (need to find out what exactly that means)
- A smart way to package a minimal Erlang Runtime environment into a
frefox extension (*.xpi file) far all the different plattforms
Did I miss something ?
regards
--
Roberto Saccon
--
Roberto Saccon
unknown
2006-08-23 06:09:35 UTC
Permalink
One way to go with XUL is not to use XPCOM but to load your XUL-application
from the webbserver and to handle events in a AJAX fashion (using the JSON
support on Yaws maybe :-). This means you do not have to install anything on
your client side, except Firefox. I think start times for such applications
are OK, if they are not too complex and considering that Firefox is already
up and running.

If you still wan't to build XPCOM bindings one way to go could be to use
Erlangs Corba support, since the interfaces to XPCOM is specified in XPIDL,
a Corba style interface, and since there are some bridges:
http://www.cmiss.org/ReleaseCenter/xpcorba
http://xpcom2corba.sunsite.dk/

Generally I think you could do some really nice applications using Firefox XUL
and a (Yaws) server. The RDF support that comes with Firefox and XUL is also
something really interesting. See the RDF tutorial on:
http://www.xulplanet.com/
for instance.

Regards
Mikael
Post by unknown
XUL bindings for Erlang (and they need to go into mozilla trunk, which
is very unrealistic for the not-so-far future)
see link below for an example of Python XUL bindings (which will be
http://weblogs.mozillazine.org/roadmap/archives/008865.html
Possible workaround: Use Javascript for GUI stuff and go from there
via Erlang XPCOM bindings.
unknown
2006-08-23 06:34:10 UTC
Permalink
Yariv's blog http://yarivsblog.com/ with his frequent Erlang postings
has inspired me.

I think he needs a little competition :-)

So I've started writing ...

In this blog I'll try to tell you some of the things that are happening
in the Erlang world. A lot of stuff is happening behind the scenes, I'll
try
to tell you about some of this.

The first post is:

http://armstrongonsoftware.blogspot.com/2006/08/making-money-from-erlang
.html

Cheers

/Joe
unknown
2006-08-23 08:06:56 UTC
Permalink
Joe - that's great; thanks. Would you be able to make an RSS feed
available? That makes it easier to read via an RSS readers?


Kind regards,

Simon
Post by unknown
Yariv's blog http://yarivsblog.com/ with his frequent Erlang postings
has inspired me.
I think he needs a little competition :-)
So I've started writing ...
In this blog I'll try to tell you some of the things that are happening
in the Erlang world. A lot of stuff is happening behind the scenes, I'll
try
to tell you about some of this.
http://armstrongonsoftware.blogspot.com/2006/08/making-money-from-erlang
.html
Cheers
/Joe
unknown
2006-08-23 09:18:15 UTC
Permalink
Post by unknown
Joe - that's great; thanks. Would you be able to make an RSS feed
available? That makes it easier to read via an RSS readers?
There's an atom feed:

http://beta.blogger.com/feeds/5246027334551923738/posts/full

Chris.
--
http://www.bluishcoder.co.nz
unknown
2006-08-23 10:07:41 UTC
Permalink
The Erlang blogosphere is growing! I also write about Erlang below.

--
http://wagerlabs.com/
unknown
2006-08-23 09:27:12 UTC
Permalink
Post by unknown
Joe - that's great; thanks. Would you be able to make an RSS feed
available? That makes it easier to read via an RSS readers?
You'll find that at Planet erlang.


--Tobbe
Post by unknown
Kind regards,
Simon
Post by unknown
Yariv's blog http://yarivsblog.com/ with his frequent Erlang postings
has inspired me.
I think he needs a little competition :-)
So I've started writing ...
In this blog I'll try to tell you some of the things that are happening
in the Erlang world. A lot of stuff is happening behind the scenes, I'll
try
to tell you about some of this.
http://armstrongonsoftware.blogspot.com/2006/08/making-money-from-erlang
.html
Cheers
/Joe
unknown
2006-08-24 16:21:27 UTC
Permalink
Using BottomFeeder (http://www.cincomsmalltalk.com/BottomFeeder/)
on Linux, I get ...

"Unable to process feed or query - http://planeterlang.org/rss20.xml"
AND
"Unable to process feed or query - http://planeterlang.org/rss10.xml"

I have successfully been using BottomFeeder for a few years.


QUESTIONS:

Is anyone else having problems with planeterlang RSS feed (what reader) ?
Is anyone else having success with planeterlang RSS feed (what reader) ?
Am I using the wrong URL (what should I use) ?
Any other suggestions ?


thanks,

~Michael
Post by unknown
Post by unknown
Joe - that's great; thanks. Would you be able to make an RSS feed
available? That makes it easier to read via an RSS readers?
You'll find that at Planet erlang.
--Tobbe
Post by unknown
Kind regards,
Simon
Post by unknown
Yariv's blog http://yarivsblog.com/ with his frequent Erlang postings
has inspired me.
I think he needs a little competition :-)
So I've started writing ...
In this blog I'll try to tell you some of the things that are happening
in the Erlang world. A lot of stuff is happening behind the scenes, I'll
try
to tell you about some of this.
http://armstrongonsoftware.blogspot.com/2006/08/making-money-from-erlang
.html
Cheers
/Joe
--
Michael McDaniel
Portland, Oregon, USA
http://autosys.us
+1 503 283 5284
unknown
2006-08-24 21:06:57 UTC
Permalink
On Thu, Aug 24, 2006 at 09:21:27AM -0700, Michael McDaniel wrote:
}
} Is anyone else having success with planeterlang RSS feed (what reader) ?

Works for me. I'm using:

Nokia S60 3rd Edition Feeds Client v3.0 (0529)


-Vance
unknown
2006-08-24 21:37:21 UTC
Permalink
Post by unknown
}
} Is anyone else having success with planeterlang RSS feed (what reader) ?
Nokia S60 3rd Edition Feeds Client v3.0 (0529)
-Vance
And works excellent in Thunderbird !!

--Tobbe
unknown
2006-08-25 06:40:33 UTC
Permalink
Works ok in JetBrains Omea RSS Reader
Post by unknown
Using BottomFeeder (http://www.cincomsmalltalk.com/BottomFeeder/)
on Linux, I get ...
"Unable to process feed or query - http://planeterlang.org/rss20.xml"
AND
"Unable to process feed or query - http://planeterlang.org/rss10.xml"
I have successfully been using BottomFeeder for a few years.
Is anyone else having problems with planeterlang RSS feed (what reader) ?
Is anyone else having success with planeterlang RSS feed (what reader) ?
Am I using the wrong URL (what should I use) ?
Any other suggestions ?
thanks,
~Michael
Post by unknown
Post by unknown
Joe - that's great; thanks. Would you be able to make an RSS feed
available? That makes it easier to read via an RSS readers?
You'll find that at Planet erlang.
--Tobbe
Post by unknown
Kind regards,
Simon
Post by unknown
Yariv's blog http://yarivsblog.com/ with his frequent Erlang
postings
Post by unknown
Post by unknown
Post by unknown
has inspired me.
I think he needs a little competition :-)
So I've started writing ...
In this blog I'll try to tell you some of the things that are
happening
Post by unknown
Post by unknown
Post by unknown
in the Erlang world. A lot of stuff is happening behind the scenes,
I'll
Post by unknown
Post by unknown
Post by unknown
try
to tell you about some of this.
http://armstrongonsoftware.blogspot.com/2006/08/making-money-from-erlang
Post by unknown
Post by unknown
Post by unknown
.html
Cheers
/Joe
--
Michael McDaniel
Portland, Oregon, USA
http://autosys.us
+1 503 283 5284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060825/eb30e8cb/attachment.html>
unknown
2006-08-25 08:10:30 UTC
Permalink
OK in KDE's Akregator, too.
Post by unknown
Works ok in JetBrains Omea RSS Reader
Post by unknown
Using BottomFeeder
(http://www.cincomsmalltalk.com/BottomFeeder/) on Linux, I
get ...
"Unable to process feed or query -
http://planeterlang.org/rss20.xml" AND
"Unable to process feed or query -
http://planeterlang.org/rss10.xml"
I have successfully been using BottomFeeder for a few years.
Is anyone else having problems with planeterlang RSS feed
(what reader) ? Is anyone else having success with
planeterlang RSS feed (what reader) ? Am I using the wrong
URL (what should I use) ?
Any other suggestions ?
thanks,
~Michael
On Wed, Aug 23, 2006 at 11:27:12AM +0200, Torbjorn Tornkvist
Post by unknown
Post by unknown
Joe - that's great; thanks. Would you be able to make an
RSS feed available? That makes it easier to read via an
RSS readers?
You'll find that at Planet erlang.
--Tobbe
Post by unknown
Kind regards,
Simon
Post by unknown
Yariv's blog http://yarivsblog.com/ with his frequent
Erlang
postings
Post by unknown
Post by unknown
Post by unknown
has inspired me.
I think he needs a little competition :-)
So I've started writing ...
In this blog I'll try to tell you some of the things
that are
happening
Post by unknown
Post by unknown
Post by unknown
in the Erlang world. A lot of stuff is happening behind
the scenes,
I'll
Post by unknown
Post by unknown
Post by unknown
try
to tell you about some of this.
http://armstrongonsoftware.blogspot.com/2006/08/making-money
-from-erlang
Post by unknown
Post by unknown
Post by unknown
.html
Cheers
/Joe
--
Michael McDaniel
Portland, Oregon, USA
http://autosys.us
+1 503 283 5284
--
Romain LENGLET
unknown
2006-08-25 13:40:17 UTC
Permalink
Thank you everyone who responded. I have sent in bug report for
BottomFeeder.

~M
Post by unknown
OK in KDE's Akregator, too.
Post by unknown
Works ok in JetBrains Omea RSS Reader
Post by unknown
Using BottomFeeder
(http://www.cincomsmalltalk.com/BottomFeeder/) on Linux, I
get ...
"Unable to process feed or query -
http://planeterlang.org/rss20.xml" AND
"Unable to process feed or query -
http://planeterlang.org/rss10.xml"
I have successfully been using BottomFeeder for a few years.
Is anyone else having problems with planeterlang RSS feed
(what reader) ? Is anyone else having success with
planeterlang RSS feed (what reader) ? Am I using the wrong
URL (what should I use) ?
Any other suggestions ?
thanks,
~Michael
On Wed, Aug 23, 2006 at 11:27:12AM +0200, Torbjorn Tornkvist
Post by unknown
Post by unknown
Joe - that's great; thanks. Would you be able to make an
RSS feed available? That makes it easier to read via an
RSS readers?
You'll find that at Planet erlang.
--Tobbe
Post by unknown
Kind regards,
Simon
Post by unknown
Yariv's blog http://yarivsblog.com/ with his frequent Erlang
postings
Post by unknown
Post by unknown
Post by unknown
has inspired me.
I think he needs a little competition :-)
So I've started writing ...
In this blog I'll try to tell you some of the things
that are
happening
Post by unknown
Post by unknown
Post by unknown
in the Erlang world. A lot of stuff is happening behind the scenes,
I'll
Post by unknown
Post by unknown
Post by unknown
try
to tell you about some of this.
http://armstrongonsoftware.blogspot.com/2006/08/making-money
-from-erlang
Post by unknown
Post by unknown
Post by unknown
.html
Cheers
/Joe
--
Michael McDaniel
Portland, Oregon, USA
http://autosys.us
+1 503 283 5284
--
Romain LENGLET
--
Michael McDaniel
Portland, Oregon, USA
http://autosys.us
+1 503 283 5284
unknown
2006-08-25 15:20:10 UTC
Permalink
Post by unknown
Thank you everyone who responded. I have sent in bug report for
BottomFeeder.
<snip>

There's a bug fix posted in the dev stream updates now.
unknown
2006-08-24 07:45:16 UTC
Permalink
Hello,
Post by unknown
Joe - that's great; thanks. Would you be able to make an RSS feed
available? That makes it easier to read via an RSS readers?
Please, note that if you are interested in the Erlang blogosphere in
general, PlanetErlang is doing a good jood promoting a unified view of
what is being written.

The PlanetErlang is available from:
http://www.planeterlang.org/

Do not hesitate to send me blogs URL that I might have been missing.

Cheers,
--
Micka?l R?mond
http://www.process-one.net/
unknown
2006-08-23 14:40:51 UTC
Permalink
Joe,

This is great! I'm honored that my blog has inspired you to start
blogging. It's the best accomplishment of my blog so far :)

On this note, I should say that Joel Reymont's http://wagerlabs.com
blog about Erlang has both increased my interest in Erlang before I
started coding in Erlang a few months ago, as well as inspired me to
blog about it.

Best regards,
Yariv
Post by unknown
Yariv's blog http://yarivsblog.com/ with his frequent Erlang postings
has inspired me.
I think he needs a little competition :-)
So I've started writing ...
In this blog I'll try to tell you some of the things that are happening
in the Erlang world. A lot of stuff is happening behind the scenes, I'll
try
to tell you about some of this.
http://armstrongonsoftware.blogspot.com/2006/08/making-money-from-erlang
.html
Cheers
/Joe
unknown
2006-08-24 07:06:49 UTC
Permalink
Post by unknown
Joe,
This is great! I'm honored that my blog has inspired you to start
blogging. It's the best accomplishment of my blog so far :)
On this note, I should say that Joel Reymont's http://wagerlabs.com
blog about Erlang has both increased my interest in Erlang before I
started coding in Erlang a few months ago, as well as inspired me to
blog about it.
Actually, that post began a several-months-long Erlang-related frenzy
in one of Russia's biggest online programming communities,
www.rsdn.ru. It has now subsided somewhat, but Erlang still appears
there in different discussions :)

So, blog away guys. You may be considered Erlang's first evangelists.
Hopefully, others will follow :)
Post by unknown
Best regards,
Yariv
Post by unknown
Yariv's blog http://yarivsblog.com/ with his frequent Erlang postings
has inspired me.
I think he needs a little competition :-)
So I've started writing ...
In this blog I'll try to tell you some of the things that are happening
in the Erlang world. A lot of stuff is happening behind the scenes, I'll
try
to tell you about some of this.
http://armstrongonsoftware.blogspot.com/2006/08/making-money-from-erlang
.html
Cheers
/Joe
unknown
2006-08-24 07:30:02 UTC
Permalink
Hi Guys,

I have been asked to hold a talk at a Smalltalk conference <gulp>

So I have to convince a conference room full of Smalltalkers to become
Erlangtalkers.

As part of the lecture I have promised to hold a "5 second Erlang
course"

I need help and suggestions in preparing this course.

My first attempt was

"To make a fault-tolerant system you need two computers because if you
only have one and it
crashes you're sunk so you'd better use Erlang cos all other languages
suck."

Which I can just about say in 5 seconds.

So now comes the challenge.

Can you suggest alternative/better course material.

I'd like you to send me your course suggestions, in both the 5 and 10
second category.

< the 10 second category is wide open >

A prize will be awarded at the next Erlang conference to the winner

The judges for this competition are

- Joe Armstrong
- Hans Nilsson
- Ulf Wiger

The judges decision will be arrived at by a undefined voting procedure,
and is final.

/Joe
unknown
2006-08-24 07:53:06 UTC
Permalink
A fault-tolerant system must work across at least two computers,
because a system on a single computer can crash. The more computers
the higher stability, as witness the internet. Erlang is a language
suited to building fault tolerant systems.
unknown
2006-08-24 10:11:38 UTC
Permalink
5s: How would you program if processes were limitless, IPC was trivial,
and you only coded for success cases?
10s: First you bend your mind to Erlang, then you bend Erlang to fit
your problem. Your problem stays in its domain, and you model it with
concurrent processes, message passing, and supervision trees.
unknown
2006-08-24 10:13:56 UTC
Permalink
"To make a fault-tolerant system you need an alternative... Erlang!"

About 4 seconds, including dramatic pause.

V.
unknown
2006-08-24 10:44:09 UTC
Permalink
For the 5 second category:

Erlang: When five nines is an unacceptable amount of downtime.

Simon
--
www.simonpeter.org
unknown
2006-08-24 12:01:50 UTC
Permalink
Post by unknown
I have been asked to hold a talk at a Smalltalk conference <gulp>
That happens. Here is a nice example:

Side note: When I approached the FreeBSD booth, my first question was,
"So, what's FreeBSD doing here at LinuxWorld?" Without losing a beat,
the FreeBSD guy responded, "Actually, in an alternate universe, I'm
attending BSDWorld and there's one Linux booth. However, my transporter
malfunctioned 'cause it was running Linux, and so here I am."
Best nerd one-liner I've heard at the show.

http://www.securityfocus.com/columnists/413
Post by unknown
So I have to convince a conference room full of Smalltalkers to become
"To make a fault-tolerant system you need two computers because if you
only have one and it
crashes you're sunk so you'd better use Erlang cos all other languages
suck."
Which I can just about say in 5 seconds.
So now comes the challenge.
Can you suggest alternative/better course material.
10s: In the above sense:

Loading Image...

Welcome to the mirror universe!
No OOP. No UML. Easy concurrency. Easy distribution.
Erlang.


5s:

Objects 3.0: Lightweight processes + easy distribution = Erlang



Regards,
Marc
unknown
2006-08-24 12:45:22 UTC
Permalink
5s:
"In the next 10 seconds you'll find out how to solve tough concurrent
problems at 1/10th of an effort and not to spent the rest of your life
debugging their consequences."

10s:
"What if you were to write a system that was OS-agnostic, would easily
scale to 100,000s of processes, would run on a cluster of machines,
would offer nine nines of uptime, and would have to be built in a week?
... Sounds impossible with Smalltalk? ... Add Erlang to your arsenal
and see for yourself!"

Serge
Post by unknown
Hi Guys,
I have been asked to hold a talk at a Smalltalk conference <gulp>
So I have to convince a conference room full of Smalltalkers to become
Erlangtalkers.
As part of the lecture I have promised to hold a "5 second Erlang
course"
I need help and suggestions in preparing this course.
My first attempt was
"To make a fault-tolerant system you need two computers because if you
only have one and it
crashes you're sunk so you'd better use Erlang cos all other languages
suck."
Which I can just about say in 5 seconds.
So now comes the challenge.
Can you suggest alternative/better course material.
I'd like you to send me your course suggestions, in both the 5 and 10
second category.
< the 10 second category is wide open >
A prize will be awarded at the next Erlang conference to the winner
The judges for this competition are
- Joe Armstrong
- Hans Nilsson
- Ulf Wiger
The judges decision will be arrived at by a undefined voting procedure,
and is final.
/Joe
unknown
2006-08-24 13:02:19 UTC
Permalink
Post by unknown
"In the next 10 seconds you'll find out how to solve tough concurrent
problems at 1/10th of an effort and not to spent the rest of your life
debugging their consequences."
Shouldn't that be:

"You'll find out how to solve tough concurrent
problems, at 1/10th of an effort and not to spent the rest of your life
debugging their consequences, in the next 10 seconds:"

or something... otherwise the next ten seconds will include part of
the first five seconds and there will be a system crash. Luckily the
presentation will be fault tolerant because Ulf will be giving a
presentation to a Common Lisp community concurrently.

Cheers,
Bryan Rasmussen
unknown
2006-08-24 13:53:10 UTC
Permalink
The 5 second pitch for Smalltalkers:

"Erlang is Smalltalk as Alan Kay wanted it"

Some ammunition for a talk useful to back this up..

- Smalltalkers often subscribe to the view that OO programming is about
the exchange of messages between objects. So message oriented
programming gives a starting point.

- For single assignment, Kay himself advocated it:

"Though [it] came from many motivations, two were central. ... [T]he
small scale one was to find a more flexible version of assignment, and
then to try to eliminate it altogether." Alan Kay History of Smalltalk
(1993)

"Doing encapsulation right is a commitment not just to abstraction of
state, but to eliminate state oriented metaphors from programming."
Alan Kay, Early History of Smalltalk

And its quite fashionable really as advocated by Bloch and Beck:

Favor immutability. Joshua Bloch, Effective Java (2001)

Use value objects when possible. Kent Beck, Test Driven Development (2001)

- Re: Last call optimizations.

"Object-Oriented Programming in languages that don?t require tail-call
optimizations makes no sense." Matthias Felleisen

- Re Concurrency:

"I can't understand why objects [of O-O languages] are not concurrent in
the first place." Usually attributed to Robin Milner as cited in a
Matsuoka paper ('93 I believe).

and apparently Kay himself early on described his early conception of
objects as being "little computers" that would communicate with each
other via messages. Given the cross-fertilization with Hewitt's work on
the Actor model I think its easy to claim he himself assumed massive
concurrency as a good model.

Cheers,
Niall
unknown
2006-08-25 10:40:33 UTC
Permalink
Post by unknown
I have been asked to hold a talk at a Smalltalk conference <gulp>
well, you've been challenging them for some time now (object- vs
concurrency-oriented programming) <:-)>
Post by unknown
So I have to convince a conference room full of Smalltalkers to
become Erlangtalkers.
if there's a room full of hackers, you might be able to use that
to your advantage: describe the salient features of Erlang/OTP.
then challenge them to add an "Erlang/OTP" class to their favourite
Smalltalk system (Squeak?). what are the fundamental issues
they will run into and need to take care of? how does Erlang
solve these?

I'm not a Smalltalker myself, but I doubt that the usual "Erlang is
the better language" approach is going to be fruitful in that kind of
community. You do *not* have to convince them to become
Erlangers, nor would I rate your chances highly if you tried.

You ought to be able to convince them that Erlang represents
certain ideas whose time has come, tackling issues that Smalltalks
may not have addressed yet (check carefully before making such
claims!-), but will have to address sooner rather than later, too.

In other words, accept that they'll keep doing things the
Smalltalk way, but convince them that there are problems they
need to take care of, and that Erlang represents one coherent
and well-tested set of solutions.

What might work is to look at what current Smalltalks do well,
check what Erlang does better, and then to highlight the differences
in terms of areas that Smalltalkers may not have focussed on yet
(multithreading/distribution/fault-tolerance?). You'll probably find
lots of things that Erlang does not do as well as Smalltalk (guis/
reflection/ease of tool-building?). Be honest about those, too..

just as Erlang has limitations that make some tasks more difficult
than in Smalltalk (reflection/meta-programming, for instance), so
Smalltalk has limitations that make some tasks more difficult than
in Erlang. Working out what these limitations are, and why they
are important, would give you something more welcome than the
usual sales talk for a not-invented-here language: a well-informed
talk for a well-informed audience, addressing real issues and
offering intelligent appropaches to their solution.
Post by unknown
As part of the lecture I have promised to hold a "5 second Erlang
course"
I thought Erlang was soft realtime, why the artifical hard time limit?-)

The gold-standard for conciseness there might not be the feature
bulletpoint slide, nor the 5-second sales pitch, but the Lisp-in-Lisp
or Smalltalk-in-Smalltalk executable definitions. Can you give an
Erlang-in-Erlang implementation on a single page of code?
Post by unknown
"To make a fault-tolerant system you need two computers because if you
only have one and it crashes you're sunk so you'd better use Erlang cos
all other languages suck."
you might as well not attend, then. perhaps they'll give you some credit
for bravado, but none for trying to understand their way of doing things.

by all means, highlight Erlang's successes in that area, but be careful to
understand Smalltalk's as well. eg., some decades ago, there was a famous
cover page depicting a Smalltalk system as a ship going to see while parts
of it were under (re-)construction (pre-dating Erlang's hot code replacement).

if you leave out the "cos all other languages suck" part, you have a point,
but I'd phrase it differently, presenting Erlang's ideas and contributions as
a natural extension and generalisation of Smalltalk's ideas and contributions
(to the multi-processing/distributed case, with implicit and hardware fault
tolerance, and with large teams of programmers when needed).

you need to figure out what they do already have, where Erlang offers
advantages, and where inherent Smalltalk features might get in the way
of exploiting these advantages (eg. is message passing in a typical
Smalltalk system these days loosely coupled and suited for distribution,
or tightly coupled imperative, update-everywhere, sequential?).

compare with this (from "The Early History Of Smalltalk", 1993 by Alan Kay):

In computer terms, Smalltalk is a recursion on the notion of computer itself.
Instead of dividing "computer stuff" into things each less strong than the
whole--like data structures, procedures, and functions which are the usual
paraphernalia of programming languages--each Smalltalk object is a recursion
on the entire possibilities of the computer. Thus its semantics are a bit like
having thousands and thousands of computer all hooked together by a very
fast network. Questions of concrete representation can thus be postponed
almost indefinitely because we are mainly concerned that the computers
behave appropriately, and are interested in particular strategies only if the
results are off or come back too slowly.

http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_Introduction.html

I have the feeling that this gives an almost ideal starting point: taking the
ideas as given, what happens if we insert some harsh reality:

- what if this recursion is not idealised, but real, with thousands and
thousands of *concurrently operating* processes, possibly on many
real computers, or on a single computer with multiple cores, or both?
- what if the network isn't "very fast"?
- what if some results do not come back at all?
- what if some of those computers fail or have to be rebooted?
- what if debugging a running system is a fine idea, but you simply
can't afford to stop the world while you're doing it?

(enter Erlang)

In other words, present Erlang as a natural next step in thinking about
some of the same ideas from which Smalltalk emerged. Don't try to
turn Smalltalkers into Erlangers, but do try to make Smalltalkers think
about the issues Erlang addresses. Ideally, convince them to "borrow"
what is best about Erlang, instead of adopting conventional threads
(again, check carefully what they've got). Mix with your usual spiel
on objects vs processes, perhaps tie the loop back to Smalltalk's
roots in Simula's process libs..

just one partially informed outsider's view..

good luck,
claus

ps. I'd certainly like to see a video of this. I'm trying to imagine
Alan Kay and Joe Armstrong in the same room, in violent
agreement about how everybody else never seems to get it!-)
unknown
2006-08-25 15:07:30 UTC
Permalink
Post by unknown
I'd like you to send me your course suggestions, in both the 5 and 10
second category.
Today's software requires concurrency, from multicore processors
to massively parallel distributed systems. Concurrency is hard,
but most languages make it harder than it needs to be.
Erlang makes it easy.

clocks in around 9 seconds.

----
Garry Hodgson, Senior Software Geek, AT&T CSO

Can't you hear my lambs a callin'?
Oh good shepherd won't you feed my sheep?
unknown
2006-08-26 03:10:54 UTC
Permalink
Post by unknown
Post by unknown
I'd like you to send me your course suggestions, in both the 5 and 10
second category.
"Anything that can be said in less than 10 seconds (including this), is
an oversimplification."

Sorry to be the one to pour the cold water, Joe, but I think this
5 or 10-second sound-bite thing is a bad idea.
Post by unknown
Today's software requires concurrency, from multicore processors
to massively parallel distributed systems. Concurrency is hard,
but most languages make it harder than it needs to be.
Erlang makes it easy.
Plenty of today's software does not require concurrency (at the programming
language level).

The second sentence is fine, but it doesn't say anything about Erlang.

Erlang does not make concurrency *easy*. Programming in general is not
easy -- even quite trivial programs often have errors.

It is not clear that making concurrency easy is a primary goal,
regardless of its possibility. "Reliable but difficult" would trump
"unreliable and easy".


(I could have made similar kinds of criticisms of most any of the
suggestions so far.)

----

Programmers are pedantic, skeptical people -- or else they wouldn't be
good programmers. They/we have a tendency to pick apart anything that
is said, often concentrating on the bits that are wrong, or wrong in some
situations. Therefore, don't oversimplify when speaking to programmers.

It is possible to do more damage to Erlang's reputation in 10 seconds
than it is possible to do good. You may argue that the rest of the talk
would be spent explaining the sound-bite(s) -- but why put so much
emphasis on something that may cause a bad impression, then potentially
have to spend considerable effort fixing that impression?

When explaining technical concepts to an audience most of whom are
unfamiliar with them, IMHO a slower, incremental approach is preferable.

This does not mean that short, pithy "slogans" cannot be effective, as
mnemonics for an argument. A slogan does not attempt to accurately convey
the argument by itself -- it only has to be sufficient to stand for the
argument *for someone who already understands it*, acting as a reinforcement
to their memory.

Here are two examples:

"In the future we shall know more." (Lee Smolin on quantum gravity)

"Well-typed programs do not go wrong." (Robin Milner on type theory)

In each case, you wouldn't attempt to explain the associated argument to
an unfamiliar audience by first stating the slogan. First make the argument,
including any caveats, and *then* associate it with the slogan.
--
David Hopwood <david.nospam.hopwood>
unknown
2006-08-24 07:56:52 UTC
Permalink
Please state the time in your entries


Was that in the 5 or ten second category - I guess five 'cos it took me
7 seconds to say

/Joe
-----Original Message-----
From: bryan rasmussen [mailto:rasmussen.bryan]
Sent: den 24 augusti 2006 09:53
To: Joe Armstrong (TN/EAB)
Cc: erlang-questions
Subject: Re: Learn Erlang in 5 seconds - competition - win a prize
A fault-tolerant system must work across at least two
computers, because a system on a single computer can crash.
The more computers the higher stability, as witness the
internet. Erlang is a language suited to building fault
tolerant systems.
unknown
2006-08-24 08:01:49 UTC
Permalink
Sorry, I thought we were all trying for 5 seconds. With some hedging.

Try again:

A fault-tolerant system must span at least two computers,
because a single computer can crash. More computers equals
higher stability, witness the internet. Erlang is a language
for building such systems
Post by unknown
Please state the time in your entries
Was that in the 5 or ten second category - I guess five 'cos it took me
7 seconds to say
/Joe
-----Original Message-----
From: bryan rasmussen [mailto:rasmussen.bryan]
Sent: den 24 augusti 2006 09:53
To: Joe Armstrong (TN/EAB)
Cc: erlang-questions
Subject: Re: Learn Erlang in 5 seconds - competition - win a prize
A fault-tolerant system must work across at least two
computers, because a system on a single computer can crash.
The more computers the higher stability, as witness the
internet. Erlang is a language suited to building fault
tolerant systems.
unknown
2006-08-24 08:18:28 UTC
Permalink
--- "Joe Armstrong (TN/EAB)"
Post by unknown
Hi Guys,
I have been asked to hold a talk at a Smalltalk
conference <gulp>
So I have to convince a conference room full of
Smalltalkers to become
Erlangtalkers.
As part of the lecture I have promised to hold a "5
second Erlang
course"
"Concurrency, distribution, fault-tolerance. Choose
any three." 3.9 seconds, so you have 1 second for
questions :-)

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
unknown
2006-08-24 08:41:55 UTC
Permalink
Post by unknown
--- "Joe Armstrong (TN/EAB)"
Post by unknown
Hi Guys,
I have been asked to hold a talk at a Smalltalk
conference <gulp>
So I have to convince a conference room full of
Smalltalkers to become
Erlangtalkers.
As part of the lecture I have promised to hold a "5
second Erlang
course"
"Concurrency, distribution, fault-tolerance. Choose
any three." 3.9 seconds, so you have 1 second for
questions :-)
Best,
Thomas
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
I think we have a winner :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060824/c4f6f9e4/attachment.html>
unknown
2006-08-24 10:23:31 UTC
Permalink
I could do the 10s vs in 6s - so you can add 4 secs to this :-)

/Joe
-----Original Message-----
From: Bruce Fitzsimons [mailto:Bruce]
Sent: den 24 augusti 2006 12:12
To: Joe Armstrong (TN/EAB); erlang-questions
Subject: Re: Learn Erlang in 5 seconds
5s: How would you program if processes were limitless, IPC
was trivial, and you only coded for success cases?
10s: First you bend your mind to Erlang, then you bend Erlang
to fit your problem. Your problem stays in its domain, and
you model it with concurrent processes, message passing, and
supervision trees.
unknown
2006-08-24 11:53:41 UTC
Permalink
Armstrong Corrolary on Greenspun's 10th Rule of
Programming: All sufficiently complicated distributed
systems contain ad hoc, informally-specified,
bug-ridden, slow implementation of half of Erlang -and
if they don't they are probably severely misdesigned.



___________________________________________________________
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html
unknown
2006-08-24 12:14:43 UTC
Permalink
Nice one! :))
Post by unknown
Armstrong Corrolary on Greenspun's 10th Rule of
Programming: All sufficiently complicated distributed
systems contain ad hoc, informally-specified,
bug-ridden, slow implementation of half of Erlang -and
if they don't they are probably severely misdesigned.
___________________________________________________________
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html
unknown
2006-08-24 14:53:05 UTC
Permalink
I vote for this one. But s/half/quarter/.

-----Original Message-----
From: owner-erlang-questions
[mailto:owner-erlang-questions] On Behalf Of Ewan Higgs
Sent: Thursday, August 24, 2006 6:54 AM
To: Joe Armstrong (TN/EAB); erlang-questions
Subject: Re: Learn Erlang in 5 seconds - competition - win a prize

Armstrong Corrolary on Greenspun's 10th Rule of
Programming: All sufficiently complicated distributed
systems contain ad hoc, informally-specified,
bug-ridden, slow implementation of half of Erlang -and
if they don't they are probably severely misdesigned.



___________________________________________________________
Copy addresses and emails from any email account to Yahoo! Mail - quick,
easy and free. http://uk.docs.yahoo.com/trueswitch2.html
unknown
2006-08-24 18:18:09 UTC
Permalink
Can't help falling "outside the box" (seeing a picture, instead of words),
but - how about modified version of "Game Of Life" where:
- the first life-form is programmed using erlang(-principles)
- the second not...
Then watch all non-erlang life-forms die away while you (concurrently)
tell the audience what is going on.

On Thu, 24 Aug 2006 16:53:05 +0200, Logan, Martin
Post by unknown
I vote for this one. But s/half/quarter/.
-----Original Message-----
From: owner-erlang-questions
[mailto:owner-erlang-questions] On Behalf Of Ewan Higgs
Sent: Thursday, August 24, 2006 6:54 AM
To: Joe Armstrong (TN/EAB); erlang-questions
Subject: Re: Learn Erlang in 5 seconds - competition - win a prize
Armstrong Corrolary on Greenspun's 10th Rule of
Programming: All sufficiently complicated distributed
systems contain ad hoc, informally-specified,
bug-ridden, slow implementation of half of Erlang -and
if they don't they are probably severely misdesigned.
___________________________________________________________
Copy addresses and emails from any email account to Yahoo! Mail - quick,
easy and free. http://uk.docs.yahoo.com/trueswitch2.html
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
unknown
2006-08-24 16:41:33 UTC
Permalink
I enter this for the 5 second course (provided you don't speak too fast):

When there is more than one parallel concept in the problem or solution,
Erlang will be your saviour. It reacts predictably yet is closest thing to
executing native thought.

Marthin
-----Original Message-----
From: owner-erlang-questions [mailto:owner-erlang-
questions] On Behalf Of Joe Armstrong (TN/EAB)
Sent: 24 August 2006 09:57
To: bryan rasmussen
Cc: erlang-questions
Subject: RE: Learn Erlang in 5 seconds - competition - win a prize
Please state the time in your entries
Was that in the 5 or ten second category - I guess five 'cos it took me
7 seconds to say
/Joe
-----Original Message-----
From: bryan rasmussen [mailto:rasmussen.bryan]
Sent: den 24 augusti 2006 09:53
To: Joe Armstrong (TN/EAB)
Cc: erlang-questions
Subject: Re: Learn Erlang in 5 seconds - competition - win a prize
A fault-tolerant system must work across at least two
computers, because a system on a single computer can crash.
The more computers the higher stability, as witness the
internet. Erlang is a language suited to building fault
tolerant systems.
unknown
2006-08-24 19:53:12 UTC
Permalink
Post by unknown
As part of the lecture I have promised to hold a "5 second Erlang
course"
I need help and suggestions in preparing this course.
My proposal is a 5-seconds recursive definition of Erlang/OTP:

_E_rlang is
_R_oughly a
_L_anguage for
_A_musing
_N_etworked
_G_ames and
_/_ or
_O_rdinary
_T_wisted
_P_rogramming

HND

Enzo
--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
unknown
2006-08-24 21:59:39 UTC
Permalink
-----Original Message-----
From: owner-erlang-questions
[mailto:owner-erlang-questions] On Behalf Of Bruce Fitzsimons
Sent: Thursday, August 24, 2006 5:12 AM
To: Joe Armstrong (TN/EAB); erlang-questions
Subject: Re: Learn Erlang in 5 seconds

5s: How would you program if processes were limitless, IPC was trivial,
and you only coded for success cases?

That is brilliant.

10s: First you bend your mind to Erlang, then you bend Erlang to fit
your problem. Your problem stays in its domain, and you model it with
concurrent processes, message passing, and supervision trees.
unknown
2006-08-25 01:47:57 UTC
Permalink
"Joe Armstrong \(TN/EAB\)" <joe.armstrong> wrote:
(1) I have been asked to hold a talk at a Smalltalk conference <gulp>
(2) As part of the lecture I have promised to hold a "5 second Erlang course"
(3) < the 10 second category is wide open >

Since these are Smalltalk people, start with what you *agree* about:

Like Smalltalk, Erlang is an open dynamic language with a Lisp heritage.
Smalltalk makes data structure design easy; Erlang was invented to make
massively concurrent distributed process design easy. Erlang processes
have identity, state, and behaviour, and interact by sending messages;
if you know the history of Smalltalk this is deja vu all over again
except that Erlang prevents many concurrency problems by having read-only
data, so that classes would be less useful.

That should be about 10 seconds.
unknown
2006-08-25 02:19:48 UTC
Permalink
Serge Aleynikov <serge> wrote:
"What if you were to write a system that was OS-agnostic, would easily
scale to 100,000s of processes, would run on a cluster of machines,
would offer nine nines of uptime, and would have to be built in a week?
... Sounds impossible with Smalltalk? ... Add Erlang to your arsenal
and see for yourself!"

Actually, no, it DOESN'T sound impossible with Smalltalk.
Erlang is available for Windows, Solaris, Linux, MacOS X, and some others.
Squeak Smalltalk is available for Windows, Solaris, Linux, MacOS X, and
some others. So "OS-agnostic" is easy. Scale to 100,000s of processes?
Well, it took me 0.6 seconds to create 10,000 processes on a 1GHz PowerMac.
That gave me courage to try forking 200,000 processes, and that just took
9.3 seconds. Mind you, they didn't _do_ anything much... For IPC, Squeak
has semaphores (inherited from ST-80) and message queues. Run on a cluster
of machines? Squeak has serialised streams (SmartRefStream), so sending
graphs of objects from one machine to another is dead simple, and it certainly
has cross-platform support for sockets. In fact, when you open a file
browser, the root is *under* the root of your local file system; FTP is just
there. Squeak has its own web browser and mail user agent and web server
(in fact more than one). It *is* being used to develop distributed stuff.
Built in a week? Depends on how much of OTP would need reinventing, but
there doesn't seem to be any reason why it couldn't be done; the IDE in
Squeak is really rather pleasant (and there's the refactoring browser).
Someone already skilled in Smalltalk would likely take far less time to
finish such a system in Squeak than in Erlang.

Nine nines of uptime? That's 3 MILLISECONDS of downtime in a year, no?
Sorry, for something built in a week I just don't believe it. I believe
it a little bit more for Erlang than I do for Smalltalk, just like I have
a little bit more belief in mermaids than in vampires.

It is *never* a good idea to insult your audience.
As Anatol Rapoport (sp?) pointed out in a great book once,
in any kind of real-world debate it's a good move to start
by explaining why your rival is RIGHT about so many things
and is reasonably concerned about so many issues.

If you tell a Smalltalk audience that they can't develop distributed
concurrent systems in Smalltalk they will write you down as an arrogant
idiot who knows nothing about Smalltalk, and won't hear anything else you
say no matter how good it is.

If you tell them that Smalltalk is great and that Erlang is great too
and part of this is their common heritage, they will start listening.
If you praise Smalltalk development environments and say that Erlang
has learned from Smalltalk (ErlIde + unit testing framework) and has
more things to learn from Smalltalk (refactoring browser) they will start
to get warm fuzzy feelings about you (this guy has taken the trouble to
learn something about us, he's worth listening to).

You should certainly admit that while Erlang has a GUI kit (in fact more
than one), it's not a strength of the language, and that connecting a
Smalltalk GUI with an Erlang system might be a good way to proceed.
(Alas, _each_ Smalltalk has its _own_ incompatible GUI kit; Squeak even
manages to have two of them.)

THEN you can say that while Smalltalk has always HAD concurrency it has
never been a PRIMARY focus of the language, while Erlang has had
concurrency has its primary focus from day 1. Some of the differences
between Smalltalk and Erlang, like syntax, are just accidents of history.
Other differences (objects -vs- immutable data) are due to this
fundamental difference of emphasis.
unknown
2006-08-25 14:53:41 UTC
Permalink
Post by unknown
"What if you were to write a system that was OS-agnostic, would easily
scale to 100,000s of processes, would run on a cluster of machines,
would offer nine nines of uptime, and would have to be built in a week?
... Sounds impossible with Smalltalk? ... Add Erlang to your arsenal
and see for yourself!"
Actually, no, it DOESN'T sound impossible with Smalltalk.
[...]

Every language certainly has merits, otherwise why would it be designed
in the first place?

An important distinction of Erlang aside from built-in concurrency
support is that its OTP framework allows to build systems/products
rather than collections of stand-along applications.

What do I mean by that?

Recovery from faults, health monitoring, centralized error reporting,
SNMP support with ease of agent extensibility, release handling with
automatic system upgrades, application and release versioning, systemic
use of design patterns or templates that allow development teams to use
the same coding style, and preserve structure of applications therefore
simplifying support of derived products.

Can you do this in other languages? Certainly, if you tackle these
problems individually! Yet /IMHO/ the designers of most languages only
take it to the point of providing developers with a compiler, a VM (if
required by the language), debugging tools, perhaps some IDE, some basic
libraries, and leave it up to the developer to use this in order to
develop products. So the next step that happens is that many developers
use these tools to put together some useful components in a non-systemic
manner. This makes it expensive for companies to use such a language
and libraries for building products, because they have to incur the cost
of assembling pieces together, ensure there exists adequate support for
each 3rd party component, and deal with coding style and other
differences. All of this makes products expensive to develop and maintain.

Frankly, if Erlang didn't come with the OTP, I don't think we would use
it in our work.
Post by unknown
Nine nines of uptime? That's 3 MILLISECONDS of downtime in a year, no?
(86400 s/day * 365 days) * 10^-9 =~= 0.032 s
Post by unknown
Sorry, for something built in a week I just don't believe it. I believe
it a little bit more for Erlang than I do for Smalltalk, just like I have
a little bit more belief in mermaids than in vampires.
If we are using the same terms, availability is:

MTBF
A = -----------
MTBF + MTTR

Where:
MTBF - Mean time between failure
MTTR - Mean time to repair


Combined availability of N parallel components would be:

Ac = 1 - (1 - Ai)^N

Let's assume that we have a distributed redundant system composed of
three server nodes running on separate hosts. Using the formula above,
each node must provide 0.999 of uptime, or roughly 9 hours of downtime
per year.

I also don't believe in mermaids and vampires, but having deployed such
systems built with Erlang/OTP in a production telecom network, these
numbers don't sound unreasonable.

Well, I should've probably noted something about hardware abstraction.
Building reliable systems that rely on unreliable networks is quite a
big challenge on its own, and Erlang/OTP doesn't help in this area
without additional effort needed to solidify the network architecture,
and implement algorithms that deal with detection and recovery from
network partitioning.

However, given a reliable network putting together a proof-of-concept
simple redundant application with the traits above within a week is
certainly not a unreasonable task for a developer with a good knowledge
of the OTP and building distributed applications.
Post by unknown
It is *never* a good idea to insult your audience.
[...]
Post by unknown
If you tell a Smalltalk audience that they can't develop distributed
concurrent systems in Smalltalk they will write you down as an arrogant
idiot who knows nothing about Smalltalk, and won't hear anything else you
say no matter how good it is.
Granted that for the word 'impossible' may sound offensive to someone,
the "Sounds impossible with Smalltalk?" sentence can be taken out
safely, shortening the 10s phrase, while still preserving the urge to
explore Erlang. ;-)

Regards,

Serge
unknown
2006-08-28 01:51:52 UTC
Permalink
I think
Serge Aleynikov <serge>
misunderstood where I am coming from.
Post by unknown
Actually, no, it DOESN'T sound impossible with Smalltalk.
I then provided illustrative detail about why it wouldn't even be
particularly hard in the modern Smalltalk I know best.

Every language certainly has merits, otherwise why would it be designed
in the first place?

The point is not that Smalltalk has SOME merits,
but that a decent modern Smalltalk has many of the RIGHT merits to be not
altogether unreasonable for this kind of application.
The central weakness in Smalltalk is the absence of any kind of
encapsulation between processes. Of course, Smalltalk processes don't
*have* to trample on each other's data structures to get work done, it's
just that it's extremely difficult to be sure that they don't do this
accidentally. Good discipline and tools could help. More importantly,
there is no obvious reason why you couldn't have a Smalltalk system
where everything was exactly the way it is now EXCEPT that processes
DIDN'T have write access to each other's data. (In fact, if I ever get
my Smalltalk compiler finished, that's exactly how I intend to do it.)

If you took Smalltalk, encapsulated process's data from each other,
and added !, you'd have something that would basically BE Erlang with
funny syntax minus pattern matching plus mutable private data (and with
the process dictionary, Erlang already has a form of mutable private
data) plus classes.

I suggest that while cheap processes are very nice to have,
it's process ENCAPSULATION which matters most for Erlang,
because that makes processes easy to THINK about and makes a whole
lot of nasty concurrency bugs impossible.

Process encapsulation also happens to be the thing that makes Erlang
distribution pleasant, because once you can't muck around with another
process's data you stop caring so much which machine it keeps those data on.

An important distinction of Erlang aside from built-in concurrency
support is that its OTP framework allows to build systems/products
rather than collections of stand-alone applications.

Yes, agreed. But a modern Smalltalk is also more than just a language;
a modern Smalltalk *also* has a framework, and thanks to the Web, that
framework includes support for TCP/IP, HTTP, FTP, XML, hot loading, &c.

To be sure, Squeak doesn't have ASN.1 support, but there was a time when
Erlang didn't either, and it wouldn't be particularly hard to add it.
As for application and release versioning, it took years and years of
arguing and experimentation, but eventually something very like that did
go in.

The really really fundamental difference between Erlang and (present)
Smalltalk is that Erlang processes have idiot-proof encapsulated data
and Smalltalk processes don't.
Post by unknown
Nine nines of uptime? That's 3 MILLISECONDS of downtime in a year, no?
(86400 s/day * 365 days) * 10^-9 =~= 0.032 s

Sorry, slipped a decimal point there. 31.6 milliseconds.

I wrote
vvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Post by unknown
Sorry, for something built in a week I just don't believe it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If we are using the same terms, availability is
[snipped because irrelevant]

I also don't believe in mermaids and vampires, but having deployed such
systems built with Erlang/OTP in a production telecom network, these
numbers don't sound unreasonable.

I also can easily believe that a system with that level of reliability
(assuming, which I'm not altogether happy about assuming, that failures
are independent; common causes tend to produce common failures) can be
built with Erlang/OTP.

What I *can't* swallow is that a nontrivial system can be built to that
level of reliability in *any* language in just one week. For a non-trivial
system, it's going to take you at least a week just to understand the
requirements. It's also going to take a fair while to run adequate tests.

However, given a reliable network putting together a proof-of-concept
vvvvvvvvvvvvvvvv
simple redundant application with the traits above within a week is
^^^^^^^^^^^^^^^^
certainly not a unreasonable task for a developer with a good knowledge
of the OTP and building distributed applications.

But that isn't the kind of application we were talking about, far from it.

Heck, I could put together a proof-of-concept simple redundant application
with the traits above in a week using Oz/Mozart (once I've spent the
necessary couple of weeks reading the Mozart reference manuals; it's
already taken me a week to not quite finish the tutorials). I wouldn't
dream of suggesting that that said anything significant about the
usefulness of Oz/Mozart for a full-blown system.

Continue reading on narkive:
Loading...