| Author |
Message |
|
| Marc.Vanwoerkom at FernUn |
 Posted: Tue Apr 01, 2003 3:25 pm |
 |
|
|
Guest
|
|
| Back to top |
|
| erlang at manderp.freeser |
| Posted: Tue Apr 01, 2003 4:26 pm |
|
|
|
Guest
|
Hmm... I think I mentioned before that I'm utterly impervious to
embarassment! You got me. (-:
Pete.
Peter-Henry Mander wrote:
> Oh dear, I only just got used to the existing terminology! (-:
>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| matthias at corelatus.se |
| Posted: Tue Apr 01, 2003 5:08 pm |
|
|
|
Guest
|
Hi,
It's probably a reflection on my poor work/play ratio, but today has
been more fun that I've had for quite some time. Thanks to everyone
who fell for it gratiously, everyone who saw through it and kept quiet
and, best of all, those who picked up the ball and ran with
it. Destructive update indeed!
Cheers,
Matt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| martin at vailsys.com |
| Posted: Wed Apr 02, 2003 8:46 am |
|
|
|
Guest
|
All,
This thread has yielded quite a discussion. I must admit that I
became quite sick reading Bjorns email proposing pointer syntax and
destructive assignment, I did not catch the joke until I read further -
scary. While some of the suggestions about "nice-ing up" Erlang
terminology might not sit well with most people on this list, I think
the idea of making Erlang terminology intelligible and accessible to
managers and the like is an issue that needs to be addressed. I know
that all of the people on this list love the language the way it is and
would like to see it spread. I also know what it is like to try to sell
a C/C++ shop's management, and engineers for that matter, on something
new like Erlang. This task is made more difficult when things like,
letting processes crash being a good thing, are mentioned. It is
difficult for them to wrap their minds, addled by years of C/C++
programming:) around "not being defensive, just letting it crash, and
spawn 20 thousand processes". This difficulty is compounded with those
phrases are thrown in the mix with dynamic typing, run time code reload,
and location transparency. Most of the time people look at you like you
have been smoking something! Am I wrong here??? I don't think that we
should compromise the basic foundations of the language. Erlang is
functional, concurrent, a process is a process, a list is a list, and a
node is a erlang virtual machine:) I just think that we should not be
shy away from well chosen euphemisms - they should an important part of
every would-be Erlang salesman's life.
Here is how the other ninety nine and one half sees it:
1. Crashing is a great way to handle errors ==C++== seg faults on
purpose.
2. 20000 processes ==average UNIX guy== real slow
3. don't be defensive ==Most other languages== sloppy incomplete error
checking
4. Dynamic typing combined with "don't be defensive" ==Most static
typing theory junkies== just can't work.
5. Run time code reload on top of all of this gets you disbelieving
looks and you are dismissed as being a crackpot:)
This is not the way to sell something. I am not suggesting that we
compromise what Erlang is, that would be a worse mistake than being bad
sales people. I am saying that we get used to saying things in a more
marketing friendly way.
Example:
Erlang allows the programmer easily generate exceptions when a process
gets into a bad state, these exceptions can be simply used to "reset the
state of a process" instead of crashing the application.
ok = demo:do()
allows state to be reset if demo:do were to return 'error'. The process
is then immediately ready to do work again. This makes programming
customers applications much easier and the apps themselves much more
robust. The beauty is that it is all built in, saving you development
time and headache - more ROI.
Just an idea maybe over the top - a bit:) but I think that saying things
in a "nice" way needs to be contemplated.
My 2 cents,
Martin
On Tue, 2003-04-01 at 00:22, Matthias Lang wrote:
> Hi,
>
> Recently, there was some confusion on the list about the meaning of
> "Defensive Programming" in the context of Erlang. For most
> programmers, defensive programming is a good thing, yet in the Erlang
> programming guidelines it is considered a bad thing. Therefore I've
> renamed it to "micro-managed error handling" to make the author's
> intent clearer. While doing that, I also tackled a number of similar
> problems:
>
> crash: again, in most languages crashing is bad whereas in Erlang it
> confusingly enough becomes a good thing. The FAQ now refers
> to such events as "inter-process exceptions (IPEs)"
>
> single-assignment: is a very academic term for what most people
> would call "const" variables. I have coined the replacement
> term "auto-consting".
>
> tail-recursion: very powerful feature. Ridiculously academic name.
> Now called stack-unrolling.
>
> process: thread. An process is very lightweight. The rest of the
> world refers to lightweight processes as threads. So does the
> Erlang FAQ from now on.
>
> node: process. An Erlang node is always an OS process. So we may as
> well call a spade a spade. "process" now means "erlang node".
>
> behaviour: interface. In R9B-2, the directive '-public(gen_server).'
> is a synonym for '-behaviour'. In R10, the -behaviour
> directive will elicit a warning. By R11 an error.
>
> list: array. Everyone knows what an array is.
>
> Any further suggestions?
>
> Matthias
>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joe at sics.se |
| Posted: Wed Apr 02, 2003 11:00 am |
|
|
|
Guest
|
On 1 Apr 2003, martin j logan wrote:
> All,
> This thread has yielded quite a discussion. I must admit that I
> became quite sick reading Bjorns email proposing pointer syntax and
> destructive assignment, I did not catch the joke until I read further -
> scary. While some of the suggestions about "nice-ing up" Erlang
> terminology might not sit well with most people on this list, I think
> the idea of making Erlang terminology intelligible and accessible to
> managers and the like is an issue that needs to be addressed. I know
> that all of the people on this list love the language the way it is and
> would like to see it spread. I also know what it is like to try to sell
> a C/C++ shop's management, and engineers for that matter, on something
> new like Erlang. This task is made more difficult when things like,
> letting processes crash being a good thing, are mentioned. It is
> difficult for them to wrap their minds, addled by years of C/C++
> programming:) around "not being defensive, just letting it crash, and
> spawn 20 thousand processes". This difficulty is compounded with those
> phrases are thrown in the mix with dynamic typing, run time code reload,
> and location transparency. Most of the time people look at you like you
> have been smoking something! Am I wrong here??? I don't think that we
> should compromise the basic foundations of the language. Erlang is
> functional, concurrent, a process is a process, a list is a list, and a
> node is a erlang virtual machine:) I just think that we should not be
> shy away from well chosen euphemisms - they should an important part of
> every would-be Erlang salesman's life.
I think you're both right and wrong here - it depends who you are
selling.
The sales pitch has to be two dimensional, i.e.
Problem X Person
To start with the problem domain has to be suitable for Erlang - so
I spend a great deal of time listening to what peoples problem are
before recommending Erlang - often I recommend C - or even visual basic.
You have to ask the question: What is Erlang good at? - the answer
is not *everything* - the answer is that it is good at distribution
and fault-tolerant stuff - it's not good at sequential "poking around
in memory" stuff ...
Then there is the person - the augment directed to a "suit" or "a
unix guy" or "a java person" are just not the same.
"suits" need special treatment ... (two sub-categories of suit are
VC (venture capitalist) and "LM" Line management
If I'm selling to "VC" I always use the "MAKE MORE MONEY FAST"
argument - I present them with good hard evidence that Erlang projects
have a higher chance of succeeding than non-Erlang projects.
"VC" are more likely to take risks, so they like this argument -
though they will press hard on details.
The main objection of the "LM" is that "Erlang in not Java/C++" - if
they allow Erlang they are often taking a big personal risk - they
actual stand to gain if they have large development teams and everything
takes a long time - their pay = LengthOfTimeOFPROJECT X #people in
project - so Erlang is a no no here.
Selling to programmers is different - getting the "Early adopters is
easy" they *like* new stuff - it's the mainstream that's the problem -
they want "lots of stuff for free" - they think "Oh dear, their's no
GUI - so I can't use Erlang" - the early adopters think "Oh great,
their's no GUI - I'll write one myself ..."
Arguments have to be *careful* matched against the Problem X
Mindset of the person you are trying to sell Erlang to - if anything
the trend is towards economic rather than technical arguments which
indicates a movement towards the main stream ...
What does bite are "statement by other people" - press releases by
Nortel and Ericsson where they say "Erlang is great" have much more
credibility than anything we can say. Unfortunately big companies
don't usually make a big deal of "the technology inside" (apart from
Intel) - since non of their customers actually care what's inside.
Todays article (New great stuff from Nortel programmed in Erlang)
in Computer Sweden is a good example ...
I still think the best method is "success stories" ...
/Joe
>
> Here is how the other ninety nine and one half sees it:
>
> 1. Crashing is a great way to handle errors ==C++== seg faults on
> purpose.
>
> 2. 20000 processes ==average UNIX guy== real slow
>
> 3. don't be defensive ==Most other languages== sloppy incomplete error
> checking
>
> 4. Dynamic typing combined with "don't be defensive" ==Most static
> typing theory junkies== just can't work.
>
> 5. Run time code reload on top of all of this gets you disbelieving
> looks and you are dismissed as being a crackpot:)
>
> This is not the way to sell something. I am not suggesting that we
> compromise what Erlang is, that would be a worse mistake than being bad
> sales people. I am saying that we get used to saying things in a more
> marketing friendly way.
>
> Example:
>
> Erlang allows the programmer easily generate exceptions when a process
> gets into a bad state, these exceptions can be simply used to "reset the
> state of a process" instead of crashing the application.
>
> ok = demo:do()
>
> allows state to be reset if demo:do were to return 'error'. The process
> is then immediately ready to do work again. This makes programming
> customers applications much easier and the apps themselves much more
> robust. The beauty is that it is all built in, saving you development
> time and headache - more ROI.
>
> Just an idea maybe over the top - a bit:) but I think that saying things
> in a "nice" way needs to be contemplated.
>
> My 2 cents,
> Martin
>
>
>
> On Tue, 2003-04-01 at 00:22, Matthias Lang wrote:
> > Hi,
> >
> > Recently, there was some confusion on the list about the meaning of
> > "Defensive Programming" in the context of Erlang. For most
> > programmers, defensive programming is a good thing, yet in the Erlang
> > programming guidelines it is considered a bad thing. Therefore I've
> > renamed it to "micro-managed error handling" to make the author's
> > intent clearer. While doing that, I also tackled a number of similar
> > problems:
> >
> > crash: again, in most languages crashing is bad whereas in Erlang it
> > confusingly enough becomes a good thing. The FAQ now refers
> > to such events as "inter-process exceptions (IPEs)"
> >
> > single-assignment: is a very academic term for what most people
> > would call "const" variables. I have coined the replacement
> > term "auto-consting".
> >
> > tail-recursion: very powerful feature. Ridiculously academic name.
> > Now called stack-unrolling.
> >
> > process: thread. An process is very lightweight. The rest of the
> > world refers to lightweight processes as threads. So does the
> > Erlang FAQ from now on.
> >
> > node: process. An Erlang node is always an OS process. So we may as
> > well call a spade a spade. "process" now means "erlang node".
> >
> > behaviour: interface. In R9B-2, the directive '-public(gen_server).'
> > is a synonym for '-behaviour'. In R10, the -behaviour
> > directive will elicit a warning. By R11 an error.
> >
> > list: array. Everyone knows what an array is.
> >
> > Any further suggestions?
> >
> > Matthias
> >
>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| John-Olof.Bauner at ERA.E |
| Posted: Wed Apr 02, 2003 11:17 am |
|
|
|
Guest
|
Joe Armstrong wrote:
> The main objection of the "LM" is that "Erlang in not Java/C++" - if
>they allow Erlang they are often taking a big personal risk - they
>actual stand to gain if they have large development teams and everything
>takes a long time - their pay = LengthOfTimeOFPROJECT X #people in
>project - so Erlang is a no no here.
>
And when the big Java/C++-project is delayed more people are thrown in
and the LM becomes an even bigger LM.
John-Olof
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Marc.Vanwoerkom at FernUn |
| Posted: Wed Apr 02, 2003 11:59 am |
|
|
|
Guest
|
> Todays article (New great stuff from Nortel programmed in Erlang)
> in Computer Sweden is a good example ...
Is that available online?
Regards,
Marc
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joe at sics.se |
| Posted: Wed Apr 02, 2003 12:25 pm |
|
|
|
Guest
|
On Wed, 2 Apr 2003, Marc Ernst Eddy van Woerkom wrote:
> > Todays article (New great stuff from Nortel programmed in Erlang)
> > in Computer Sweden is a good example ...
>
> Is that available online?
Try these ...
<li><a href="http://computersweden.idg.se/ArticlePages/200304/02/20030402081837_CS631/20030402081837_CS631.dbp.asp">Nortelsvenskar s |
|
|
| Back to top |
|
| jch at algo.net |
| Posted: Wed Apr 02, 2003 12:26 pm |
|
|
|
Guest
|
Marc Ernst Eddy van Woerkom <Marc.Vanwoerkom_at_FernUni-Hagen.de> writes:
> > Todays article (New great stuff from Nortel programmed in Erlang)
> > in Computer Sweden is a good example ...
>
> Is that available online?
It's at
<http://computersweden.idg.se/ArticlePages/200304/02/20030402131746_CS745/20030402131746_CS745.dbp.asp>.
--
"I live in the heart of the machine. We are one."
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| eleberg at cbe.ericsson.s |
| Posted: Wed Apr 02, 2003 12:26 pm |
|
|
|
Guest
|
> Date: Wed, 2 Apr 2003 13:58:59 +0200 (MEST)
> From: Marc Ernst Eddy van Woerkom <Marc.Vanwoerkom_at_FernUni-Hagen.de>
> > Todays article (New great stuff from Nortel programmed in Erlang)
> > in Computer Sweden is a good example ...
>
> Is that available online?
in swedish:
http://computersweden.idg.se/ArticlePages/200304/02/20030402131746_CS745/2003040
2131746_CS745.dbp.asp
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| matthias at corelatus.se |
| Posted: Wed Apr 02, 2003 12:52 pm |
|
|
|
Guest
|
Marc Ernst Eddy van Woerkom writes:
> > Todays article (New great stuff from Nortel programmed in Erlang)
> > in Computer Sweden is a good example ...
>
> Is that available online?
I know of three current articles in various newspapers about Bluetail.
But they're all in Swedish:
http://www.nyteknik.se/pub/ipsart.asp?art_id=27520
Abridged translation: Bluetail was sold to Alteon for
1.4Msek a while ago (about $150M). Unlike lots
of other Swedish companies bought by Americans, Bluetail
hasn't been axed. 10 employees are still employed.
H |
|
|
| Back to top |
|
| jamesh at Volition-inc.co |
| Posted: Wed Apr 02, 2003 3:12 pm |
|
|
|
Guest
|
Joe Armstrong wrote:
> You have to ask the question: What is Erlang good at? -
> the answer is not *everything* - the answer is that it
> is good at distribution and fault-tolerant stuff - it's
> not good at sequential "poking around in memory" stuff ...
There is a vast area between the two extremes, though, including such
applications as:
ErlGuten
Wings3D
20001 ICFP Judges' Prize winner
but as you worked on two of these, you already know this :)
Unintentional though it may be, Erlang fills a general programming void.
Haskell is still too academic to bank on. ML and OCaml are often too
static. Lisp has grown crusty in certain ways and can be awkward after
using more modern functional syntax (e.g. Lisp's LET). Python is overly
OOP-centric.
Of course one loophole is that "fault tolerant" can be extended to mean "all
applications."
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Wed Apr 02, 2003 6:02 pm |
|
|
|
Guest
|
On Tue, Apr 01, 2003 at 12:38:31PM -0600, martin j logan wrote:
>
> Here is how the other ninety nine and one half sees it:
>
> 1. Crashing is a great way to handle errors ==C++== seg faults on
> purpose.
Don't say it that way. Segfaults are NOT done on purpose (i.e. no C/C++
programmer that I know of _wants_ his code to segfault, whereas in Erlang you
may intend for your process to die and be reborn. Not a clear analogy.
> 2. 20000 processes ==average UNIX guy== real slow
Don't say it that one. Entire node is *1* UNIX process running a thread per
OTP process. That doesn't sound nearly as slow.
> 3. don't be defensive ==Most other languages== sloppy incomplete error
> checking
Most languages would argue that you _should_ be defensive (ex. checking for
NULL, catching exceptions, etc.) Not sure this one is clear.
> 4. Dynamic typing combined with "don't be defensive" ==Most static
> typing theory junkies== just can't work.
Not sure how to address this one. I have worked too much with C++ and not enough
with Erlang to make a good call on this. Static typing has helped me a great
deal with my C++ code. Working in languages like Perl in the past (intern days)
without strict type checking I managed to get myself into trouble as the code
got really big and I failed to [re]factor it into manageable units (especially
since Perl insists on there being "more than one way" to do anything). Is the
same not true with Erlang/OTP?
Has anyone ever written an OTP application that crashed as the result of
passing the wrong type into a function or by misspelling a variable? Of course
with test-first methodology such a crash should not occur in production, but
still I can't help but wonder what is so wrong with such a silly mistake being
caught at compile time (since the misspelling, for example, would have been
caught by a lack of declaration of the typo, and the bad function call would
have also been caught). Though test-first methodology and rich test suites
will/should catch such mistakes, wouldn't it be better to have a compiler catch
such mistakes? Is it that much more work to declare a variable before using it?
I personally am a big fan of Perl and the "strict" pragma. Omitting the "use"
of this allows one to whip up a quick-and-dirty script in a hurry without
declaring variables. By "use"ing it, you can catch all sorts of silly typos in
larger scripts that would otherwise have to be chased down during testing.
Could someone explain why static typing is considered so "bad" or "unnecessary"?
I think I could be sold on this (I _do_ consider myself to be open-minded), I
just need to hear the right argument.
> 5. Run time code reload on top of all of this gets you disbelieving
> looks and you are dismissed as being a crackpot:)
Shoot down C/C++ junkies here by discussing shared objects and runtime linkage.
Is that not a similar creature? Not sure why one would be so much scarier than
the other.
> Example:
>
> Erlang allows the programmer easily generate exceptions when a process
> gets into a bad state, these exceptions can be simply used to "reset the
> state of a process" instead of crashing the application.
>
> ok = demo:do()
>
> allows state to be reset if demo:do were to return 'error'. The process
> is then immediately ready to do work again. This makes programming
> customers applications much easier and the apps themselves much more
> robust. The beauty is that it is all built in, saving you development
> time and headache - more ROI.
This argument is not so bad, though it would need to be followed up by (at
least) a brief explanation of supervision trees in OTP.
Just my 2 cents ;-)
-Rick
P.S. Sorry if I come across as argumentative. For the record I actually DO
agree with Martin on quite a lot of his ideas, and I AM sold on Erlang/OTP.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Wed Apr 02, 2003 6:37 pm |
|
|
|
Guest
|
On Wed, 2 Apr 2003 11:50:51 -0600
Rick Pettit <rpettit_at_vailsys.com> wrote:
> On Tue, Apr 01, 2003 at 12:38:31PM -0600, martin j logan wrote:
> >
> > Here is how the other ninety nine and one half sees it:
> >
> > 1. Crashing is a great way to handle errors ==C++== seg faults on
> > purpose.
>
> Don't say it that way. Segfaults are NOT done on purpose (i.e. no
> C/C++ programmer that I know of _wants_ his code to segfault, whereas
> in Erlang you may intend for your process to die and be reborn. Not a
> clear analogy.
I think what Martin was trying to say is that when you say that crashing
is a great way to handle errors, what the average C++ guy hears is 'Seg
fault on purpose? That makes no sense. These Erlang people are crazy.
Etc.'
> [...]
> Not sure how to address this one. I have worked too much with C++ and
> not enough with Erlang to make a good call on this. Static typing has
> helped me a great deal with my C++ code. Working in languages like
> Perl in the past (intern days) without strict type checking I managed
> to get myself into trouble as the code got really big and I failed to
> [re]factor it into manageable units (especially since Perl insists on
> there being "more than one way" to do anything). Is the same not true
> with Erlang/OTP?
Yes. But IMO Perl's problems go way beyond just having dynamic typing,
as well.
> Has anyone ever written an OTP application that crashed as the result
> of passing the wrong type into a function or by misspelling a
> variable?
Crashed, no. Failed, yes.
And that, I think, is an important point. To most people, "crash" is a
dirty word because *they associate it with loss of data*.
But (even before I encountered Erlang) I realized that a crash is, at
least, a clear indication that something has gone wrong. What is worse
is the insiduous failure... the semantic error in the system that you
don't consciously notice for a long time because it *doesn't* make
anything crash outright. It just bungs up the works and leaves you with
the feeling that your system is inhabited by gremlins.
> Of course
> with test-first methodology such a crash should not occur in
> production, but still I can't help but wonder what is so wrong with
> such a silly mistake being caught at compile time (since the
> misspelling, for example, would have been caught by a lack of
> declaration of the typo, and the bad function call would have also
> been caught).
Catching errors as soon as possible is a good thing (and can help avoid
gremlins too).
I think there's something of a false dilemma here, too - the dynamic
typing advocates usually take the position that strong typing is
stifling (which it is,) while the strong typing advocates usually take
the position that once you have strong typing, you don't need dynamic
typing (which is a very systems-construction-ish approach that doesn't
lend itself well to ad-hoc networks and hot code reloading.)
My thought is that the best system would have both compile-time and
run-time checks.
> > 5. Run time code reload on top of all of this gets you disbelieving
> > looks and you are dismissed as being a crackpot:)
>
> Shoot down C/C++ junkies here by discussing shared objects and runtime
> linkage. Is that not a similar creature? Not sure why one would be so
> much scarier than the other.
Because runtime linkage typically only happens once during a run of a
program, whereas hot code swapping can happen any number of times with
any number of changes the to code in the interim.
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Wed Apr 02, 2003 7:30 pm |
|
|
|
Guest
|
On Wed, Apr 02, 2003 at 12:33:27PM -0600, Chris Pressey wrote:
> I think what Martin was trying to say is that when you say that crashing
> is a great way to handle errors, what the average C++ guy hears is 'Seg
> fault on purpose? That makes no sense. These Erlang people are crazy.
> Etc.'
Ah, that makes more sense. Though I know loss of data is a concern when anything
crashes.
> Yes. But IMO Perl's problems go way beyond just having dynamic typing,
> as well.
Agreed. Bad example. I try to stay away from Perl for everything but the
quick-and-dirty scripts these days.
> > Has anyone ever written an OTP application that crashed as the result
> > of passing the wrong type into a function or by misspelling a
> > variable?
>
> Crashed, no. Failed, yes.
>
> And that, I think, is an important point. To most people, "crash" is a
> dirty word because *they associate it with loss of data*.
Agreed.
> But (even before I encountered Erlang) I realized that a crash is, at
> least, a clear indication that something has gone wrong. What is worse
> is the insiduous failure... the semantic error in the system that you
> don't consciously notice for a long time because it *doesn't* make
> anything crash outright. It just bungs up the works and leaves you with
> the feeling that your system is inhabited by gremlins.
Agreed. Assertions can be made in these cases to prevent this very dilemma.
Design by contract seems to address this.
> Catching errors as soon as possible is a good thing (and can help avoid
> gremlins too).
>
> I think there's something of a false dilemma here, too - the dynamic
> typing advocates usually take the position that strong typing is
> stifling (which it is,) while the strong typing advocates usually take
> the position that once you have strong typing, you don't need dynamic
> typing (which is a very systems-construction-ish approach that doesn't
> lend itself well to ad-hoc networks and hot code reloading.)
I think I follow...
> My thought is that the best system would have both compile-time and
> run-time checks.
I fully agree.
> Because runtime linkage typically only happens once during a run of a
> program, whereas hot code swapping can happen any number of times with
> any number of changes the to code in the interim.
Well yes, unless the C/C++ application loading the shared object (which in turn
requires runtime linkage) does so over and over again (i.e. loads .so, then
later unloads and reloads NEW .so, and so on). In this case I don't see the
difference.
Unless I am missing something here, regardless of type checking the interface
to the [shared object|hot code being loaded] MUST remain the same in BOTH
cases. Of course the code behind the interface can change as much as it wants
to, also in both cases. In this sense I see no difference between Erlang hot
code load and loading/unloading of shared objects.
Am I missing something?
-Rick
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
