| Author |
Message |
|
| cpressey at catseye.mb.ca |
 Posted: Wed Apr 02, 2003 8:27 pm |
 |
|
|
Guest
|
On Wed, 2 Apr 2003 13:18:15 -0600
Rick Pettit <rpettit_at_vailsys.com> wrote:
> On Wed, Apr 02, 2003 at 12:33:27PM -0600, Chris Pressey wrote:
> [...]
> > 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.
But how often does this happen in practice?
My impression is that .so's are employed almost exclusively so that an
application doesn't use up memory for code until it knows it needs it.
i.e. for many (most? all?) programs that are built with .so's I've also
seen options to build them with statically linked-in libraries.
(Sometimes this is done to make it easier for the user, so that they
don't have to download .so's and/or so the system won't accidentally try
to load old .so's.)
> 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?
Not really - it's not as much a question of capability, as it is of how
they're commonly used.
Perhaps the issue is that compiled programs using .so's generally aren't
fault-tolerant in the same way Erlang is, so using them for hot-swapping
is that much scarier. At least with a well written Erlang program, if
you swap in something that's up to no good, you can swap it out again
and put in the old thing. With a C program, the seg fault would have
already happened, and there would be nothing more you could do.
Either way, the interface can't change... well, yes and no. The
interface between functions can't change. But the interface within the
data passed to the functions might. A new option {foo, bar} might be
added to a list of configuration options, or an old one might be
deprecated. Not sure if this is what you were thinking of, though.
> -Rick
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Wed Apr 02, 2003 9:28 pm |
|
|
|
Guest
|
On Wed, Apr 02, 2003 at 02:27:34PM -0600, Chris Pressey wrote:
> > 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.
>
> But how often does this happen in practice?
Perhaps not often in other companies, but I have personnally written shared
object libraries that are meant to be loaded/unloaded/reloaded as the
implementation behind the interface evolves. Works really well, too, in that
C/C++ clients talk to Erlang servers via these shared objects, and as long as
the API from C/C++ app to shared object stays the same all sorts of neat
changes can take place both on server side (hot code load) and on client
side (shared library swap), with NO DOWNTIME!
> My impression is that .so's are employed almost exclusively so that an
> application doesn't use up memory for code until it knows it needs it.
This is perhaps most common use.
> i.e. for many (most? all?) programs that are built with .so's I've also
> seen options to build them with statically linked-in libraries.
> (Sometimes this is done to make it easier for the user, so that they
> don't have to download .so's and/or so the system won't accidentally try
> to load old .so's.)
Agreed. I think that is the case. Also, applications with statically compiled
shared objects do not need to make libdl calls to load/unload explicitly, IIRC.
Of course this means such binaries can NOT reload shared objects on the fly.
> Perhaps the issue is that compiled programs using .so's generally aren't
> fault-tolerant in the same way Erlang is, so using them for hot-swapping
> is that much scarier. At least with a well written Erlang program, if
> you swap in something that's up to no good, you can swap it out again
> and put in the old thing. With a C program, the seg fault would have
> already happened, and there would be nothing more you could do.
Agreed, though segfaults normally occur in software that is not defensive
and has not been coded under a test-first methodology. Not sure there is a
big difference between loading a shared object that core's the application
and hot-loading Erlang code that keeps killing the process it was loaded into.
Only difference is that supervisor would probably restart OTP process, as would
inittab entry on Solaris or daemontools, etc. In both cases the new code has
to be taken back out and the good version put back in. In both cases the new
code caused a problem. Though the entire application may not have gone down in
the OTP realm, that may not mean that it can function normally (or at all).
My point is that there is NOT a big difference between the two, and that is
how Martin should approach the sales pitch with C/C++ guys who argue against
hot-code load but are all for shared objects.
> Either way, the interface can't change... well, yes and no. The
> interface between functions can't change. But the interface within the
> data passed to the functions might. A new option {foo, bar} might be
> added to a list of configuration options, or an old one might be
> deprecated. Not sure if this is what you were thinking of, though.
Well, yes and no. That is no different than putting an extra node into a
data structure passed in C/C++ IMO. The basic interface MUST remain the same
in both cases, but can be modified via the actual data passed in, also in
both cases. Again, my point being that there is no real difference between
Erlang/OTP hot code load and C/C++ shared object loading, so Martin's
sales pitch can include this fact. Under this light, the idea of hot code load
is NOT all that crazy.
-Rick
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Thu Apr 03, 2003 3:40 am |
|
|
|
Guest
|
On Wed, 2 Apr 2003 15:16:42 -0600
Rick Pettit <rpettit_at_vailsys.com> wrote:
> On Wed, Apr 02, 2003 at 02:27:34PM -0600, Chris Pressey wrote:
> > > 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.
> >
> > But how often does this happen in practice?
>
> Perhaps not often in other companies, but I have personnally written
> shared object libraries that are meant to be loaded/unloaded/reloaded
> as the implementation behind the interface evolves. Works really
> well, too, in that C/C++ clients talk to Erlang servers via these
> shared objects, and as long as the API from C/C++ app to shared object
> stays the same all sorts of neat changes can take place both on server
> side (hot code load) and on client side (shared library swap), with NO
> DOWNTIME!
Hey, if it works, more power to you. I'm still in a position where I'm
working on projects where a couple of minutes of downtime is acceptable,
so my experience with hot swapped code comes mostly from playing with it
- and I don't think I've ever written a .so - so I'm out of my element
here.
> [...]
> My point is that there is NOT a big difference between the two, and
> that is how Martin should approach the sales pitch with C/C++ guys who
> argue against hot-code load but are all for shared objects.
In light of your success with it - yes indeed.
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| martin at vailsys.com |
| Posted: Thu Apr 03, 2003 6:49 am |
|
|
|
Guest
|
On Wed, 2003-04-02 at 11:50, Rick Pettit 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.
Perhaps I can clarify my little ==<other types of people>== bit here.
When explaining how things are done in Erlang is is often said that "you
should not explicitly handle errors just let the process crash". When a
person used to programming in C or C++ hears that they often think
crash/segfault that can't ever be good. Stating that "letting a process
crash in lieu of handling an error explicitly" is a good thing is not
the best way to present the supervision feature of OTP/Erlang to
non-erlangers.
>
> > 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.
>
We talk about spawning processes very casually when explaining Erlang. I
know the look that I get when I say "This app is comprised of thousands
of processes". To most people familiar with concurrency at the UNIX OS
level or any number of threading schemes this sounds preposterous. Even
after explanation most don't believe it until they have worked with it.
Most will not get that opportunity as they will right you off after
hearing about your 20000 processes:)
> > 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.
It is common in Erlang code to explicitly handle errors only on
untrusted interfaces. This is not the case in most other languages and
sounds rather radical/unrealistic to the uninitiated.
> > 4. Dynamic typing combined with "don't be defensive" ==Most static
> > typing theory junkies== just can't work.
After saying that you should not be defensive your labeled a radical if
you then follow it with "...and its all dynamically typed" you will be
walked to the door and asked never to come back. We know after
programming Erlang that judicious coding practice and all of Erlangs
pluses allow very correct fault tolerant code to be written. Most people
do not believe this until they see it.
I hope this is more clear now.
Cheers,
Martin
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Thu Apr 03, 2003 6:49 am |
|
|
|
Guest
|
On Wed, Apr 02, 2003 at 02:47:40PM -0600, martin j logan wrote:
>
> Perhaps I can clarify my little ==<other types of people>== bit here.
>
> When explaining how things are done in Erlang is is often said that "you
> should not explicitly handle errors just let the process crash". When a
> person used to programming in C or C++ hears that they often think
> crash/segfault that can't ever be good. Stating that "letting a process
> crash in lieu of handling an error explicitly" is a good thing is not
> the best way to present the supervision feature of OTP/Erlang to
> non-erlangers.
Agreed. Chris cleared this silly misunderstanding up for me.
> We talk about spawning processes very casually when explaining Erlang. I
> know the look that I get when I say "This app is comprised of thousands
> of processes". To most people familiar with concurrency at the UNIX OS
> level or any number of threading schemes this sounds preposterous. Even
> after explanation most don't believe it until they have worked with it.
> Most will not get that opportunity as they will right you off after
> hearing about your 20000 processes:)
Right, but again there is only *1* OS process, with many threads of execution
within it. 20000 UNIX processes DOES sound preposterous!
> > Most languages would argue that you _should_ be defensive (ex. checking for
> > NULL, catching exceptions, etc.) Not sure this one is clear.
>
> It is common in Erlang code to explicitly handle errors only on
> untrusted interfaces. This is not the case in most other languages and
> sounds rather radical/unrealistic to the uninitiated.
Agreed. I suppose it is interesting to point out that if a C/C++ application
was _also_ comprised of individual processes which _could_ crash then a similar
approach could be taken. That is, checking for NULL and catching exceptions
would NOT have to happen on internal code, only at the border.
The difference here is that of restarting a light-weight thread within the OTP
node vs. an entire UNIX process. Don't see any other big differences between
letting an OTP process (not on the border) to blow up vs. letting a C/C++
application referencing NULL pointer blow up.
In both cases, if the overall system is coded to cope with such process deaths
than it doesn't really matter, aside from the performance hit restarting a
UNIX process vs. a very light-weight Erlang one.
> > > 4. Dynamic typing combined with "don't be defensive" ==Most static
> > > typing theory junkies== just can't work.
>
> After saying that you should not be defensive your labeled a radical if
> you then follow it with "...and its all dynamically typed" you will be
> walked to the door and asked never to come back. We know after
> programming Erlang that judicious coding practice and all of Erlangs
> pluses allow very correct fault tolerant code to be written. Most people
> do not believe this until they see it.
Though I do not disagree that judicious coding practice coupled with the many
wonderful features of Erlang can lead to a large body of correct/fault-tolerant
code, I have my doubts about that codes reusability.
I can hear the anti-OO guys out there are already, and I agree that such OO
concepts as inheritance are not all they are cracked up to be in practice (i.e.
usually a good inheritance tree comes about as the result of refactoring an
existing system, since it may not have been clear at design time how the tree
should be layed out). A big difference is reusing functions/objects internally
that ARE defensively coded.
Put another way, most all my objects ARE defensive, and might as well be placed
"on the border". Since this is true, I can reuse an internal object on the
border without worrying about crashes. I can make calls to it from anywhere
and know that it is well behaved.
The same is NOT true with an Erlang module that is coded to crash on bad data
since it is not meant for border use. It would be a big mistake to use such
a module in a border case, and thus it is important as an Erlang/OTP developer
to make crystal clear the distinction.
Of course the code is much smaller when it is not defensively coded throughout
the application, no argument there. But when both sides (i.e. C/C++ and
Erlang OTP) are coded that way, what is the difference?
I suppose defensively coding EVERYTHING is a bit silly and unnecessary, but
this is not a strengh/weakness of Erlang/OTP, merely a coding practice that
can be (or not be) applied to any language.
> I hope this is more clear now.
Much. Thank you.
-Rick
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| martin at vailsys.com |
| Posted: Thu Apr 03, 2003 6:49 am |
|
|
|
Guest
|
On Wed, 2003-04-02 at 03:58, Joe Armstrong wrote:
>
>
>
>
> 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.
>
I agree.
> "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.
This is the place we need to sell the hardest. Erlang needs to shine
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 ...
>
The thing is, erlang is a wonderful tool for capitalizing on economic
opportunities. Rapid Development, high ROI, low maintenance... The list
goes on. How do we position ourselves/Erlang?? How does Erlang
capitalize??
> 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, I fully agree with you on this one.
I think that one way to have more of these would be to sell the "LM".
>
Cheers,
Martin
> /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 |
|
| eleberg at cbe.ericsson.s |
| Posted: Thu Apr 03, 2003 6:50 am |
|
|
|
Guest
|
> From: James Hague <jamesh_at_Volition-inc.com>
> Lisp has grown crusty in certain ways and can be awkward after
> using more modern functional syntax
the major problem i have with erlang vs lisp is erlangs syntax. it is
not sufficiently symetric, i suppose (i prefer matching start-stop
markers). and i have a terrible time remembering if i should use ;/, or
not, in case statements.
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| erlang at manderp.freeser |
| Posted: Thu Apr 03, 2003 7:06 am |
|
|
|
Guest
|
May I join in?
The hot-swap in Erlang operates differently to shared library reloading
in one aspect which I think you overlooked: *both* the old and new
versions of a hot-loaded module will run in a live system *until* all
the code relying on the module have come to a suitable switching point.
I'll try to explain with an example, a very simple server process that
runs in a loop receiving and acting on messages (which I didn't compile
or run, so it may not even work, so spank me :-)
-module(simple_server).
server() ->
receive
{tagA,Data} ->
%% do A ...
server(); % <<<<<<<<<<<<<<<< case A
{tagB,Data} ->
%% do B ...
simple_server:server(); %<<< case B
end.
The difference between cases A and B is that in case B the server code
will be swapped with a new version if one was loaded at that time
*without stopping*, whereas case A would continue to use the old version
regardless.
I believe that reloading shared libraries will require a fair amount of
runtime code management programmed by hand, and I'm not sure that loops
like this one can be swapped without stopping the server momentarily.
The Erlang version simply never stops, never loses any server state.
I think that the hot-swapping in Erlang is almost (not quite) implicitly
supported, whereas C/C++ the extra work involved in implementing and
debugging such a feature just gets in the way of solving more
interesting problems.
Pete.
Chris Pressey wrote:
> On Wed, 2 Apr 2003 15:16:42 -0600
> Rick Pettit <rpettit_at_vailsys.com> wrote:
>
>
>>On Wed, Apr 02, 2003 at 02:27:34PM -0600, Chris Pressey wrote:
>>
>>>>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.
>>>
>>>But how often does this happen in practice?
>>
>>Perhaps not often in other companies, but I have personnally written
>>shared object libraries that are meant to be loaded/unloaded/reloaded
>>as the implementation behind the interface evolves. Works really
>>well, too, in that C/C++ clients talk to Erlang servers via these
>>shared objects, and as long as the API from C/C++ app to shared object
>>stays the same all sorts of neat changes can take place both on server
>>side (hot code load) and on client side (shared library swap), with NO
>>DOWNTIME!
>
>
> Hey, if it works, more power to you. I'm still in a position where I'm
> working on projects where a couple of minutes of downtime is acceptable,
> so my experience with hot swapped code comes mostly from playing with it
> - and I don't think I've ever written a .so - so I'm out of my element
> here.
>
>
>>[...]
>>My point is that there is NOT a big difference between the two, and
>>that is how Martin should approach the sales pitch with C/C++ guys who
>>argue against hot-code load but are all for shared objects.
>
>
> In light of your success with it - yes indeed.
>
> -Chris
>
>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| jay at duomark.com |
| Posted: Thu Apr 03, 2003 7:09 am |
|
|
|
Guest
|
Rick Pettit wrote:
> Put another way, most all my objects ARE defensive, and
> might as well be placed "on the border". Since this is true,
> I can reuse an internal object on the border without worrying
> about crashes. I can make calls to it from anywhere and know
> that it is well behaved.
>
>The same is NOT true with an Erlang
> module that is coded to crash on bad data since it is not meant
> for border use. It would be a big mistake to use such a module
> in a border case, and thus it is important as an Erlang/OTP
> developer to make crystal clear the distinction.
I have been promoting the use of processes as an interface
mechanism. Precisely because of reuse issues, it is an important
method of integration. Make all your code non-defensive and
use a process at the border to do any data filtering to ensure
that the reusable code doesn't get bad data. You can also use
the filter process to alter the data to match the reusable code's
interface if necessary.
jay
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| etxuwig at etxb.ericsson. |
| Posted: Thu Apr 03, 2003 9:07 am |
|
|
|
Guest
|
On Wed, 2 Apr 2003, Rick Pettit wrote:
>Put another way, most all my objects ARE defensive, and
>might as well be placed "on the border". Since this is
>true, I can reuse an internal object on the border without
>worrying about crashes. I can make calls to it from
>anywhere and know that it is well behaved.
>
>The same is NOT true with an Erlang module that is coded to
>crash on bad data since it is not meant for border use. It
>would be a big mistake to use such a module in a border
>case, and thus it is important as an Erlang/OTP developer
>to make crystal clear the distinction.
Remember that Erlang was designed for environments where
"resetting" is probably a more correct description than
"crashing" -- the program always has to bounce back,
preferrably without the external users noticing.
I think the idea of having defensive interfaces wherever
human (or otherwise external) input is involved is a good
thing, but internal components should assume that the users
of the interface have RTFM and use the component properly.
In any event, misuse of the component should lead to
distinct failures, not mystical semi-correct behaviour.
Thus, the main difference between a component at the
external border and an internal component is not primarily
that one is safe and the other is not, but that one produces
an error message intended for mere mortals, while the other
fails in a way that gives the programmer as much useful
debugging info as possible.
I think it's a mistake to confuse the two, but also always
try to write my code in the same way in both cases. Error
handling in the external interface is taken care of by
catching exceptions at the top and interpreting the
exception information into a human-readable error message.
This top layer will have different semantics depending on
the nature of the interface (window-based GUI, command line,
HTML pages, ...).
I reuse code quite a lot, and I think most Erlang
programmers do (I know one who doesn't believe in reusing
code, since it's so easy to write working erlang programs
from scratch...)
>Of course the code is much smaller when it is not
>defensively coded throughout the application, no argument
>there. But when both sides (i.e. C/C++ and Erlang OTP) are
>coded that way, what is the difference?
>
>I suppose defensively coding EVERYTHING is a bit silly and
>unnecessary, but this is not a strengh/weakness of
>Erlang/OTP, merely a coding practice that can be (or not
>be) applied to any language.
I recently dusted off the book "Writing solid code" by Steve
Maguire, and browsed through it. Very good book, but it
struck me that among the countless good advice on how to
write robust C code, the most of it was not relevant to
Erlang programmers. The book contains lots of sage advice
that's surely relevant regardless of language, but as good
as the book is, it's hardly worth it to plow through 200
pages of C-specific coding advice in order to get to those
pearls.
/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| thomasl_erlang at yahoo.c |
| Posted: Thu Apr 03, 2003 9:28 am |
|
|
|
Guest
|
--- Rick Pettit <rpettit_at_vailsys.com> wrote:
(First, I agree that the word 'crash' is possibly
unfortunate for getting exceptions.)
> > 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?
Misspelled variables are caught by the compiler. (Esp.
if you use warn_unused_vars.)
/.../
> 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.
Here's my opinion at least.
My basic train of thought is this:
* The main benefit of Erlang, Lisp, Prolog, SML and so
on is _type_safeness_: there is no way that you can
accidentally confuse one value's type with another.
This (along with GC and pureness) gets rid of the
majority of errors.
(This is also known as 'strong typing', not to be
confused with 'static typing'.)
* Static typing a la Hindley-Milner (SML, Haskell,
etc) probably helps most when you use higher-order
functions aggressively.
Erlang programs typically do not employ combinators
and suchlike, so the need for such checking is less
here.
Furthermore, static typing does not check concurrency
properties that might be of greater interest to our
sort of applications.
(Model checking etc. seems to be waiting in the wings
for checking that sort of thing.)
* Finally, static typing in the sense above is
prescriptive: it will reject programs that are okay
because it can't prove they are (e.g., heterogenous
lists were rejected for a long time; not sure about
whether it's handled well these days). This may mean
you have to 'code around' the problem, though a static
typing guy might say you are removing a latent bug.
Also, the programming language designers will have to
restrict programs to enable checking (e.g., receive
... end is hard to check in its current form, since
any process can potentially send to any process, as is
hot code loading, for obvious reasons).
Basically, prescriptive typing means you have to
sacrifice some convenience and slow down language
evolution, so that the type checker can keep up. (Some
may think this is a good thing, of course.)
The other, less common, approach is descriptive
typing: permit any program but flag any strangeness. A
sort of "lint-like" approach. This is harder to do
(since the checker has to *follow* difficult code
rather than reject it, and since there is a problem
with false positives due to inaccuracy). Still, I
think it's an interesting approach.
There have been at least four attempts to do this for
Erlang that I know of, but none has really gotten 'out
of the gates'.
* An aside: an interesting difference between Erlang
and SML (say) seems to be that SML programmers appear
to talk more about types and how they should be
designed before coding. This is something I seldom
encounter in writing Erlang programs  I haven't
seen a good summary of the differences, though. (This
thinking seems to be more recent than last time I
really looked at FP.) Maybe it's a "Smalltalk-Java"
difference.
To summarize:
Personally, I find that static typing in its current
form adds little value to my Erlang programming.
Errors due to type mistakes do appear, but not so
frequently as to make it a major problem. The
consequences are exceptions, not core dumps or quiet
madness, so debugging is easier than in the C++ case.
(An opinion: Making Erlang even easier to test would
probably be more pragmatically beneficial than adding
static typing.)
Best,
Thomas
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| jamesh at Volition-inc.co |
| Posted: Thu Apr 03, 2003 3:02 pm |
|
|
|
Guest
|
>> Lisp has grown crusty in certain ways and can be awkward
>> after using more modern functional syntax
>
>the major problem i have with erlang vs lisp is erlangs
>syntax. it is not sufficiently symetric, i suppose
>(i prefer matching start-stop markers). and i have a
>terrible time remembering if i should use ;/, or
>not, in case statements.
Yes, I agree with that. I've wondered how Erlang would be with Python and
Haskell's "significant whitespace" as an alternative to all the commas and
semicolons (ah, the endless debates that would start). Writing a
preprocessor to do the conversion to proper Erlang would be an easy project.
My quibble with Lisp's syntax is less about delimiters and more about the
lack of shortcuts that I've gotten used to:
* Being able to introduce a local without explicitly declaring it and
starting a new indentation level.
* Pattern matching to destructure data into components.
* Tuples, especially using tuples to return multiple values (as opposed to
multiple-value-bind).
James
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Thu Apr 03, 2003 4:36 pm |
|
|
|
Guest
|
On Wed, Apr 02, 2003 at 09:40:37PM -0600, Chris Pressey wrote:
> Hey, if it works, more power to you. I'm still in a position where I'm
> working on projects where a couple of minutes of downtime is acceptable,
> so my experience with hot swapped code comes mostly from playing with it
> - and I don't think I've ever written a .so - so I'm out of my element
> here.
Please don't get me wrong here, I am not arguing in favor of C/C++ over Erlang.
I was merely trying to help Martin clarify his argument. To say Erlang allows
code load on the fly and C/C++ does not, or to say that you _have_ to program
defensively in C/C++ everywhere whereas you only need to do so in border cases
with Erlang is just not true in my opinion.
> > My point is that there is NOT a big difference between the two, and
> > that is how Martin should approach the sales pitch with C/C++ guys who
> > argue against hot-code load but are all for shared objects.
>
> In light of your success with it - yes indeed.
Again, I am just playing devil's advocate here. I would like to see Erlang
succeed...I am sold. My only intent was to _strengthen_ his argument by
playing the other side.
-Rick
P.S. Writing applications which load/unload shared objects on the fly without
crashing or corrupting data in some way is tricky business, particularly
in a multi-threaded environment. I have somehow managed to be successful
in doing so, but with Erlang/OTP I clearly see the light ;-)
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Thu Apr 03, 2003 4:43 pm |
|
|
|
Guest
|
On Thu, Apr 03, 2003 at 08:05:26AM +0100, Peter-Henry Mander wrote:
> May I join in?
Of course you may ;-)
> The hot-swap in Erlang operates differently to shared library reloading
> in one aspect which I think you overlooked: *both* the old and new
> versions of a hot-loaded module will run in a live system *until* all
> the code relying on the module have come to a suitable switching point.
Agreed. I realized this after my post. In either case, as I mentioned to Chris
in a previous mailing, my intent was to strengthen Martin's argument by playing
the other side.
> or run, so it may not even work, so spank me :-)
Would you settle for me "excusing you" :-)
> The difference between cases A and B is that in case B the server code
> will be swapped with a new version if one was loaded at that time
> *without stopping*, whereas case A would continue to use the old version
> regardless.
Agreed. In my (pthread) applications I would need to synchronize the load/unload
via mutex locking, and would NOT be able to easily use a new shared object
while finishing up with the old one. I can almost invision an insane way to
try to do so, but it would involve terrible obfuscation as the two modules
could NOT share the same symbols and still exist in the same process at the
same time, AFAIK. This certainly is a limitation (you getting this, Martin?)
> I believe that reloading shared libraries will require a fair amount of
> runtime code management programmed by hand, and I'm not sure that loops
> like this one can be swapped without stopping the server momentarily.
> The Erlang version simply never stops, never loses any server state.
Agreed. A familiarity with libdl and the dynamic loader is a must to even get
off the ground. Erlangers never need to know about such gory details.
> I think that the hot-swapping in Erlang is almost (not quite) implicitly
> supported, whereas C/C++ the extra work involved in implementing and
> debugging such a feature just gets in the way of solving more
> interesting problems.
Once again, I am in agreement. I must say I am quite happy with the results of
my posting, as this discussion has both cleared a few things up for me and
given Martin more ammo for his argument with the "LM".
-Rick
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Thu Apr 03, 2003 4:46 pm |
|
|
|
Guest
|
On Wed, Apr 02, 2003 at 11:13:22PM -0800, Jay Nelson wrote:
> I have been promoting the use of processes as an interface
> mechanism. Precisely because of reuse issues, it is an important
> method of integration. Make all your code non-defensive and
> use a process at the border to do any data filtering to ensure
> that the reusable code doesn't get bad data. You can also use
> the filter process to alter the data to match the reusable code's
> interface if necessary.
This sounds pretty interesting, though I must sadly admit that I not an
experienced enough Erlang/OTP developer to know if it is the "right thing to
do" or not. It does sound like such an architecture could aid in code
reusability. Since simplicity seems to be a big concern with the Erlang guys
(and rightly so), I would be interested to see what their thoughts are on that.
-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
