Erlang killer app?,

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

isaac gouy-2
Ulf Wiger wrote:
>ideal for the flexible and robust messaging
>backbones we wanted to build

Alex Peake wrote:
>warehouse application is old and the whole system
>about to be re-written

Ulf, given the Erlang community has a depth of
experience outside of telecomm, perhaps the advantages
of Erlang aren't well known outside of the telecomm
community? They aren't well known by people building
systems which require similar qualities?

Alex, which bits do you imagine would really use
Erlangs strengths, which bits would need to be
implemented in something else? How did you hear about
Erlang?

>Erlang offers huge productivity gains
Hmm. I had a big surprise going from Smalltalk to
Java. We knew that Smalltalk was x10 more productive
than C++ but thought Smalltalk would only be x2 better
than Java. It's amazing how much static typing and an
excess of syntax slow you down ;-)

So-many Smalltalk systems have been re-written in
Java, at great cost and reduction of functionality.

IMHO mostly it doesn't matter that Smalltalk is hugely
more productive, or that Erlang is hugely more
productive. It matters that they have name recognition
as the best solution for a particular class of
problems.

(And that's why I've been asking about the core
strengths of Erlang/OTP, and how they can be applied
outside of Telecomm)

best wishes, Isaac


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Francesco Mazzoli-2
To give my two pennies to the discussion. Telecom systems'
characteristics include:

* Distribution
* Fault Tolerance
* Massive Concurrency
* Soft Real Time
* Non Stop (For Upgrades / Patch Installation / Crashes)

Those are the characteristics Erlang has inherited, and thus, it is
suitable to solve most problems in domains exhibiting those
characteristics.

When bluetail released its first product, Erlang certainly did not have
name recognition for the domain of problems it was solving. They were
first out using it in a suitable domain, and cashed in on it. Many other
start ups are now doing the same, but in other areas.

In my 9 years of working with Erlang, I have seen it used with great
success in simulations, computer telephony integration, products for
ISPs, games, 3d modellers, distributed database applications, all
without any recognition in those area, as it was a language only used
for embedded telecom control systems. What these non telecom application
developers were able to do, however, was use the 5 - 10 fold increase in
productivity to improve their time to market and at the same time easily
integrating characteristics such as code upgrade and salability during
runtime, high availability which were previously unheard of or hard to
solve in those domains.

One of the great strengths of the language is the ability to quickly put
together a working prototype. If you are looking at using Erlang in a
new domain (e-commerce systems sound exciting) but are unsure, test your
ideas. Design errors, limitations, and flaws should show up at an early
stage of the development when it is still possible to stop and reverse
the baby elephant... If your hunch is right, you will have a working
prototype to show and convince higher management. This strategy has been
used time after time when Erlang was competing against hundreds of
documents describing how the problem could be solved using other hyped
technology.

Regards,
Francesco
--
http://www.erlang-consulting.com



isaac gouy wrote:

>Ulf Wiger wrote:
>
>>ideal for the flexible and robust messaging
>>backbones we wanted to build
>>
>
>Alex Peake wrote:
>
>>warehouse application is old and the whole system
>>about to be re-written
>>
>
>Ulf, given the Erlang community has a depth of
>experience outside of telecomm, perhaps the advantages
>of Erlang aren't well known outside of the telecomm
>community? They aren't well known by people building
>systems which require similar qualities?
>
>Alex, which bits do you imagine would really use
>Erlangs strengths, which bits would need to be
>implemented in something else? How did you hear about
>Erlang?
>
>>Erlang offers huge productivity gains
>>
>Hmm. I had a big surprise going from Smalltalk to
>Java. We knew that Smalltalk was x10 more productive
>than C++ but thought Smalltalk would only be x2 better
>than Java. It's amazing how much static typing and an
>excess of syntax slow you down ;-)
>
>So-many Smalltalk systems have been re-written in
>Java, at great cost and reduction of functionality.
>
>IMHO mostly it doesn't matter that Smalltalk is hugely
>more productive, or that Erlang is hugely more
>productive. It matters that they have name recognition
>as the best solution for a particular class of
>problems.
>
>(And that's why I've been asking about the core
>strengths of Erlang/OTP, and how they can be applied
>outside of Telecomm)
>
>best wishes, Isaac
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Health - Feel better, live better
>http://health.yahoo.com
>
>




Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Alex Peake
In reply to this post by isaac gouy-2
Isaac wrote:
> Alex, which bits do you imagine would really use
> Erlangs strengths, which bits would need to be
> implemented in something else? How did you hear about
> Erlang?
>
>

I have been on a search for "a better way" to write software for several years. I discovered the
"functional" style about two years ago and started with Common Lisp, then Scheme and wrote some
interesting stuff in (PLT) Scheme and (Franz) Common Lisp realizing significant productivity gains.
I also looked into Haskell (and Clean) and SML (and Miranda) and CAML.

Of all of these only Franz Common Lisp has a broad enough set of capabilities for my world (see
previous message on this thread), but it is outrageously expensive! ($6000 per seat for development
and $20,000 per server for deployment of the app!)

PLT Scheme comes close, but "academic, as time permits" support is not a good bet for the commercial
systems I write.

"Libraries" for the ML languages are sparse (as relates to my world). Though interestingly things
are starting to happen with .NET (which opens up huge libraries). There are now an early versions of
SML.NET and also CAML.Net (called F#).

I found Erlang just a few months ago as I continued to search. It is "fairly" complete for what I
want and commercial enough (but I am still very much novice in Erlang).

I like the Erlang language (functional, pattern matching, ...) and the natural distributed nature of
it. I have re-written my Lisp/Scheme pattern generators in Erlang and they are more elegant now.

Erlang can connect to RDBMSs (only ODBC, but I can live with that) and that is essential in my work.

A Web Server (yaws?) as distributed application server is important building scalable applications
as well as for Web Services (SOAP/XML), and of course as web server for browser based UI. I have not
discovered the level of support for generating HTML, dealing with XML (and SOAP) yet.

>From what I have seen so far, the UI creation part is sadly lacking in Erlang. I just mentioned HTML
for browsers, and for "thick" clients (for a more interesting and productive UI) it appears that
tcl/tk is the answer. My first experiments there had the first window take 12 seconds to open (using
an example from the docs)! And I cannot see how to work with "interesting" UI widgets - grids like
ComponentOne and Infragistics. It would be fine if interop were "easy" with (perhaps) .NET? (or
Java?) for the UI part. Web Services might solve that -- I write the UI in C# or Java -- that would
be good?

I am not sure if it is going to be difficult in Erlang (without (.NET, Java) interop), but I need
"Message Queuing" (the reliable, transactional delivery of arbitrary messages over a network, with
alternate routing in case of failure). MQ does exist in COM and that is supported by Erlang (I
read).

I ramble, sorry.

Alex





Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

isaac gouy-2
Thank you all for educating me on the things you've
been doing with Erlang. (And for putting up with the
messed up subject line!)

I have a humble and unoriginal suggestion.
Maybe there are projects that you've done which you
could write articles about and educate some more
people about through the computer "comics"?
("Comics"? - everything from Java Report to InfoWeek)

Java Report! Maybe there's an article about
interfacing Java UI with a complex Erlang/OTP system?

Python Journal! ditto

Linux world / Unix world? Maybe they'd be interested
in the yaws/unix clever stuff discussed in Per
Bergqvist's and Klacke's postings?

Of course, the humble suggestion is more Erlang/OTP
advocacy! My apologies to those of you who must have
worked very hard, as strong advocates for Erlang
during the last 10 years. I can just about imagine
what it's taken to get Erlang/OTP to where it is
today.

I asked the OpenNMS guys why they chose to develop in
Java. They didn't have much experience of Java when
they started but from their C++ perspective "It seemed
the right tool for the job of writing something easily
portable with a rapid development time."
"> Has anyone on the OpenNMS team heard of Erlang?
Heard of, yes.  Looked at, not really...
> Was it ever considered as an implementation choice?
I doubt it"

I don't know enough about Erlang/OTP to be sure - but
I would guess that (apart from the UI) Erlang/OTP
would have been ideal for what these guys are doing.
But they didn't know that...

thanks again, Isaac








__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Thierry Mallard-2
On Sat, Jul 20, 2002 at 05:33:46PM -0700, isaac gouy wrote:

> [ Choosing a language ]
> I asked the OpenNMS guys why they chose to develop in
> Java. They didn't have much experience of Java when
> they started but from their C++ perspective "It seemed
> the right tool for the job of writing something easily
> portable with a rapid development time."
> "> Has anyone on the OpenNMS team heard of Erlang?
> Heard of, yes.  Looked at, not really...
> > Was it ever considered as an implementation choice?
> I doubt it"

In my humble opinion, this is a common pattern : often, specially when
it's a "hobby project", the developers thinks first "ok, I like
this language and I want to code with it. Now, what can I do... ? "
and not : "Ok, there's problem here that needs to be solved. What would
be the betters tools (language among others) to solve it ? "

For example -and only an example- I wondered recently why Zope was
written in Python. The answer Jim Fulton gave in an interview was
" I was a convert to Python by that time. ;) "


Best regards,

--
Thierry Mallard
http://vawis.net


Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Shawn Pearce
Isn't this kind of what this thread is about currently?
``I like Erlang, so what can we make in it?''

I agree however, that its very, very common for developers
to pick up langauges such as Java, but shun something such
as Erlang, just because of the sheer hype, marketing, and
influence of coworkers.  Then they come with an idea and
create a software package in it, even if that means
lots of work because of the wrong language selection.

I myself shuned using Ruby for a project that others who
know it have said it would have been good at.  Instead
I have a 65,000+ line C++ monster I'd prefer not to touch.
I also know I was tempted to port it to Erlang, just because
I knew the language and thought it would be `cool'.

I've also used Tcl and Java for a project that I think
would be much better suited to Erlang, except:

        1) I don't know the state of SAE on Windows.  Tcl
                can be built to a stand alone Windows .exe,
                perfect for my application.  No DLLs are required.

        2) Erlang doesn't have XSLT and FOP->PDF available.
                (But JInterface would work well enough here with
                 only minimal Java code that I could use the
                 Java based processors.)

        3) Programming web interfaces in Erlang still isn't
                a strong suite of mine, despite that I do it
                in nearly every other language.  Perhaps its
                because I still think yaws,inets,etc are weaker
                than the other offerings... not that I really
                like Java servlets and JSP that much.

        4) My coworkers don't know Erlang and don't want to
                bother with the "chore" of learning a language
                other than the One-True-Language-Called-Java(tm).
                Its just too much of an inconvience for them.  Too
                much effort, too much thinking and studying required.

Conversely, I chose C/Erlang for my video application,
only because its very similiar to what the telecomm guys
do with Erlang.  Much of the "routing" and "control" is
done in Erlang, with the device specific bindings and
speed critical sections in C.  Erlang made perfect sense
to use, as it had an integrated database, code reloading,
distributed messaging, which were all critical as I am
attempting to create a multiple computer solution.

I think Erlang's biggest strength is really the points
mentioned earlier in this thread about fault tolerance,
distribution, etc, but also how well it coordinates
and integrates with other systems.

Just how "easy" is it to hook Java to C or C++?  What
about making Java act as an NFS server to communicate
with Unix clients?

Erlang people do this all of the time, because its so
easy.  And because its so easy, we try not to reinvent
the wheel (when possible), unlike our Java, Perl and
Python friends.

I think its because:

        Erlang is concurrent, and with message passing
        so central to its design, that it is very trival
        to declare some unknown black box as 'another
        concurrent process, handling messages'.  This
        fits perfectly into the environment, and the
        environment fits perfectly to it.


Thierry Mallard <thierry> scrawled:

> On Sat, Jul 20, 2002 at 05:33:46PM -0700, isaac gouy wrote:
> > [ Choosing a language ]
> > I asked the OpenNMS guys why they chose to develop in
> > Java. They didn't have much experience of Java when
> > they started but from their C++ perspective "It seemed
> > the right tool for the job of writing something easily
> > portable with a rapid development time."
> > "> Has anyone on the OpenNMS team heard of Erlang?
> > Heard of, yes.  Looked at, not really...
> > > Was it ever considered as an implementation choice?
> > I doubt it"
>
> In my humble opinion, this is a common pattern : often, specially when
> it's a "hobby project", the developers thinks first "ok, I like
> this language and I want to code with it. Now, what can I do... ? "
> and not : "Ok, there's problem here that needs to be solved. What would
> be the betters tools (language among others) to solve it ? "
>
> For example -and only an example- I wondered recently why Zope was
> written in Python. The answer Jim Fulton gave in an interview was
> " I was a convert to Python by that time. ;) "

--
Shawn.

Why do I like Perl?  Because ``in accordance with Unix tradition Perl
gives you enough rope to hang yourself with.''

Why do I dislike Java? Because ``the class ROPE that should contain the
method HANG to do the hanging doesn't exist because there is too much
'security' built into the base language.''


Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Joe Williams-2
On Sun, 21 Jul 2002, Shawn Pearce wrote:

> Isn't this kind of what this thread is about currently?
> ``I like Erlang, so what can we make in it?''
>
> I agree however, that its very, very common for developers
> to pick up langauges such as Java, but shun something such
> as Erlang, just because of the sheer hype, marketing, and
> influence of coworkers.  Then they come with an idea and
> create a software package in it, even if that means
> lots of work because of the wrong language selection.
>
> I myself shuned using Ruby for a project that others who
> know it have said it would have been good at.  Instead
> I have a 65,000+ line C++ monster I'd prefer not to touch.
> I also know I was tempted to port it to Erlang, just because
> I knew the language and thought it would be `cool'.
>
> I've also used Tcl and Java for a project that I think
> would be much better suited to Erlang, except:
>
> 1) I don't know the state of SAE on Windows.  Tcl
> can be built to a stand alone Windows .exe,
> perfect for my application.  No DLLs are required.
>

  This  is  in  the  (near)  pipeline  :-) You  *will*  need  one  DLL
(erlang.dll) thereafter you will be  able to pack all application code
into a single .exe file (or use shared libraries). You'll also be able to make
windows .exe files inside Linux and build linux executables from windows.
 
> 2) Erlang doesn't have XSLT and FOP->PDF available.
> (But JInterface would work well enough here with
> only minimal Java code that I could use the
> Java based processors.)
>

 ?? - I don't understand - do you meant you'd like an implementation of
XSLT in Erlang???? Also, are their any good (free) FOP->PDF convertors?



> 3) Programming web interfaces in Erlang still isn't
> a strong suite of mine, despite that I do it
> in nearly every other language.  Perhaps its
> because I still think yaws,inets,etc are weaker
> than the other offerings... not that I really
> like Java servlets and JSP that much.

 I disagee - Erlang programs are a lot shorter than the equivalent Java
stuff so the embedded code is much shorter and easier to write and maintain.

  I  think I  mentioned erarier  that we  were going  to  benchmark an
yaws against Apache under condition of medium to high overload.

  We have some *very*?preliminary figures.

  At low load yaws and Apache have very similar performance.

  At 100% overload yaws is about 4 - 7 times faster than Apache.

  At 1000% overload yaws is about 4 times better than Apache.

  In other words if your web site has nasty peaks when suddenly everybody
wants to access it Apache almost falls over, yews ticks along nicely.
Even at 1000% overload yaws was servicing all requests (albeit slowly)
but Apache was rejecting 40% of all traffic.

  Also  bear in  mind  Klackes  figures -  yaws  was generating  2,000
dynamic pages/sec - a high performance PHP will manage a few hundred.

  So we have:

        1) shorter code
        2) better performance under heavy overload
        3) very fast dynamic page generation

  That's why you will like it :-)


>
> 4) My coworkers don't know Erlang and don't want to
> bother with the "chore" of learning a language
> other than the One-True-Language-Called-Java(tm).
> Its just too much of an inconvience for them.  Too
> much effort, too much thinking and studying required.
>

  If you can learn Java you  can learn anything - Java is ridicolously
complicated. If you're going argue that "lazyness rules" then take the
easy way out and program in  Erlang - believe me much less thinking is
involved programming in Erlang than programming in Java.

> Conversely, I chose C/Erlang for my video application,
> only because its very similiar to what the telecomm guys
> do with Erlang.  Much of the "routing" and "control" is
> done in Erlang, with the device specific bindings and
> speed critical sections in C.  Erlang made perfect sense
> to use, as it had an integrated database, code reloading,
> distributed messaging, which were all critical as I am
> attempting to create a multiple computer solution.
>
> I think Erlang's biggest strength is really the points
> mentioned earlier in this thread about fault tolerance,
> distribution, etc, but also how well it coordinates
> and integrates with other systems.
>
> Just how "easy" is it to hook Java to C or C++?  What
> about making Java act as an NFS server to communicate
> with Unix clients?
>
> Erlang people do this all of the time, because its so
> easy.  And because its so easy, we try not to reinvent
> the wheel (when possible), unlike our Java, Perl and
> Python friends.
>
> I think its because:
>
> Erlang is concurrent, and with message passing
> so central to its design, that it is very trival
> to declare some unknown black box as 'another
> concurrent process, handling messages'.  This
> fits perfectly into the environment, and the
> environment fits perfectly to it.
>
>
> Thierry Mallard <thierry> scrawled:
> > On Sat, Jul 20, 2002 at 05:33:46PM -0700, isaac gouy wrote:
> > > [ Choosing a language ]
> > > I asked the OpenNMS guys why they chose to develop in
> > > Java. They didn't have much experience of Java when
> > > they started but from their C++ perspective "It seemed
> > > the right tool for the job of writing something easily
> > > portable with a rapid development time."
> > > "> Has anyone on the OpenNMS team heard of Erlang?
> > > Heard of, yes.  Looked at, not really...
> > > > Was it ever considered as an implementation choice?
> > > I doubt it"
> >
> > In my humble opinion, this is a common pattern : often, specially when
> > it's a "hobby project", the developers thinks first "ok, I like
> > this language and I want to code with it. Now, what can I do... ? "
> > and not : "Ok, there's problem here that needs to be solved. What would
> > be the betters tools (language among others) to solve it ? "
> >
> > For example -and only an example- I wondered recently why Zope was
> > written in Python. The answer Jim Fulton gave in an interview was
> > " I was a convert to Python by that time. ;) "
>
> --
> Shawn.
>
> Why do I like Perl?  Because ``in accordance with Unix tradition Perl
> gives you enough rope to hang yourself with.''
>
> Why do I dislike Java? Because ``the class ROPE that should contain the
> method HANG to do the hanging doesn't exist because there is too much
> 'security' built into the base language.''
>


Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Shawn Pearce
Joe Armstrong <joe> scrawled:

> On Sun, 21 Jul 2002, Shawn Pearce wrote:
> > 1) I don't know the state of SAE on Windows.  Tcl
> > can be built to a stand alone Windows .exe,
> > perfect for my application.  No DLLs are required.
> >
>
>   This  is  in  the  (near)  pipeline  :-) You  *will*  need  one  DLL
> (erlang.dll) thereafter you will be  able to pack all application code
> into a single .exe file (or use shared libraries). You'll also be able to make
> windows .exe files inside Linux and build linux executables from windows.

Good to hear!  Lets see if I can talk my boss into it.

* checks *

Nope.

I think SAE is a good thing.  ;-)  Even if I can't use it at work.

> > 2) Erlang doesn't have XSLT and FOP->PDF available.
> > (But JInterface would work well enough here with
> > only minimal Java code that I could use the
> > Java based processors.)
> >
>
>  ?? - I don't understand - do you meant you'd like an implementation of
> XSLT in Erlang???? Also, are their any good (free) FOP->PDF convertors?

No, I don't think an implementation of XSLT is the issue.  I was simply
stating that since it doesn't have one, I'd have to use another one
externally.  But JInterface is pretty solid at communiating back and
forth, making it relatively trivial.  An Erlang based XSLT would be cool,
but I think its one of those things that right now nobody really has a
big desire for, so its not worth expending resources into.

Would I find use for an Erlang based XSLT if we had one?  Maybe.  Do I
have that many uses for the existing Java based ones?  Nope.  C++?  Nope.

The Apache Jakarta Project has a tool available called FOP to translate
XSL:FO (which is what I meant to say) to PDF.  Does a pretty slick job too.
Some XSL:FO features are not yet supported. but version 0.23 is pretty stable.
I've got an internal tool at work based entirely around XSLT->XSLT->XSL:FO->PDF.

So even if we had XSLT in Erlang, I'd still be doing the last pass in Java.

> > 3) Programming web interfaces in Erlang still isn't
> > a strong suite of mine, despite that I do it
> > in nearly every other language.  Perhaps its
> > because I still think yaws,inets,etc are weaker
> > than the other offerings... not that I really
> > like Java servlets and JSP that much.
>
>  I disagee - Erlang programs are a lot shorter than the equivalent Java
> stuff so the embedded code is much shorter and easier to write and maintain.

Excellent point.  I didn't think of it that way.  I was thinking about the fact
that I'm not a big fan of embedding code within the HTML.  Haven't been since
we were using the latest and greatest Pentium 90 to serve up web pages in Perl and
used Berkely db as our database.

>   I  think I  mentioned erarier  that we  were going  to  benchmark an
> yaws against Apache under condition of medium to high overload.
>
>   We have some *very*?preliminary figures.
>
>   At low load yaws and Apache have very similar performance.
>
>   At 100% overload yaws is about 4 - 7 times faster than Apache.
>
>   At 1000% overload yaws is about 4 times better than Apache.
>
>   In other words if your web site has nasty peaks when suddenly everybody
> wants to access it Apache almost falls over, yews ticks along nicely.
> Even at 1000% overload yaws was servicing all requests (albeit slowly)
> but Apache was rejecting 40% of all traffic.
>
>   Also  bear in  mind  Klackes  figures -  yaws  was generating  2,000
> dynamic pages/sec - a high performance PHP will manage a few hundred.
>
>   So we have:
>
> 1) shorter code
> 2) better performance under heavy overload
>         3) very fast dynamic page generation
>
>   That's why you will like it :-)

And that's why I'm wondering how much better the Apache Servlet container
might run when stuck behind a yaws like server rather than the real Apache
HTTPd.  We build Java servlet applications at work, and our customers deploy
in Apache Tomcat.  We've got a major telcom equipment vendor who is having
lots of trouble with the front end Apache web server we're using when its
under high load (about 100 concurrent connections, 26 views/sec).  Apache
itself is falling apart, but the Tomcat's seem fine.

I'm quite tempted to write a plugin for yaws (or just plain hack yaws) to
create a proof of concept of this.  Problem is, my boss won't approve my
expending time/resources on anything isoteric like Tcl, Erlang, etc.  (He
just pulled the plug today on a Tcl/Tk GUI we were building, opting instead
for it to be done in Java/JSP, for no reason other than that its JSP.)

*sigh*

> > 4) My coworkers don't know Erlang and don't want to
> > bother with the "chore" of learning a language
> > other than the One-True-Language-Called-Java(tm).
> > Its just too much of an inconvience for them.  Too
> > much effort, too much thinking and studying required.
>
>   If you can learn Java you  can learn anything - Java is ridicolously
> complicated. If you're going argue that "lazyness rules" then take the
> easy way out and program in  Erlang - believe me much less thinking is
> involved programming in Erlang than programming in Java.

This I have to agree whole heartedly with.  Unfortunately, I work for
an organization that only jumps on the bandwagon that Sun and Microsoft
are on.  Any other isn't a valid bandwagon, and there are no other
technologies available for use.  Since Tcl isn't a big Sun technology,
at least not like Java, coworkers refuse to expend any effort into
learning it to any extent.  Consequently, we can't do rapid GUI development
in Tcl/Tk for internal projects.

I'm having a hard enough time getting coworkers to learn shell scripting,
let alone a new-to-them language like Erlang.

Now a slightly off topic question:  Has anyone had success at getting
Erlang (or any other isoteric-to-them language/environment) into an
environment like I'm describing?

--
Shawn.

Why do I like Perl?  Because ``in accordance with Unix tradition Perl
gives you enough rope to hang yourself with.''

Why do I dislike Java? Because ``the class ROPE that should contain the
method HANG to do the hanging doesn't exist because there is too much
'security' built into the base language.''


Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Alex Peake


> -----Original Message-----
> From: owner-erlang-questions
> [mailto:owner-erlang-questions]On Behalf Of Shawn Pearce
> Sent: Monday, July 22, 2002 8:22 PM
> To: erlang-questions
> Subject: Re: Erlang killer app?,
>
>
[...snip...]
> Now a slightly off topic question:  Has anyone had success at getting
> Erlang (or any other isoteric-to-them language/environment) into an
> environment like I'm describing?
>

I am using Erlang in just such an environment, but surreptitiously -- I use to to generate Active
Server Pages, VB COM objects and JavaScript. I have also used it to generate VB forms. I am now
working on generating C#, ASPX versions.

Alex




Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Steven H. Rogers
In reply to this post by Shawn Pearce
Shawn Pearce wrote:

<snip/>

>
> I'm having a hard enough time getting coworkers to learn shell scripting,
> let alone a new-to-them language like Erlang.
>
> Now a slightly off topic question:  Has anyone had success at getting
> Erlang (or any other isoteric-to-them language/environment) into an
> environment like I'm describing?
>

Well, I've had some success.

I introduced Java to my C shop when it was still considered esoteric.  I
silenced a complaint about using a non-standard language by countering that
if I'd really wanted to be non standard, I'd be using Objective-C.  Java
still isn't widely used in my group, though it now is in the rest of the
company.

I proposed Python as the scripting language for a piece of test
equipment and it was accepted over Perl, Tcl, and a home grown version
of Tiny C.  I intended it to be used by mostly "non-programmer"
engineers to write test scripts, but the systems programmers liked it
enough to use it for much of their work, with C extensions for hardware
interfacing.

So, in my experience, you can be successful if you present a good case.
  Now, I have a distributed control application that seems nearly ideal
for Erlang, but I don't whether I should try to introduce "Yet Another
Programming Language".  We're spread pretty thin and no matter how good
an "esoteric language" may be for a particular application, there is
extra overhead involved with using it.

Regards,
Steve
--
"A language that doesn't affect the way you think about programming is
not worth knowing." - Alan Perlis



Reply | Threaded
Open this post in threaded view
|

make_script info

Eric Merritt-3
Guys,

 I am am probably missing something here so I hope you
guys can point out my stupidity. I am trying to use
the systools:make_script function to make a boot file
for my app. This is the first time I have done this so
I am kinda moving slow. In any case, my application is
laid out according to the otp docs, ie.

 ./ebin
      appname.app
      appname.rel
 ./docs
 ./include
      someincludes.hrl
 ./src
      somesources.erl

My problem is that when I go to  use make script I
always get the error "File not found: appname.app",
this is getting frustrating becuase the appname.app
file is right there. The command I use for the
make_script function is

        erl -pa $(EBIN) \
        -s systools make_script appname \
 -s erlang halt -noshell

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


Reply | Threaded
Open this post in threaded view
|

make_script info

Christopher Williams-2
If I remember correctly systools:make_script expects the "appname.app"
should be in "./src" as default. You could always call the function
with 2 arguments systools:make_script(appname,[{path,["<Path>/ebin"]}]).
and it will find "appname.app" or you could use the script
<ERLHOME>/bin/erlc i.e. erlc -o . -I <Path>/ebin appname.rel

//Chris

On Tue, 23 Jul 2002, Eric Merritt wrote:

> Guys,
>
>  I am am probably missing something here so I hope you
> guys can point out my stupidity. I am trying to use
> the systools:make_script function to make a boot file
> for my app. This is the first time I have done this so
> I am kinda moving slow. In any case, my application is
> laid out according to the otp docs, ie.
>
>  ./ebin
>       appname.app
>       appname.rel
>  ./docs
>  ./include
>       someincludes.hrl
>  ./src
>       somesources.erl
>
> My problem is that when I go to  use make script I
> always get the error "File not found: appname.app",
> this is getting frustrating becuase the appname.app
> file is right there. The command I use for the
> make_script function is
>
> erl -pa $(EBIN) \
> -s systools make_script appname \
>  -s erlang halt -noshell
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>



Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Scott Lystig Fritchie-3
In reply to this post by Steven H. Rogers
>>>>> "sp" = Shawn Pearce (?) wrote:

>> Now a slightly off topic question: Has anyone had success at
>> getting Erlang (or any other isoteric-to-them language/environment)
>> into an environment like I'm describing?

I suppose I could've chimed in sooner about this.  If you haven't seen
it, I presented a paper about just such an experience at the 6th
Erlang/OTP User Conference.  See "Sendmail Meets Erlang: Experiences
Using Erlang for Email Applications" at http://www.erlang.se/euc/00/.

-Scott



Reply | Threaded
Open this post in threaded view
|

make_script info

Eric Merritt-3
In reply to this post by Christopher Williams-2

--- Chris Williams <chris.williams>
wrote:
> If I remember correctly systools:make_script expects
> the "appname.app"
> should be in "./src" as default. You could always
> call the function
> with 2 arguments

Just out or curiosity, if that is the case why does
the documentation suggest that it should go into the
ebin directory?
>systools:make_script(appname,[{path,["<Path>/ebin"]}]).
> and it will find "appname.app" or you could use the
> script
> <ERLHOME>/bin/erlc i.e. erlc -o . -I <Path>/ebin
> appname.rel

Thanks a million Chris, I will give this a shot.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


Reply | Threaded
Open this post in threaded view
|

make_script info

Francesco Mazzoli-2
>
>
>Just out or curiosity, if that is the case why does
>the documentation suggest that it should go into the
>ebin directory?
>
The app file is supposed to be in the ebin directory, as the search
paths in the code server (retrievable through code:get_path()) are used
to locate it.

Chis must have done a typo, as in his paths example, he has in fact
written ebin.. Some projects have in the past put their app files in
their src directories, but it creates problems with the sys tools, you
have to add the src directories in your search paths, and are all in all
limited in your actions...  If you want to tread in gray areas, there
are much more fun things you can do.

Cheers,
Francesco
--
http://www.erlang-consulting.com




Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Francesco Mazzoli-2
In reply to this post by Steven H. Rogers
A strategy I have seen work very well when introducing Erlang in new
environments is to put together a working prototype.. And often, this
can be achieved in little time providing something which usually
impresses. When others (including management and pointy haired bosses)
see the results versus what others have achieved using hyped stuff (Or
if nothing of it works, truckloads of documents :-), they have opted for
Erlang.

>> Now a slightly off topic question:  Has anyone had success at getting
>> Erlang (or any other isoteric-to-them language/environment) into an
>> environment like I'm describing?
>
Teaching it to people who question why they should be learning something
new? All the time... (As recently as three weeks ago..) But through
experience, if people have enough of a computer science background, they
very quickly realize the potential. Students who have maybe taken an
occasional programming course in college and have maybe only come in
contact with one or two languages and are the ones who are hard to
convince, as they feel safe with what they know and fear new stuff..

Regards,
Francesco
--
http://www.erlang-consulting.com



Reply | Threaded
Open this post in threaded view
|

make_script info

Eric Merritt-3
In reply to this post by Francesco Mazzoli-2
Francesco,

> The app file is supposed to be in the ebin
> directory, as the search
> paths in the code server (retrievable through
> code:get_path()) are used
> to locate it.
>
> Chis must have done a typo, as in his paths example,
> he has in fact
> written ebin.. Some projects have in the past put
> their app files in
> their src directories, but it creates problems with
> the sys tools, you
> have to add the src directories in your search
> paths, and are all in all
> limited in your actions...  If you want to tread in
> gray areas, there
> are much more fun things you can do.
>

Now I am a bit confused. If the *.app file is supposed
to be in the ebin directory then why doesn't
systools:make_script("appname") find it when I run it?
Even if it is in the ebin should I provide a path
(perhaps that is what I am not doing). My original
problem was that the make_script function couldn't
find the *.app file in ebin (though thats where its
at). I kept getting a file not found error which was a
bit frustrating.

Thanks for your input,
Eric

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Erlang killer app?,

Hal Snyder-2
In reply to this post by Francesco Mazzoli-2
Francesco Cesarini <francesco> writes:

> A strategy I have seen work very well when introducing Erlang in new
> environments is to put together a working prototype.. And often,
> this can be achieved in little time providing something which
> usually impresses. When others (including management and pointy
> haired bosses) see the results versus what others have achieved
> using hyped stuff (Or if nothing of it works, truckloads of
> documents :-), they have opted for Erlang.

What Francesco said.

It happened here. We did one pilot project in Erlang a couple years
ago. We were learning Erlang as we went. The pilot went so well that
there has been a succession of projects of larger and more ambitious
scope. It is a joy working with OTP.


Reply | Threaded
Open this post in threaded view
|

R9B-0 and Red Hat 8.0?

Steven H. Rogers
In reply to this post by Steven H. Rogers
Erlang/OTP R9B-0 fails to build for me on Red Hat Linux 8.0.  Has anyone
had any success with this platform?

Regards,
Steve
--
  _    Steven H. Rogers, PhD.
<_`   email: steve
|_>   Weblog http://shrogers.com/portal/Members/steve/blog
| \   "A language that doesn't affect the way you think about
       programming is not worth knowing." - Alan Perlis



Reply | Threaded
Open this post in threaded view
|

R9B-0 and Red Hat 8.0?

Thierry Mallard
On Sat, Oct 26, 2002 at 04:32:34PM -0500, Steve Rogers wrote:
> Erlang/OTP R9B-0 fails to build for me on Red Hat Linux 8.0.  Has anyone
> had any success with this platform?

I recall seeing someone having trouble with R8B-2 on RH8, but i don't
see on the list archive if he managed to get it compiled after all.

Can you explain with errors you got ?

Regards,

--
Thierry Mallard
http://vawis.net



12