ideas about methods returning an object or no object
Eric Marshall
Does anyone have ideas about whether they prefer methods
to return an object, when one exists, or no object when none
exists?
An example is a method which returns an array object containing
the set of employess in a company. If no employees exist, would
you prefer to return an array object containing no elements or to
return no object? I'm interested in the complexity of both
writing
and using methods that follow a specific paradigm.
Thanks in advance.
Eric Marshall
EMI Software Engineering
Laurent Martelli
>>>>> "Eric" == Eric Marshall <er...@EMIEng.com> writes:
Eric> Does anyone have ideas about whether they prefer methods to
Eric> return an object, when one exists, or no object when none
Eric> exists? An example is a method which returns an array
Eric> object containing the set of employess in a company. If no
Eric> employees exist, would you prefer to return an array object
Eric> containing no elements or to return no object? I'm
Eric> interested in the complexity of both writing and using
Eric> methods that follow a specific paradigm.
I don't prefer one or the other. I think that each situation should be
exmained carefully. But certainly you'll find that there are some
patterns.
Talking about return an empty List/Set/Sequence/Array or no
object, I'd certainly prefer returning an empty List. Because you can
use an empty List the same way you use a non-empty List. If you want
to display the returned List, you won't have to test the special case.
--
Laurent MARTELLI
mart...@iie.cnam.fr http://www-eleves.iie.cnam.fr/~martelli
Tom Cooper
Eric Marshall wrote:
> Does anyone have ideas about whether they prefer methods
> to return an object, when one exists, or no object when none
> exists?
> An example is a method which returns an array object containing
> the set of employess in a company. If no employees exist, would
> you prefer to return an array object containing no elements or to
> return no object? I'm interested in the complexity of both
> writing
> and using methods that follow a specific paradigm.
Your example says "a method which returns an array object containing the
set of employees in a company." So that is what I would expect. Not a
null object. I can check for a zero-sized array, or let my loop find
nothing if you return the array. Don't force me to make the special
case test when I don't care.
Robert C. Martin
Eric Marshall wrote:
>
> Does anyone have ideas about whether they prefer methods
> to return an object, when one exists, or no object when none
> exists?
> An example is a method which returns an array object containing
> the set of employess in a company. If no employees exist, would
> you prefer to return an array object containing no elements or to
> return no object? I'm interested in the complexity of both
> writing
> and using methods that follow a specific paradigm.
>
You will enjoy reading the "Null Object" pattern in
"Pattern Languages of Program Design III", Addison Wesley, 1997.
It addresses this problem.
--
**We are looking for good engineers, See our website
**for more information.
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Graham Perkins
Eric Marshall wrote:
> Does anyone have ideas about whether they prefer methods
> to return an object, when one exists, or no object when none
> exists?
> An example is a method which returns an array object containing
> the set of employess in a company. If no employees exist, would
> you prefer to return an array object containing no elements or to
> return no object?
I have slight preference for empty array. But more importantly,
write a post-condition.
First case:
result.length = company.employeeSet.size
Second case:
(result.length = company.employeeSet.size)
or
(company.employeeSet.size=0) and (result=null)
.. of course, you need discipline or language mechanism to always
handle post-conditions appropriately.
Mika Moilanen
"Robert C. Martin" <rma...@oma.com> writes:
>
> You will enjoy reading the "Null Object" pattern in
> "Pattern Languages of Program Design III", Addison Wesley, 1997.
> It addresses this problem.
>
I did enjoy reading http://www.ksccary.com/nullobj.htm, but it left me
empty. NO pattern works well, if you can use 'empty' object, but thats not
all the time the case. I have the following situation: I've a method, which
returns a string it calculates, if it can. I can't use empty string, because
that would lead to false results. Currently I'm returning 0, if string can't
be generated and I have to test that special case. Does anyone have any
suggestion about how to remove that test ? Of course, i can use another
method invocation to check is the string can be produced, but that's not the
main point, or is it ? :)
-mika
Milton L. Hankins {64892}
Tom Cooper wrote:
>
> Eric Marshall wrote:
>
> > Does anyone have ideas about whether they prefer methods
> > to return an object, when one exists, or no object when none
> > exists?
>
> set of employees in a company." So that is what I would expect. Not a
> null object.
> Don't force me to make the special case test when I don't care.
I would test for a special (null) case anyway just to catch the error --
so why not avoid yet another memory allocation?
--
Milton L. Hankins <>< Software Engineer, Raytheon Electronic Systems
"For God so loved the world, that He gave His only begotten Son, that
whosoever believeth in Him should not perish, but have everlasting
life." John 3:16
Joachim Durchholz
Mika,
Let me restate your problem:
- You have a function foo(whatever) that computes a string to be
returned.
- foo() may fail, in which case there is no string to be returned.
- The problem is how to propagate the failure information with minimal
fuss.
1) Return a pointer to a string, or NULL if foo() fails.
Advantage: Works.
Disadvantage: Lots of NULL pointer checks distributed in all the code
that might get to see that result.
2) Use exceptions.
If foo fails, it raises an exception.
Advantage: exceptions are right built into the language, and easy enough
to use in C++.
Disadvantage: Getting exceptions under control can be a nuisance. In
particular if you want to be able to store the fact that there was no
result in a database.
3) Use a wrapper class.
Make foo() return not a string but a MaybeString. MaybeString's
interface looks as follows (pseudocode):
class MaybeString (public String)
Boolean Valid() -- wether there is an actual String inside
end
All String functions are delegated as required: If Valid() is True, they
act like the ordinary String functions, if Valid() is False, they do
some default processing: Length() raises an exception, appending a
string just lets the MaybeString remain invalid, finding a string within
an invalid MaybeString always returns "not found", etc.
Advantages: You can pass around a MaybeString much like an ordinary
string, and you have to check for invalid strings only where there's a
real difference.
Disadvantage: You have to delegate all String functions (and there are
many, and the next release of the vendor of the String class might have
new functions that need delegation code). You can limit yourself to
delegating only those functions that your program actually needs though.
HTH
Joachim
--
Please don't send unsolicited ads.
Pedro Blanco
Mika Moilanen wrote:
>I have the following situation: I've a method, which
>returns a string it calculates, if it can. I can't use empty string, because
>that would lead to false results. Currently I'm returning 0, if string can't
>be generated and I have to test that special case. Does anyone have any
>suggestion about how to remove that test ? Of course, i can use another
>method invocation to check is the string can be produced, but that's not the
>main point, or is it ? :)
I agree it isn't, mainly because you have to work twice and you make
the machine work twice too. So here is my favourite idiom: the 'Maybe'
parameterized class: if you need to write a function that may fail,
instead of maiking it return type 'A' plus some sort o flag, you make
it return type 'Maybe<A>'. The value returned can be tested for
failure, success and, if so, for the result, using the proper methods.
You can also make the 'result' method ensure that there's been
success.
This is not a solution to your quest; there's still a test. But it
makes the use of the particular function safe and self-documented.
(Type 'Maybe' is in Haskell's standard library)
-Pedro
Patrick Logan
In comp.object Milton L. Hankins {64892} <m...@swl.msd.ray.com> wrote:
: I would test for a special (null) case anyway just to catch the error --
: so why not avoid yet another memory allocation?
Because the method can assert that null will not be returned, just as it
can assert that 1,532,346 will not be returned.
Once the assertion (i.e. post-condition) has been asserted then the client
can write the call in a functional style, e.g.
someObject pencils do: [ :eachPencil | eachPencil sharpen]
-rather than-
| pencils |
pencils := someObject pencils.
pencils == nil ifFalse:
[pencils do: [ :eachPencil | eachPencil sharpen]
There is mental anguish in the latter example that is not in the former.
As for memory allocation, this is not likely to be the bottleneck in the
systems I am involved with. YMMV. Esp. since memory allocation may only
need to happen once, e.g.
PencilHolder>>pencils
myPencils == nil ifTrue: [myPencils := IdentitySet new].
^myPencils
--
Patrick Logan (H) mailto:plo...@teleport.com
(W) mailto:patr...@gemstone.com
http://www.gemstone.com
Marc Girod
>>>>> "GP" == Graham Perkins <gper...@dmu.ac.uk> writes:
GP> I have slight preference for empty array. But more importantly,
GP> write a post-condition.
In case of returning a collection, where it makes sense that the
collection may be empty, there is no problem.
What is the statically typed answer to the remaining --and more
general-- problem, which assertions would once again hide? Callbacks.
Make your request "asynchronous" and provide it with two callbacks:
one for the error case, the other for success. Their signatures need
not be the same!
Note that the processing is statically typed _in scope_, whereas the
dynamic nature of the _global_ behaviour is preserved.
Best Regards!
--
Marc Girod Nokia Telecommunications NWS/NMS/NMD/NOMA
Valimo 1/2 P.O. Box 315 Phone: +358-9-511 63331
00380 Helsinki 00045 NOKIA Group Fax: +358-9-511 63310
Finland marc....@ntc.nokia.com
Samantha Atkins
Graham Perkins wrote in message <34D5C5...@dmu.ac.uk>...
>Eric Marshall wrote:
>> Does anyone have ideas about whether they prefer methods
>> to return an object, when one exists, or no object when none
>> exists?
>> An example is a method which returns an array object containing
>> the set of employess in a company. If no employees exist, would
>> you prefer to return an array object containing no elements or to
>> return no object?
I would chose an empty array as that is the only valid return by the way the
problem was defined, "returns an array object containing...". Since that
wording was in the equivalent of the design spec it is obviously against the
spec not to return an array. It is also much simpler to write code that
simply expects and gets an array in all circumstances and then does
something with its contents than to write code that sometimes gets one thing
and sometimes gets another. Why stop with array or no array? Why not
depart further from the spec and in some cases return a database cursor in
case the set of employees is too large to fit conveniently in memory?
Programming is difficult enough when we make contracts and follow them. It
is nigh impossible if we get lost in contextual afterthoughts that lead us
into on-the-fly redesign and special case code.
Samantha Atkins
OO Database Goddess
Kohler Markus
Mika Moilanen wrote:
>
> "Robert C. Martin" <rma...@oma.com> writes:
> >
> > You will enjoy reading the "Null Object" pattern in
> > "Pattern Languages of Program Design III", Addison Wesley, 1997.
> > It addresses this problem.
> >
>
> I did enjoy reading http://www.ksccary.com/nullobj.htm, but it left me
> empty. NO pattern works well, if you can use 'empty' object, but thats not
> returns a string it calculates, if it can. I can't use empty string, because
> that would lead to false results. Currently I'm returning 0, if string can't
> be generated and I have to test that special case. Does anyone have any
> suggestion about how to remove that test ? Of course, i can use another
> method invocation to check is the string can be produced, but that's not the
> main point, or is it ? :)
>
It can be removed...
You can define a new class UndefinedString with just one instance
nilString,
being a subtype of String.
You can use nilString whereever you have to return a String but you
couldn't produce
one. Of course you would have to redefine some methods in
UndefinedString, depending what should be different between String and
UndefinedString.
Markus
--
+----------------------------------------------------------------------------+
| Markus Kohler Hewlett-Packard
GmbH |
| Software Engineer OpenView Software
Division |
| IT/E Response
Team |
+----------------------------------------------------------------------------+
Mika Moilanen
In article <34d7c3c5....@news.arrakis.es>,
p...@arrakis.es (Pedro Blanco) writes:
> This is not a solution to your quest; there's still a test. But it
> makes the use of the particular function safe and self-documented.
>
> (Type 'Maybe' is in Haskell's standard library)
>
>
> -Pedro
I'm a real fan of type-safing ( and templates ). This idiom seems to be
a good one ( of course, if it's an idiom :)), but i think i was refusing to
understand application domain's concept: i'm using <string>s and i have to
follow the rules about how i can construct the string. In some situations,
its possible, sometimes not. (like searching the string). If its possible, i
can use it, if not, i can't. Currently i'm returning a pointer to a string
or 0 (NULL) and i have to test against 0 pointer. It's simple, there's no
memory leaks and fast. Of course, i could test string.size() == 0, but that
invokes more computation. I like to use lots of pointers but i also know the
problems. That was why i was wondering other ideas, but i guess when the
speed is the major concern, we've to use whatever machine gives us. Sad, but
true :)
- mika
Risto Lankinen
Hi!
Mika Moilanen <mik...@rotol.ramk.fi> wrote in article
<6b75rf$3qi$1...@ankka.csc.fi>...
>
> I've a method, which returns a string it calculates, if it can.
> I can't use empty string, because that would lead to false results.
Toss an exception if the string cannot be calculated.
terv: Risto Lankinen
jfb3
Samantha Atkins wrote:
> Programming is difficult enough when we make contracts and follow them. It
> is nigh impossible if we get lost in contextual afterthoughts that lead us
> into on-the-fly redesign and special case code.
>
> Samantha Atkins
> OO Database Goddess
Perfect!
I've been trying to come with a phrasing for this thought for days now.
John
Mika Moilanen
In article <01bd31f8$292c9540$01010101@rlankine-hpc>,
the situation i want to use exception (i.e. it's not an error of any kind,
just reason to stop the program).
t mika
Patrick Logan
In comp.object Mika Moilanen <mik...@rotol.ramk.fi> wrote:
: if a string cannot be calculated that means we've reached the end. It is not
: the situation i want to use exception (i.e. it's not an error of any kind,
: just reason to stop the program).
Exception != Error
(Exception >= Error) == true
That is, an exception is a non-local exit. Sometimes it is used for an
error and sometimes it is simply used as an, er, "exception".
// Java...
String string;
try {
string = calculateString();
} catch (StringCalculationReachedTheEnd atEndException) {
...do something else instead...
Isaac
In my opinion, exceptions should be used for exceptional conditions. If the
fact that the string cannot be calculated is part of normal processing, then
using an exception seems to me to abuse the notion of exceptions.
Isaac D. Mounce
Patrick Logan wrote in message <6ccf43$8sc$1...@news1.teleport.com>...
Phlip
Isaac wrote:
>In my opinion, exceptions should be used for exceptional conditions.
If the
>fact that the string cannot be calculated is part of normal
processing, then
>using an exception seems to me to abuse the notion of exceptions.
Never use exceptions for normal flow. Following this advice, DAO
should not throw an error for problems as lame as File Not Found.
The SOP in C++ should be to return a '::std::pair<bool, Object>'. If
the bool is true the Object may be referenced; if not it should be
ignored. I think I will try this the very next time the situation
arises.
-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======
-- Explain to me again why limousines are allowed in carpool
lanes... --
Patrick Logan
In comp.object Isaac <is...@flash.net> wrote:
: In my opinion, exceptions should be used for exceptional conditions. If the
: fact that the string cannot be calculated is part of normal processing, then
: using an exception seems to me to abuse the notion of exceptions.
You are not alone. However you are missing a good tool from your toolbox.
Perhaps your reasoning comes from a sense of throwing exceptions being
somehow a "heavyweight" construct? That is, it requires defining an
exception, putting it in an appropriate place (file), compiling it, etc.
I think it is useful to have one or two exceptions "pre-defined" in
languages that require relatively elaborate definitions of exceptions
(e.g. Java, C++, some Smalltalks). This convention of having them "ready
to go" makes them feel not so heavy, neither in terms of the effort to use
them, nor in terms of the "implications" of the "seriousness" of their
use.
"Exceptional conditions" do not have to be "end of the world" scenarios.
They can simply be "bzzzt, next contestant" scenarios. catch/throw are
nothing more than control flow mechanisms. They allow you not to have to
create "funny" meanings ("flags") and tests for values that are "not
normal".
Patrick Logan
In comp.object Phlip <te...@deltanet.com> wrote:
: Never use exceptions for normal flow. Following this advice, DAO
: should not throw an error for problems as lame as File Not Found.
: The SOP in C++ should be to return a '::std::pair<bool, Object>'. If
: the bool is true the Object may be referenced; if not it should be
: ignored. I think I will try this the very next time the situation
: arises.
OK. ince Phlip's is the second post I've seen this morning making the same
suggestion (which I disagree with), let's dig a bit deeper...
Handling an exception for this problem could look like this:
String str;
try {
str = calculateString();
doSomethingMore();
} catch (CannotCalculate e) {
doSomethingElse();
}
Handling a pair could look like this (I have no idea what ::std::pair
looks like. Let's assume it is a struct with a first and a second field
for the sake of this psuedo code example...
String str;
Pair p = calculateString();
if (p.first) {
doSomethingMore();
} else {
doSomethingElse();
}
These two pieces of code look very similar, except the one with exceptions
tells me more information about *why* I would choose to doSomethingElse.
It reads "do something else if it cannot calculate the string".
Phlip
Patrick Logan wrote:
>String str;
>try {
> str = calculateString();
> doSomethingMore();
>} catch (CannotCalculate e) {
> doSomethingElse();
>}
>Pair p = calculateString();
>if (p.first) {
> doSomethingMore(p.second);
>} else {
> doSomethingElse();
>}
>
>These two pieces of code look very similar, except the one with
exceptions
>tells me more information about *why* I would choose to
doSomethingElse.
>It reads "do something else if it cannot calculate the string".
For a _real_ debate about whether to use C++ exceptions for normal
control flow, try this on J.Kanze or Herb Sutter.
While I am the first to agree for any kind of self-documenting code,
in this case I will leverage my admittedly copious experience with
DAO. I am sick and tired of coding bizarre contortions to turn an
exception back into an 'if' statement. You describe the situation
where you control the contents of the function and can pick and chose
how it returns - you are not locked in by a bogus library. You have
the chance here to do it the right way!
|-p
-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======
-- Work is the source of the root of all evil --
Joachim Durchholz
Patrick Logan wrote:
>
> In comp.object Phlip <te...@deltanet.com> wrote:
>
> : The SOP in C++ should be to return a '::std::pair<bool, Object>'. If
> : the bool is true the Object may be referenced; if not it should be
> : ignored. I think I will try this the very next time the situation
> : arises.
>
> OK. ince Phlip's is the second post I've seen this morning making the
> same suggestion (which I disagree with), let's dig a bit deeper...
>
>
> exceptions tells me more information about *why* I would choose to
> doSomethingElse.
> It reads "do something else if it cannot calculate the string".
Nothing prevents you from using a
::std::pair<struct ErrorReport, Object>
This has the nice advantage that you can put arbitrary stuff into the
ErrorReport struct. You could also use a class instead of a struct,
taking advantage of similarities in error causes (if there are any).
Regards,
Patrick Logan
In comp.object Phlip <te...@deltanet.com> wrote:
: >These two pieces of code look very similar...
: For a _real_ debate about whether to use C++ exceptions...
I am actually addressing exception handling in the ideal, I am not
familiar with C++ exception handling. This ideal fits the languages in
which I have used exceptions: Smalltalk, Java, Lisp.
: You describe the situation
: where you control the contents of the function and can pick and chose
: how it returns - you are not locked in by a bogus library. You have
: the chance here to do it the right way!
Well, yes. We are discussing how we would design a new method with a
certain set of requirements. I cannot address any idiosyncracies unless
they are made explicit in the discussion.
Greg P. Gibson
Isn't this more an issue of how responsibility is partitioned? It is
not the using code's decision about how the used routine is written;
that decision should be based on what responsibilities the used routine
is to support.
For the example, if the routine is only supposed to parse a string,
then if it can't perform its responsibility, then it should throw an
exception. If it is supposed to allow for the case where there is
no more string left to parse, then passing an additional argument
back with that status is acceptable.
Whether the using code considers the case where the string cannot be
parsed as normal processing or not is irrelevant to the used routine.
--
Greg P. Gibson Inet: gib...@agcs.com, http://www.agcs.com
AG Communication Systems Talk: 602-582-7524 Fax: 602-582-7697
Phoenix, AZ 85072-2179 "Expand the power of your network"
Steven D. Majewski
>
>(Exception >= Error) == true
>
>That is, an exception is a non-local exit. Sometimes it is used for an
>error and sometimes it is simply used as an, er, "exception".
In article <6cg65s$77p$1...@excalibur.flash.net>, Isaac <is...@flash.net> wrote:
>In my opinion, exceptions should be used for exceptional conditions. If the
>fact that the string cannot be calculated is part of normal processing, then
>using an exception seems to me to abuse the notion of exceptions.
If the condition occurs significantly less than 80% of the time
( which is quite typical of exiting an inner loop ), then,
by definition, it's an "exceptional condition".
It's a pretty context dependent notion.
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---
All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson
Tim Ottinger
I prefer to think of an exception as an unpredictable response. For
instance, if you have a 'find' routine, then you may find something or
may not. That's pretty reasonable and predictable. But if the structure
is corrupt, then that's not reasonably and predictable. It's a real problem.
Then there is the second perspective to consider, that an exception is
a cry for help. The routine could not do what it wanted, and cannot
determine what the correct next action should be. Does it abort?
Retry? Fail? What? If it doesn't know what to do, it must call for
help from the outside. The 'find' example also fits this. Not finding
something won't be changed by throwing an exception. The object
is not there, and that's all there is to it.
I think these two rules are pretty good guidance, if taken together.
Of course, in Python you throw exceptions whenever you darned
well please... :-) (just a joke, take it easy).
Tim
Dave Harris
sd...@elvis.med.Virginia.EDU (Steven D. Majewski) wrote:
> If the condition occurs significantly less than 80% of the time
> ( which is quite typical of exiting an inner loop ), then,
> by definition, it's an "exceptional condition".
To take another example, if you keep reading from a file you'll eventually
reach the end of it. This suggests to me that end-of-file is not an
exceptional case - it happens on most every file eventually - even though
it might be on one read out of 1000.
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
Patrick Logan
Dave Harris <sc...@btinternet.com> wrote:
: sd...@elvis.med.Virginia.EDU (Steven D. Majewski) wrote:
: > If the condition occurs significantly less than 80% of the time
: > ( which is quite typical of exiting an inner loop ), then,
: > by definition, it's an "exceptional condition".
: To take another example, if you keep reading from a file you'll eventually
: reach the end of it. This suggests to me that end-of-file is not an
: exceptional case - it happens on most every file eventually - even though
: it might be on one read out of 1000.
So do you think it is right or wrong to use exceptions for end of file?
In either case, do you think it is beneficial to also provide a predicate
for detecting this condition?
For any exceptional situation that can be detected before invoking the
method, do you think the object should also provide a predicate for
detecting that condition beforehand?
Patrick Logan
In comp.object Tim Ottinger <otti...@oma.com> wrote:
: I prefer to think of an exception as an unpredictable response. For
: instance, if you have a 'find' routine, then you may find something or
: may not. That's pretty reasonable and predictable. But if the structure
: is corrupt, then that's not reasonably and predictable. It's a real problem.
: Then there is the second perspective to consider, that an exception is
: a cry for help. The routine could not do what it wanted, and cannot
: determine what the correct next action should be. Does it abort?
: Retry? Fail? What? If it doesn't know what to do, it must call for
: help from the outside. The 'find' example also fits this. Not finding
: something won't be changed by throwing an exception. The object
: is not there, and that's all there is to it.
: I think these two rules are pretty good guidance, if taken together.
These rules seem to be appying connotations to denotational mechanisms.
What I mean is "throw" is a language mechanism. It has a denotational
semantics that cannot be misinterpreted. The language designers have
assigned this meaning and there is no arguing with it.
What you are doing is applying connotations to these mechanisms. "Throwing
an exception is the equivalent of crying for help."
I would encourage you to drop the connotations and see the mechanisms as
engineering tools. An exception is a non-local change of the flow of
control. No more and no less.
Now the issue to consider is what is the engineering cost/benefit of
changing the flow of control using these mechanisms? The cost/benefit
drives the principles that an engineer would follow when choosing which
mechanisms to use to achieve a desired affect.
Jay Martin
Patrick Logan wrote:
>
> In comp.object Tim Ottinger <otti...@oma.com> wrote:
> : I prefer to think of an exception as an unpredictable response. For
> : instance, if you have a 'find' routine, then you may find something or
> : may not. That's pretty reasonable and predictable. But if the structure
> : is corrupt, then that's not reasonably and predictable. It's a real problem.
>
> : Then there is the second perspective to consider, that an exception is
> : a cry for help. The routine could not do what it wanted, and cannot
> : determine what the correct next action should be. Does it abort?
> : Retry? Fail? What? If it doesn't know what to do, it must call for
> : help from the outside. The 'find' example also fits this. Not finding
> : something won't be changed by throwing an exception. The object
> : is not there, and that's all there is to it.
>
> : I think these two rules are pretty good guidance, if taken together.
>
> These rules seem to be appying connotations to denotational mechanisms.
>
> What I mean is "throw" is a language mechanism. It has a denotational
> semantics that cannot be misinterpreted. The language designers have
> assigned this meaning and there is no arguing with it.
Denotional Semantics? Bah! Pretty much useless.
You are throwing away the reason for a feature and what its legitimate
uses are for some minimal mathematical definition, not a good idea.
> What you are doing is applying connotations to these mechanisms. "Throwing
> an exception is the equivalent of crying for help."
> I would encourage you to drop the connotations and see the mechanisms as
> engineering tools. An exception is a non-local change of the flow of
> control. No more and no less.
Software engineering is really social science. Its what "connotations"
produce the best results given the set of dimwits. Excessive mixing
mathematical style thought with software thought processes can be
counterproductive which is why most of academics in CS who goes
down this path don't produce practical results. IMHO, good programming
comes mostly from "restraint". Lack of "restraint" makes code hard to
read and programming is alot about communication. Mathematics is not
about "restraint" it is a no holds barred endeavor to prove a result.
> Now the issue to consider is what is the engineering cost/benefit of
> changing the flow of control using these mechanisms? The cost/benefit
> drives the principles that an engineer would follow when choosing which
> mechanisms to use to achieve a desired affect.
We will tell you that SE cost benefits of using exceptions
as an alternate means of normal flow control is not productive and this
is pretty much the opinion of the majority of experts in software
engineering languages including the language desiners. If programmers
are rampantly going to use exceptions as normal flow control, then I would
prefer languages not to have exceptions.
Jay
Tim Ottinger
Patrick Logan wrote:
> In comp.object Tim Ottinger <otti...@oma.com> wrote:
> : I prefer to think of an exception as an unpredictable response. [...]
> : Then there is the second perspective to consider, that an exception is
> : a cry for help. The routine could not do what it wanted, and cannot
> : determine what the correct next action should be. Does it abort?
> : Retry? Fail? What? If it doesn't know what to do, it must call for
> : help from the outside.[...]
> : I think these two rules are pretty good guidance, if taken together.
>
> These rules seem to be appying connotations to denotational mechanisms.
> [...] What you are doing is applying connotations to these mechanisms. "Throwing
>
> an exception is the equivalent of crying for help."
Those are the situations I would use exceptions in, and they match the
ways I've seen exceptions used to advantage in code and in articles,
and the ways I've heard them recommended in many places by many
people I trusted.
Sure it's a non-local change in the flow of control, but that doesn't say
how we can think about them to use them well. It's just a definition.
I thought the poster was looking for advice/suggestions.
Tim
Patrick Logan
In comp.object Jay Martin <jaymm...@earthlink.net> wrote:
: Denotional Semantics? Bah! Pretty much useless.
: You are throwing away the reason for a feature and what its legitimate
: uses are for some minimal mathematical definition, not a good idea.
So you are saying you do not really on how a mechanism is specified?
How is it that you can read a program and know what it will do?
If you program in C how can you know that after the following statement,
the variable i will have the value 10:
for (i = 0; i < 10; i++);
The only way to know this is to know the semantics of the "for" statement.
You may be turned off by formality, but without it you could not get
your work done. I thrive on formality. Most problems I see in software
development are due to lack of formality.
(Note that formality does not mean "high ceremony" in the Booch sense.
Formality means "well defined".)
: Software engineering is really social science.
Maybe you are concerned with the social aspects of software development. I
share that concern. One aspect of our (American) society is a fear of
formality. Certainly there is more to software engineering than the social
aspects. Eventually descriptions are executed by a machine. The describer
had better have a good formal definition of how to describe that
computation.
: ...academics in CS... don't produce practical results.
It seems to me you have such a large bone to pick with "academics in CS"
that you have thrown the baby out with the bath water. (If you'll allow me
to mix metaphors.)
: IMHO, good programming comes mostly from "restraint".
Maybe so. But restraint can be based on engineering principles derived
from the semantics of a language mechanism. Restraint does not have to be
based on emotional connotations of a language mechanism. That is my point.
No more, no less.
: Mathematics is not
: about "restraint" it is a no holds barred endeavor to prove a result.
Hmm. I am talking about software engineering, not mathematics. Who said
anything about mathematics?
: We will tell you that SE cost benefits of using exceptions
: as an alternate means of normal flow control is not productive...
Who is "we"? What are these "costs" you seem to be so aware of? What
language are you referring too? References?
: If programmers
: are rampantly going to use exceptions as normal flow control...
Who said anything about "rampantly using exceptions as normal flow of
control"? What does "rampant" mean in this context? I am talking about
understanding the meaning of a contruct and developing a set of principles
and a rationale for its use. Is this such a strange approach to take in
software engineering?
Nicholas Kitchener
> You may be turned off by formality, but without it you could not get
> your work done. I thrive on formality. Most problems I see in software
> development are due to lack of formality.
>
> (Note that formality does not mean "high ceremony" in the Booch sense.
> Formality means "well defined".)
> : We will tell you that SE cost benefits of using exceptions
> : as an alternate means of normal flow control is not productive...
>
> Who is "we"? What are these "costs" you seem to be so aware of? What
> language are you referring too? References?
>
> : If programmers
> : are rampantly going to use exceptions as normal flow control...
>
> Who said anything about "rampantly using exceptions as normal flow of
> control"? What does "rampant" mean in this context? I am talking about
> understanding the meaning of a contruct and developing a set of principles
> and a rationale for its use. Is this such a strange approach to take in
> software engineering?
Your assuming the programmer has documented all the exceptions.
Nick.
--
Nicholas Kitchener, Software Engineer, Logica UK
Marc Girod
>>>>> "PL" == Patrick Logan <plo...@user2.teleport.com> writes:
PL> These rules seem to be appying connotations to denotational mechanisms.
PL> What I mean is "throw" is a language mechanism. It has a denotational
PL> semantics that cannot be misinterpreted. The language designers have
PL> assigned this meaning and there is no arguing with it.
PL> What you are doing is applying connotations to these mechanisms. "Throwing
PL> an exception is the equivalent of crying for help."
PL> I would encourage you to drop the connotations and see the mechanisms as
PL> engineering tools. An exception is a non-local change of the flow of
PL> control. No more and no less.
Yes!!! Thanks for this formulation.
This is an advice which should be listened to in many other cases,
e.g. inheritance vs. IS_A, private vs. implementation etc.
PL> Now the issue to consider is what is the engineering cost/benefit of
PL> changing the flow of control using these mechanisms? The cost/benefit
PL> drives the principles that an engineer would follow when choosing which
PL> mechanisms to use to achieve a desired affect.
What we are facing in the case of exceptions, is a reconsideration of
the advantages of structured programming blocks (one entry and one
exit point).
In many cases, allowing for multiple returns would allow for tighter
typing: return a real string after a search, or an error; return a
prime number etc. This allows for statically enforcing assertions
within some scopes, based on splitting responsibilities in an explicit
manner.
Exceptions may be a way to provide multiple exit points, although they
were not intended for that, and may be inefficient at it. The need is
however much wider!
Structured programming is also bound to "synchronous programming":
time is irrelevant between the entry and the only exit.
The need for asynchrony is the second reason (after the emergence of
static user defined types, mentioned above), for reconsidering it.
Jay Martin
> : You are throwing away the reason for a feature and what its legitimate
> : uses are for some minimal mathematical definition, not a good idea.
>
> So you are saying you do not really on how a mechanism is specified?
> How is it that you can read a program and know what it will do?
Informal definition of what the language feature does.
The point here is that if you just look at the low level semantics
of a feature, you will miss the high level meaning, reason for its
existance and proper uses of the feature.
> If you program in C how can you know that after the following statement,
> the variable i will have the value 10:
>
> for (i = 0; i < 10; i++);
>
> The only way to know this is to know the semantics of the "for" statement.
Informal semantics.
>
> You may be turned off by formality, but without it you could not get
> your work done.
Practically nobody knows or cares about formal semantics (in fact it is
pretty much a dead field) yet it is necessary to do work???
Formal semantics is usually pages and pages of obtuse mathematical
notation (of which I have done). I don't think its useful.
Am I suppose to feel good that someone did some math?
> I thrive on formality.
Weirdness!
> Most problems I see in software
> development are due to lack of formality.
I think you are confusing "lack of formality" with chaos. I don't see the
problems with SE as being a lack of formality.
> (Note that formality does not mean "high ceremony" in the Booch sense.
> Formality means "well defined".)
Well gee then non-formal would mean "not well defined".
Software and languages can be specified without going overboard on
formality.
> : Software engineering is really social science.
>
> Maybe you are concerned with the social aspects of software development. I
> share that concern. One aspect of our (American) society is a fear of
> formality. Certainly there is more to software engineering than the social
> aspects. Eventually descriptions are executed by a machine. The describer
> had better have a good formal definition of how to describe that
> computation.
We don't need a formal definition. Software is constructed today without
it. I, like most programmers, find informal ones easier to read and understand.
> : ...academics in CS... don't produce practical results.
>
> It seems to me you have such a large bone to pick with "academics in CS"
> that you have thrown the baby out with the bath water. (If you'll allow me
> to mix metaphors.)
And one reason is that they get too silly with overly "formal" and
theoretical approaches. To me, this shows they do not really
understand software construction which is understandable as
they usually have zero "programming in the large" experience.
> : IMHO, good programming comes mostly from "restraint".
>
> Maybe so. But restraint can be based on engineering principles derived
> from the semantics of a language mechanism. Restraint does not have to be
> based on emotional connotations of a language mechanism. That is my point.
> No more, no less.
Its a dangerous point, in my view. You were arguing that if the
semantics of the language says you can do X, then great! Do X.
Lets take all the experience about when to do X and flush it
down the toilet.
"Engineering priciples derived from semantics" is not really a useful
concept. Language semantics are not going to magically specify
how good programs should be written. The emotional and intuitive connotations
are of primary importance and clarify to the programmer how the feature
should be used in real software.
Should I annoy other programmers with my "creative" use of language
features? By "restraint" I mean one should program in a highly
limited and well known number of software patterns
and err towards a less flamboyant style. Its a game, how stupid and
straightforward can my code be without getting too much in the way or
cause too much programming overhead. As you can guess, I do not like
"loose" languages and software philosophies. Interestingly, one can
specify harsher constraints informally.
> : We will tell you that SE cost benefits of using exceptions
> : as an alternate means of normal flow control is not productive...
>
> Who is "we"? What are these "costs" you seem to be so aware of? What
> language are you referring too? References?
The software engineering languages with exceptions:
C++: Read Stroustrup "The C++ Prog Lang 2nd".
Ada: Read the Official "Ada95 Quality and Style Guide"
Eiffel: Read Meyers OSC2
Costs : Ever heard of "Gotos"? Readability. Performance costs.
Languages biased towards software engineering usually have a
more "restraint" oriented outlook in their design and user
communities.
> : If programmers
> : are rampantly going to use exceptions as normal flow control...
>
> Who said anything about "rampantly using exceptions as normal flow of
> control"? What does "rampant" mean in this context? I am talking about
> understanding the meaning of a contruct and developing a set of principles
> and a rationale for its use. Is this such a strange approach to take in
> software engineering?
Okay here is a detection algorithm for incompetent (rampant) use of execeptions:
Use a tool to replace all "raise"'s and "exception handlers" with "aborts".
Run all "normal" use tests on the program excluding such things as
out of memory, out of disk space, types of tests. User input is always
normal. As usual with anything useful, there are no "formal" definitions
of what an error test case is.
The tests should run to completion as no exceptions should occur.
Which means a software product should work without exceptions.
Bottom Line: Exceptions should be viewed as pretty much "useless" outside
their very limited domain.
Jay
Joachim Durchholz
Patrick Logan wrote:
>
> So do you think it is right or wrong to use exceptions for end of
> file?
Badly wrong.
> In either case, do you think it is beneficial to also provide a
> predicate for detecting this condition?
Definitely.
> For any exceptional situation that can be detected before invoking the
> method, do you think the object should also provide a predicate for
> detecting that condition beforehand?
Yes. In fact I feel exceptions are justifiable only if it is impossible*
to determine the failure condition beforehand.
*) Impossible may also mean "determining wether the call will fail
amounts to the same processing overhead as actually computing the result
and failing". The canonical example is matrix inversion, where
determining wether a matrix is singular (non-invertible) or not does
most of the work required for actually inverting it.
Patrick Logan
In comp.object Jay Martin <jaymm...@earthlink.net> wrote:
: > Most problems I see in software
: > development are due to lack of formality.
: I think you are confusing "lack of formality" with chaos.
No. I meant what I said.
: Software and languages can be specified without going overboard on
: formality.
Oh. Well then I take back that suggestion about going overboard being
good.
: Its a dangerous point, in my view. You were arguing that if the
: semantics of the language says you can do X, then great! Do X.
Nope. I was arguing that if the semantics of a language says that "X can
be done" then a set of principles be established indicating when X
*should* be done.
: "Engineering priciples derived from semantics" is not really a useful
: concept. Language semantics are not going to magically...
Sorry. I thought we were discussing engineering, not magic.
: The emotional and intuitive connotations
: are of primary importance and clarify to the programmer how the feature
: should be used in real software.
I disagree. One's intuition, if it is not informed by the real semantics
of the language, may lead one away from what may be not only possible but
also well founded.
Tim Ottinger
Joachim Durchholz wrote:
> Patrick Logan wrote:
> >
> > So do you think it is right or wrong to use exceptions for end of
> > file?
>
> Badly wrong.
I agree with this in C++ (though I might vary my answer for Pythonor other
languages, where the local style is different). There are really
few absolute constant "right" and "wrong" answers across all languages.
I'd mentioned that I don't think exceptions (in C++) are typically used
for normal and easily expected (run of the mill) returns. A read is expected
to return a value or an EOF. Any other response might possibly be well-
suited to be returned as an exception.
In a more dynamic language, I might use exceptions for this without
blinking or flinching at all. It's just not the normal C++ way of doing
things.
> > For any exceptional situation that can be detected before invoking the
> > method, do you think the object should also provide a predicate for
> > detecting that condition beforehand?
>
> Yes. In fact I feel exceptions are justifiable only if it is impossible*
> to determine the failure condition beforehand.
>
> *) Impossible may also mean "determining wether the call will fail
> amounts to the same processing overhead as actually computing the result
> and failing". The canonical example is matrix inversion, where
> determining wether a matrix is singular (non-invertible) or not does
> most of the work required for actually inverting it.
Of course, it's obviously possible to determine that such a thing might
occur, since you have to catch exceptions, and have a throw specifier.
But the idea is that the routine cannot do anything about the "problem",
and so it is given back to the caller, who is expected to have enough
context to determine what to do.
I referred to this as a "call for help" and was chastised for it, though
Whether one considers these connotations to be accurate or not, one
might consider that they accurately describe a perspective that might
be useful.
Since this is not a C++ group, though, let me say that "when in Rome
you do as the Romans do". If Python experts use exceptions for this,
then do it in python. If the best Java, Smalltalk, Eiffel, etc code do it,
then do it. If they don't then find out why. Languages and their
associated cultures usually grow they way they do for reasons.
Tim
S. Ramesh
On Mon, 02 Mar 1998 16:18:53 -0600, Tim Ottinger <otti...@oma.com>
wrote:
>
>
>Joachim Durchholz wrote:
>
>> Patrick Logan wrote:
>> >
>> > So do you think it is right or wrong to use exceptions for end of
>> > file?
>>
>> Badly wrong.
>
>I agree with this in C++ (though I might vary my answer for Pythonor other
>languages, where the local style is different). There are really
>few absolute constant "right" and "wrong" answers across all languages.
>
>I'd mentioned that I don't think exceptions (in C++) are typically used
>for normal and easily expected (run of the mill) returns. A read is expected
>
>to return a value or an EOF. Any other response might possibly be well-
>suited to be returned as an exception.
>
>In a more dynamic language, I might use exceptions for this without
>blinking or flinching at all. It's just not the normal C++ way of doing
>things.
>
I think you have pointed to one of the key issues here. In a dynamic
language like Smalltalk, exceptions are very useful constructs,
allowing many different layers to react a particular exceptional case.
Because exceptions are 1st class objects in Smalltalk, besides being
caught and handled, they can also specify any type of behaviour when
not handled, and this is what, I think makes exceptions such a
powerful and useful way to change the flow of control in Smalltalk
I have built a number of systems in Smalltalk which had highly layered
architectures. In this type of system, an attempt, for instance, to
read beyond the end of the file stream, generated an exception at the
level of the file subsystem. Various layers through the application
could catch the 1st exception, and either send a new exception or
modify and resend the old one..
Thus a headless version of an app could log exceptions to a file,
while various application layers would generate technical messages to
be logged, user messages to be displayed, and perhaps security alerts.
The result was that the user got error messages that made sense for
their application context, while all technical information was
preserved.
Some exceptions, if not handled were able to attempt to correct the
situation themselves. For example a file subsystem might generate an
exception on trying to read a non-existent file, while an app
subsystem, if the user had sufficient authority, would trap the 1st
exception and signal a new exception that if not caught would create
the file and restart the original message send.
I don't mean to suggest that this type of architecture would be a good
idea in C++, but in dynamic languages, exceptions come into their own.
Just my two cents,
Ramesh
Patrick Logan
Tim Ottinger <otti...@oma.com> wrote:
: I referred to this as a "call for help" and was chastised for it...
Sorry. (Since I was the one doing the chastising.)
: Whether one considers these connotations to be accurate or not...
: ...Languages and their
: associated cultures usually grow they way they do for reasons.
In my chastising (oops) I was trying to point out the benefit of shedding
the culture and examining the mechanism itself.
Tim Ottinger
Patrick Logan wrote:
> : I referred to this as a "call for help" and was chastised for it...
>
> Sorry. (Since I was the one doing the chastising.)
'Sokay. I much prefer being chastised by people I respect.
> : Whether one considers these connotations to be accurate or not...
> : ...Languages and their
> : associated cultures usually grow they way they do for reasons.
>
> In my chastising (oops) I was trying to point out the benefit of shedding
> the culture and examining the mechanism itself.
And this is valid also. A little exposure to smalltalk and python have
really helped me do work that would have been a little more difficult
in the C++ culture, but there is the inherent danger that it will harder
to understand to someone from the perspective of a C++ culture.
Sigh.
But as you said, it's all cost/benefit. There is a reduced cost to code
that is readable on its own, but when it is too expensive and the benefit
is great, we need to switch paradigms and perspectives. In the normal
case, you write to an audience and consider their perspectives.
Tim
Jay Martin
I find this "culture" talk pretty disturbing. These guidelines are not
promoted by Stroustrup, Meyers, design teams of Ada83/Ada95, etc because
of some fanciful whim and hard to break bad habits, but by
understanding of "programming in the large" issues. Its not merely that
it
becomes a "cultural goof" in X language that such advice should be
heeded, but
real underlying software issues. Of course everything should be
questioned, but
for everyone to dismiss the opinions of these experts is really silly
("I am a genius and these guys are all morons"). Pointing to the
underlying
semantics: "Exception raised here, blows off stack frames, until caught
in
"exception handler" there", does not say much about how the feature
should be used.
Of course, "programming in the small", prototyping, exploratory
programming and RAD
and related languages have different needs and a freer style, but
"programming in large"
is where the "shit hits the fan" and thus is usually the context where
these issues
are discussed.
Jay
Ell
Jay Martin (jaymm...@earthlink.net) wrote:
:
: Tim Ottinger wrote:
: >
: > Patrick Logan wrote:
: Of course, "programming in the small", prototyping, exploratory
: programming and RAD
: freer style, but
: "programming in large"
: is where the "shit hits the fan" and thus is usually the context where
: these issues
: are discussed.
In my opinion, something their adherence to solipism, and craftite
"diving right in" underscores they really *understand* little about.
Elliott
--
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
"The domain object model is the foundation of OOD."
Check out SW Modeller vs SW Craftite Central : www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
Tim Ottinger
Tim Ottinger wrote:
> Patrick Logan wrote:
>
> > : I referred to this as a "call for help" and was chastised for it...
> >
> > Sorry. (Since I was the one doing the chastising.)
>
> 'Sokay. I much prefer being chastised by people I respect.
In retrospect, this doesn't read the way I meant it to. I meant
taht I prefer to be chastised by people I respect, like Patrick
Logan. I did NOT mean to say I prefer people I respect to
the likes of Mr. Logan!
Just wanted to make sure this was read correctly.
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: Of course everything should be questioned...
Not only should everything be questioned, everything should be
_understood_.
: for everyone to dismiss the opinions of these experts is really silly
I am not suggesting dismissing their opinions. I am suggesting that we
should understand the reasons for their opinions.
: ("I am a genius and these guys are all morons").
I will be the first to tell you I am not a genius and they are not morons.
That does not mean reasonable people cannot disagree about something.
: Of course, "programming in the small", prototyping, exploratory
: programming and RAD... but "programming in the large"...
Of course it is not all one or the other. I understand your concern for
programming in the large. But every problem cannot be reduced to the
social problems of software teams.
Patrick Logan
Tim Ottinger <otti...@oma.com> wrote:
: Tim Ottinger wrote:
It was a better lesson for me when I read it the other way! 8^/
Graham Hughes
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Jay" == Jay Martin <jaymm...@earthlink.net> writes:
Jay> I find this "culture" talk pretty disturbing. These
Jay> guidelines are not promoted by Stroustrup, Meyers, design
Jay> teams of Ada83/Ada95, etc because of some fanciful whim and
Jay> hard to break bad habits, but by understanding of
Jay> "programming in the large" issues. Its not merely that it
Jay> becomes a "cultural goof" in X language that such advice
Jay> should be heeded, but real underlying software issues. Of
Jay> course everything should be questioned, but for everyone to
Jay> dismiss the opinions of these experts is really silly ("I am
Jay> a genius and these guys are all morons"). Pointing to the
Jay> underlying semantics: "Exception raised here, blows off stack
Jay> frames, until caught in "exception handler" there", does not
Jay> say much about how the feature should be used.
I don't think you quite understand the culture remark completely.
I'll use an example, to help illustrate.
Suppose I want to write a factorial function (to flog a dead horse :-).
In Ada, I might write this as
function Factorial(N : in Integer) : Integer is
Result : Integer;
begin
for Count in 1 .. N
loop
Result := Result * Count;
end loop;
return Result;
end Factorial;
This is classic imperative style. However, a functional language like
Scheme might do it this way:
(define (factorial n)
(define (inner-factorial running n)
(if (<= n 1)
running
(inner-factorial (* running n) (- n 1))))
(inner-factorial 1 n))
If you don't like Scheme, the same in Haskell looks like
factorial n = innerfact 1 n
where innerfact run 0 = run
innerfact run n = innerfact (run * n) (n - 1)
What is the difference between these two functions? Nothing. Both
loop, it's just that one does it implicitly. The difference between
these is nothing more or less than style.
Now, it can be argued that the implicit looping is confusing somehow,
and the explicit looping is more obvious. However, this is only to
someone who has little experience in the functional style. For larger
problems, I find that a lazy evaluated stream style is *much* clearer
than the equivalent with C++ iterators or the like, and enough people
agree with me to make functional languages reasonably well spread,
even into industry (Erlang comes to mind).
However, doing a Scheme style factorial function in Ada will probably
confuse the Ada programmer, because Ada was not designed to do that
sort of thing. This is what the issue is. Programming in a
functional style can make many algorithms very easy to understand, but
*only* if you know how to program in a functional style!
So if I run across one of those algorithms in an imperative language,
do I use the functional style (and finish it easily, at the cost of
possibly alienating others without your eclectic language background),
or try to do it in an imperative style (and possibly not finish it at
all)?
Certainly, if it isn't too hard I should try the latter, but this
isn't always possible. I recall having to use a CLOS idiom
(change-class) in a C++ project to avoid contaminating the entire
design with what was really a tiny local problem. A year or so later
and a reasonable amount of thought on the subject, and I *still* don't
know how I could have avoided it.
A programming `culture' here refers to the set of approaches to a
problem that a given set of programmers will recognize easily. You'd
have to be a fool to have learned Ada without running into loop; an
Ada programmer can reasonably expect other Ada programmers to
understand what a loop is.
Jay> Of course, "programming in the small", prototyping,
Jay> exploratory programming and RAD and related languages have
Jay> different needs and a freer style, but "programming in large"
Jay> is where the "shit hits the fan" and thus is usually the
Jay> context where these issues are discussed.
Culture is mostly independent of such concerns. The trouble arises
when you try to introduce a new idiom from another language. This can
often be a good thing in the long run, but it can cause major
confusion in the short term. Template metaprogramming in C++ comes to
mind; it enables incredibly fast C++ matrix libraries, but it is
*weird* to work with the first few times.
- --
Graham Hughes <th...@treepeople.dyn.ml.org>
http://treepeople.dyn.ml.org/thrag/
PGP Fingerprint: 36 15 AD 83 6D 2F D8 DE EC 87 86 8A A2 79 E7 E6
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNP3QG1N2pHdjE11BAQHcrwP/a7o5myqAp17DIUarneGTbPy0CXclXl5C
SewnVt1JWWiBqhmd7NcmsiDS+6ij9+9OPH0gknFevQJCpMC0p4o+Lpb2IzGTx22a
vN5kzlZqtDA9lYkmDz9qv1a5ng+S2bBaNHbGXrobMXTtdlNy0DqMIRfV+kUOF2VH
zr//h2vSMO0=
=nJEZ
-----END PGP SIGNATURE-----
Brian Rogoff
On 4 Mar 1998, Graham Hughes wrote:
> >>>>> "Jay" == Jay Martin <jaymm...@earthlink.net> writes:
>
> Jay> I find this "culture" talk pretty disturbing. These
> Jay> guidelines are not promoted by Stroustrup, Meyers, design
> Jay> teams of Ada83/Ada95, etc because of some fanciful whim and
> Jay> hard to break bad habits, but by understanding of
> Jay> "programming in the large" issues. Its not merely that it
> Jay> becomes a "cultural goof" in X language that such advice
> Jay> should be heeded, but real underlying software issues. Of
>
> I'll use an example, to help illustrate.
>
> Suppose I want to write a factorial function (to flog a dead horse :-).
>
> In Ada, I might write this as
>
> function Factorial(N : in Integer) : Integer is
Your Pascal cultural influence is showing here in a syntax error :-).
> ... snip ...
>
> This is classic imperative style. However, a functional language like
> Scheme might do it this way:
>
> (define (factorial n)
> (define (inner-factorial running n)
> (if (<= n 1)
> running
> (inner-factorial (* running n) (- n 1))))
> (inner-factorial 1 n))
>
> If you don't like Scheme, the same in Haskell looks like
>
> factorial n = innerfact 1 n
> where innerfact run 0 = run
> innerfact run n = innerfact (run * n) (n - 1)
>
> What is the difference between these two functions? Nothing. Both
> loop, it's just that one does it implicitly. The difference between
> these is nothing more or less than style.
While I agree with your main point, the example is flawed. The reason you
assume there is no difference in the two pieces of code is that in
(R<n>RS and ANSI/IEEE) Scheme, tail calls are *guaranteed* to be compiled
to jumps, so that tail recursive factorial is the same as the looping one.
Neither Ada, nor ANSI Common Lisp for that matter, make that guarantee, so
expressing loops as tail calls is likely to lead to stack overflow in
these languages (and C++, Java, etc).
> However, doing a Scheme style factorial function in Ada will probably
> confuse the Ada programmer,
I doubt there are really any monolingual Ada (or Lisp) programmers, so I
doubt this!
> Programming in a
> functional style can make many algorithms very easy to understand, but
> *only* if you know how to program in a functional style!
That might be heresy on comp.object!
> So if I run across one of those algorithms in an imperative language,
> do I use the functional style (and finish it easily, at the cost of
> possibly alienating others without your eclectic language background),
> or try to do it in an imperative style (and possibly not finish it at
> all)?
It is quite difficult to use a "functional style" in many non-functional
languages, and the long term costs may be great. Its like trying to do
OO programming in C; sure it can be done, I've done it, but the benefits
are not as great and the maintenance costs potentially high. I'm not
really disagreeing with you here, just pointing out the down side to
"programming into a language, not in it".
-- Brian
Graham Hughes
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Brian" == Brian Rogoff <b...@shell5.ba.best.com> writes:
Brian> Your Pascal cultural influence is showing here in a syntax
Brian> error :-).
Doh. Shows you how much Ada I do. I just didn't want to pick C++ or
Java :-).
Brian> While I agree with your main point, the example is
Brian> flawed. The reason you assume there is no difference in the
Brian> two pieces of code is that in (R<n>RS and ANSI/IEEE)
Brian> Scheme, tail calls are *guaranteed* to be compiled to
Brian> jumps, so that tail recursive factorial is the same as the
Brian> looping one. Neither Ada, nor ANSI Common Lisp for that
Brian> matter, make that guarantee, so expressing loops as tail
Brian> calls is likely to lead to stack overflow in these
Brian> languages (and C++, Java, etc).
Granted, I was trying to pick a simple example (and partly why I
picked Scheme). More interesting is a Fibonnaci generator, where
memoiziation after the fact *can* allow the simple, stupid algorithm
to perform linearly. Not as well as the closed form expression, of
course :-). OTOH, that requires a bit more Scheme. And actually, I
believe both Allegro CL and gcc do tail call optimization, depending
on the optimization level. Just because it isn't in the language
doesn't mean it isn't there...
Truly fascinating is when you take an infinite stream of data and turn
it into a Monte Carlo simulation, as SICP does. But that's a bit out
of comp.object's scope. However, it and any attendant statistical
analysis *is* something that functional languages do reasonably well.
A running standard deviation can be quite useful.
>> However, doing a Scheme style factorial function in Ada will
>> probably confuse the Ada programmer,
Brian> I doubt there are really any monolingual Ada (or Lisp)
Brian> programmers, so I doubt this!
I can envision an Ada programmer left unexposed to the wonders of
functional languages; such a programmer probably would blink pretty
hard at the tail recursion, as opposed to a normal loop.
>> Programming in a functional style can make many algorithms very
>> easy to understand, but *only* if you know how to program in a
>> functional style!
Brian> That might be heresy on comp.object!
Possibly, but so? :-)
OO code is near impossible to understand if you haven't learned how to
program OO, too. But nobody here is claiming that using stuff from
the OO `culture' isn't useful. That might actually have been a better
example, come to think of it.
Brian> It is quite difficult to use a "functional style" in many
Brian> non-functional languages, and the long term costs may be
Brian> great. Its like trying to do OO programming in C; sure it
Brian> can be done, I've done it, but the benefits are not as
Brian> great and the maintenance costs potentially high. I'm not
Brian> really disagreeing with you here, just pointing out the
Brian> down side to "programming into a language, not in it".
Depends on the algorithm, really. Functional programming is useful
enough that people have written a frontend to Java that allows it more
easily than Java alone does (Pizza), and it can sometimes lead to a
clearer expression of the algorithm. Certainly much of my OO code is
also functional. Functional style doesn't always mean tail recursion,
pattern matching, and all that. It can be argued that parts of C++'s
STL (functors, for example) are there to allow functional style.
- --
Graham Hughes <th...@treepeople.dyn.ml.org>
http://treepeople.dyn.ml.org/thrag/
PGP Fingerprint: 36 15 AD 83 6D 2F D8 DE EC 87 86 8A A2 79 E7 E6
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNP5THlN2pHdjE11BAQEm6QP/SRjt9wEbhpl2kO4ux/EDINuhYc3nWgmD
3ZyiQ7GcIkcg7EM4h/0uTkzpfcSh/tsGFdTnzApOYJBbVDPvaUXpzWSRTDi2NFNP
MVkXr8vtUu/s9z4KK7bRbkZ6alMcmSBDSWGjpbGllb3vJkLNNrp3WDVjtW406zp3
1DV3AOXxVEA=
=G7Qu
-----END PGP SIGNATURE-----
Jay Martin
Graham Hughes wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> >>>>> "Jay" == Jay Martin <jaymm...@earthlink.net> writes:
>
> Jay> I find this "culture" talk pretty disturbing. These
> Jay> guidelines are not promoted by Stroustrup, Meyers, design
> Jay> teams of Ada83/Ada95, etc because of some fanciful whim and
> Jay> hard to break bad habits, but by understanding of
> Jay> "programming in the large" issues. Its not merely that it
> Jay> becomes a "cultural goof" in X language that such advice
> Jay> should be heeded, but real underlying software issues. Of
> Jay> dismiss the opinions of these experts is really silly ("I am
> Jay> a genius and these guys are all morons"). Pointing to the
> Jay> underlying semantics: "Exception raised here, blows off stack
> Jay> frames, until caught in "exception handler" there", does not
> Jay> say much about how the feature should be used.
>
> I'll use an example, to help illustrate.
But what I was mainly objecting to this:
>>> In my chastising (oops) I was trying to point out the benefit of shedding
>>> the culture and examining the mechanism itself.
Which is a call to "shed the culture" of what ever language we are using
(hopefully strongly typed and extremely Anal) and do a "mind expanding"
trip of the infinite possiblities by being unshackled of evil
cultural restraint. I was also objecting abit to to the implicit
"all cultures are automatically equal" notions.
> Suppose I want to write a factorial function (to flog a dead horse :-).
>
> In Ada, I might write this as
>
> function Factorial(N : in Integer) : Integer is
> Result : Integer;
> begin
> for Count in 1 .. N
> loop
> Result := Result * Count;
> end loop;
> return Result;
> end Factorial;
>
> This is classic imperative style. However, a functional language like
> Scheme might do it this way:
>
> (define (factorial n)
> (define (inner-factorial running n)
> (if (<= n 1)
> running
> (inner-factorial (* running n) (- n 1))))
> (inner-factorial 1 n))
>
> If you don't like Scheme, the same in Haskell looks like
>
> factorial n = innerfact 1 n
> where innerfact run 0 = run
> innerfact run n = innerfact (run * n) (n - 1)
>
> What is the difference between these two functions? Nothing. Both
> loop, it's just that one does it implicitly. The difference between
> these is nothing more or less than style.
>
> Now, it can be argued that the implicit looping is confusing somehow,
> and the explicit looping is more obvious.
Heh, there is a bug in the looping one (Result is uninitialized), but I still think
it is clearer.
> However, this is only to someone who has little experience in the
> functional style.
> For larger
> problems, I find that a lazy evaluated stream style is *much* clearer
> than the equivalent with C++ iterators or the like, and enough people
> agree with me to make functional languages reasonably well spread,
> even into industry (Erlang comes to mind).
Functional programming is pretty much dead and is barely used and I believe
its for a reason. I don't think its benefits justify a stampede to
functional style. Only certain crackpot universities
(on the east coast) are pompous enough to try push this stuff even though
its pretty much dead. I have real problems with people who say that
say functional style is more "mathematical" as some type
of "proof" that it is better (mathematics != programming).
> However, doing a Scheme style factorial function in Ada will probably
> confuse the Ada programmer, because Ada was not designed to do that
> sort of thing. This is what the issue is. Programming in a
> functional style can make many algorithms very easy to understand, but
> *only* if you know how to program in a functional style!
> So if I run across one of those algorithms in an imperative language,
> do I use the functional style (and finish it easily, at the cost of
> possibly alienating others without your eclectic language background),
> or try to do it in an imperative style (and possibly not finish it at
> all)?
> Certainly, if it isn't too hard I should try the latter, but this
> isn't always possible.
This is reasonable. Some people have no restraint and do other idioms
or even make up their own style.
> A programming `culture' here refers to the set of approaches to a
> problem that a given set of programmers will recognize easily. You'd
> have to be a fool to have learned Ada without running into loop; an
> Ada programmer can reasonably expect other Ada programmers to
> understand what a loop is.
>
> Jay> Of course, "programming in the small", prototyping,
> Jay> exploratory programming and RAD and related languages have
> Jay> different needs and a freer style, but "programming in large"
> Jay> is where the "shit hits the fan" and thus is usually the
> Jay> context where these issues are discussed.
>
> Culture is mostly independent of such concerns.
The problem is that not all cultures are created equal with
respect to "programming in the large". To assert such is
just PC "can't we all just get along" nonsense. Some language
cultures seem to encourage the programmer to "make their own language"
which discourages widespread readability. Dynamically typed
language cultures are much more into prototyping
and are usually much less anal than strongly typed
language cultures.
Jay
Patrick Logan
: While I agree with your main point, the example is flawed. The reason you
: assume there is no difference in the two pieces of code is that in
: (R<n>RS and ANSI/IEEE) Scheme, tail calls are *guaranteed* to be compiled
: to jumps, so that tail recursive factorial is the same as the looping one.
: Neither Ada, nor ANSI Common Lisp for that matter, make that guarantee, so
: expressing loops as tail calls is likely to lead to stack overflow in
: these languages (and C++, Java, etc).
What this illustrates is that there is a cultural influence among compiler
writers as well as language users. There is no reason a tail call should
not be compiled so efficiently that it behaves as a loop. (Common Lisp
often is compiled this way, even though it is a challenge to handle
special variables. I believe the GNU C compiler makes this improvement too,
which betrays its (i.e. Stallman, et al.'s) foundation in the MIT
Lisp/Scheme compiler culture.)
Patrick Logan
: Brian> While I agree with your main point, the example is
: Brian> flawed.
: Granted, I was trying to pick a simple example...
As I indicated in a previous message, this example servers to illustrate
cultural influences at work among the compiler writers as well as the
language users.
Let's pick another example by going back in time:
Compiling procedure calls efficiently.
25 years ago procedure calls were consider expensive, just as tail calls
are considered expensive in many languages today. As a result the culture
around languages like PL/1 influenced programmers not to use procedure
calls as much as they should/could. But the compiler writers were
influenced as much by this culture as were the language users.
At the same time the Lisp culture was becoming performance minded. Their
applications had always run slow. But it didn't matter because the
programmers were getting the results they needed. When their programs
actually became practical outside of the lab, they found the performance
was barely tolerable at best. One of the main reasons was that procedure
calls were very expensive and in Lisp procedure calls are unavoidable.
The culture of Lisp programming required efficient procedure calls and the
culture of Lisp compiler writers *forced* them to pay most of their
attention to making procedure calls efficient. They did. Subsequently this
influenced the compiler writers of other languages. Nowadays it would be
unmarketable to sell a compiler of any language that did not compile
procedure calls efficiently.
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: Functional programming is pretty much dead and is barely used and I
: believe its for a reason.
What on earth could make you say such a thing? It can only be said in
ignorance. Functional programming is stronger now than it has ever been.
To you it may still seem dead, because your interests are in practical
programming in the large. Functional programming is only beginning to deal
with in-the-large problems. So? It has been dealing with other problems
quite well. In time it will have much to offer to the in-the-large
problems. This does not have to be a mine is bigger and better than yours
discussion. It is not all one or the other. In fact Erlang, a functional
language, is *widely* used by Ericson (spelling is wrong, I know) in
their telephone/communication systems *today*. When the FP community fully
comes to terms with programming-in-the-large you can bet it will have
something of value to offer us. Of course I don't expect anyone to hold
their breath waiting. But neither should they be ignorant of what is so.
: I don't think its benefits justify a stampede to
: functional style. Only certain crackpot universities
: (on the east coast) are pompous enough to try push this stuff even
: though
: its pretty much dead. I have real problems with people who say that
: say functional style is more "mathematical" as some type
: of "proof" that it is better (mathematics != programming).
Jay you seem like a wise yet one-trick pony. You have something valuable
to say but in order to highlight it, you express falsehoods about things
you are justifiably ignorant of. Get the chip of your shoulder and stick
to what you know.
Brian Rogoff
On Thu, 5 Mar 1998, Jay Martin wrote:
> Graham Hughes wrote:
> > I don't think you quite understand the culture remark completely.
> > I'll use an example, to help illustrate.
>
> But what I was mainly objecting to this:
>
> >>> In my chastising (oops) I was trying to point out the benefit of shedding
> >>> the culture and examining the mechanism itself.
>
> Which is a call to "shed the culture" of what ever language we are using
> (hopefully strongly typed and extremely Anal) and do a "mind expanding"
> trip of the infinite possiblities by being unshackled of evil
> cultural restraint. I was also objecting abit to to the implicit
> "all cultures are automatically equal" notions.
I don't think there was such an implicit notion. Different programming
paradigms (I don't like "culture" here) are typically suited to different
problem domains.
... snip ...
> Heh, there is a bug in the looping one (Result is uninitialized), but I still think
> it is clearer.
Its much harder to get those imperative programs right :-)
> Functional programming is pretty much dead and is barely used and I believe
> its for a reason. I don't think its benefits justify a stampede to
> functional style. Only certain crackpot universities
> (on the east coast) are pompous enough to try push this stuff even though
> its pretty much dead. I have real problems with people who say that
> say functional style is more "mathematical" as some type
> of "proof" that it is better (mathematics != programming).
What a weird mixture of ad-hominem, misunderstanding, error, and
braggadocio! And how amusing that we could have replaced "functional
style" by "object oriented style" 15 years ago. The arguments from the
group at Ericcson on the virtues of the functional style were based
mainly on the reduction of code size, not on mathematics. And certain
universities on the West Coast (and Midwest), not to mention Europe,
South America, Australia, etc., also seem to find it important.
This is not to say that I agree with some of the wilder claims for
functional programming (or OO, or logic programming, or ...) but
I certainly anticipate that many applications will be able to
incorporate them.
> > Jay> Of course, "programming in the small", prototyping,
> > Jay> exploratory programming and RAD and related languages have
> > Jay> different needs and a freer style, but "programming in large"
> > Jay> is where the "shit hits the fan" and thus is usually the
> > Jay> context where these issues are discussed.
> >
> > Culture is mostly independent of such concerns.
>
> The problem is that not all cultures are created equal with
> respect to "programming in the large". To assert such is
> just PC "can't we all just get along" nonsense. Some language
> cultures seem to encourage the programmer to "make their own language"
> which discourages widespread readability. Dynamically typed
> language cultures are much more into prototyping
> and are usually much less anal than strongly typed
> language cultures.
Well, at least I could find something I could roughly agree with in your
post. OTOH, not all programming is "in the large", maybe most isn't.
And static typing is no guarantee of a readability oriented "culture".
Most of the C++ and Java I've worked with was not written with readers in
mind.
-- Brian
Jay Martin
Patrick Logan wrote:
>
> Jay Martin <jaymm...@earthlink.net> wrote:
>
> : Functional programming is pretty much dead and is barely used and I
> : believe its for a reason.
>
> ignorance. Functional programming is stronger now than it has ever been.
Every functional language went no where or is dead. Scheme/Lisp
once popular are pushing up daisies (Good). I would say
this makes functional programming languages weaker today.
> To you it may still seem dead, because your interests are in practical
> programming in the large. Functional programming is only beginning to deal
> with in-the-large problems. So?
And thats because the crackpots of academia cannot
program their way out of bag and are fundamentally incompetent
at software. (Usually they think it is "unworthy of study")
It is pointless for them even to comment without years
of programming in the large experience in software in industry.
That they didn't deal with these software issues a quarter
of century ago is just inexcusable. That they keep
pumping out massively software incompetent graduates into
the software industry (sewer) is inexcusable.
> It has been dealing with other problems
> quite well. In time it will have much to offer to the in-the-large
> problems.
> This does not have to be a mine is bigger and better than yours
> discussion. It is not all one or the other. In fact Erlang, a functional
> language, is *widely* used by Ericson (spelling is wrong, I know) in
> their telephone/communication systems *today*.
So one crackpot company is lead astray into their own weakly
functional special purpose crackpot language. Yawn.
Hopefully this company will go out of business so we won't
have hear about this one company continually by the
functional language-oids. Sort of like the "5th generation
language project" in Japan which was served up by the AI
bozos as proof of their importance for years (even though it had
been silently cancelled).
> When the FP community fully
> comes to terms with programming-in-the-large you can bet it will have
> something of value to offer us. Of course I don't expect anyone to hold
> their breath waiting. But neither should they be ignorant of what is so.
The functional community being academic incompetents will probably
never understand software. This requires getting into the grime of
software which their ivory tower theoretical purism would not allow.
I see nothing of practical worth coming out of academia especially
in languages. Of course if guys don't believe me
then I suggest you go to a university library and checkout
academic journals on functional languages or any other theoretical
subject and see if you find anything of practical value.
Good luck.
> : I don't think its benefits justify a stampede to
> : functional style. Only certain crackpot universities
> : (on the east coast) are pompous enough to try push this stuff even
> : though
> : its pretty much dead. I have real problems with people who say that
> : say functional style is more "mathematical" as some type
> : of "proof" that it is better (mathematics != programming).
>
> Jay you seem like a wise yet one-trick pony. You have something valuable
> to say but in order to highlight it, you express falsehoods about things
> you are justifiably ignorant of. Get the chip of your shoulder and stick
> to what you know.
Where are the falsehoods and stuff I don't know?
My comments on CS academics are from my experience as a PHD student and
reading academic materials. I have looked at functional languages, read
books, etc and don't find them compelling. Sorry, I will jump all over
anyone who implicitly uses CS academics as anything close to an authority
in the software field or X CS theory as some "manifest evolution" of
software.
Jay
Phlip
Jay Martin & Patrick Logan wrote:
> ..What on earth...Functional programming...dead...crackpots of
> academia...one-trick pony...
Uhm, could the group get a Definition of FP out of _both_ of you? Try to do
better than this:
The building block of a FP is the Function.
The building block of an OOP is the Object.
Yeah, and the building block of Assembler is the Electron. Could you guys take a
definition to the next level?
-- Phlip
======= http://users.deltanet.com/~tegan/home.html =======
Ell
: > language, is *widely* used by Ericson (spelling is wrong, I know) in
: > their telephone/communication systems *today*.
: So one crackpot company is lead astray into their own weakly
: functional special purpose crackpot language.
Ericsson seems hardly to be a crackpot company. They sell quite a few
cellular phones, other electronic equipment, and have major telephone
switching systems in place around the world. It also is where Jacobson
and others developed many of those switching systems using the OO paradigm
and use cases.
No one can be absolutely sure where functional languages will go, but they
haven't caught on all these years for large scale system development and I
see no compelling reason they should.
Jay Martin
Patrick Logan wrote:
>
> : While I agree with your main point, the example is flawed. The reason you
> : assume there is no difference in the two pieces of code is that in
> : (R<n>RS and ANSI/IEEE) Scheme, tail calls are *guaranteed* to be compiled
> : to jumps, so that tail recursive factorial is the same as the looping one.
> : Neither Ada, nor ANSI Common Lisp for that matter, make that guarantee, so
> : expressing loops as tail calls is likely to lead to stack overflow in
> : these languages (and C++, Java, etc).
(Now that Scheme's creator is the controller of the Java language, I am sure that
this feature will be in Java anytime now, if its not already.)
> What this illustrates is that there is a cultural influence among compiler
> writers as well as language users. There is no reason a tail call should
> not be compiled so efficiently that it behaves as a loop. (Common Lisp
> often is compiled this way, even though it is a challenge to handle
> special variables. I believe the GNU C compiler makes this improvement too,
> which betrays its (i.e. Stallman, et al.'s) foundation in the MIT
> Lisp/Scheme compiler culture.)
Heh, if Visual C++ doesn't have it "it doesn't exist"!
Jay
Tim Ottinger
Ell wrote:
> : > ... In fact Erlang, a functional
> : > language, is *widely* used by Ericson (spelling is wrong, I know) in
> : > their telephone/communication systems *today*.
>
> : So one crackpot company is lead astray into their own weakly
> : functional special purpose crackpot language.
>
> Ericsson seems hardly to be a crackpot company. They sell quite a few
> cellular phones, other electronic equipment, and have major telephone
> switching systems in place around the world. It also is where Jacobson
> and others developed many of those switching systems using the OO paradigm
> and use cases.
Also, other respected OO gurus have stated that every domain should
have its own notation and its own language(s). Now, the knee-jerk reaction
to such a statement is "gosh, that's an awful thing... I'd have to learn the
language-of-the-week just to survive", but think a little more about it and
you start to see the truth hiding behind those words.
It's been stated here more than once that our language either frees
or constrains our thinking. If you believe this, then you can see that
you need a good way to phrase accounting problems and solutions
and that you need a good way to phrase solutions to these problems.
Now this still stops short of "a custom language for each domain",
but it's not stopping all that short.
In a way, isn't that one of the benefits of OO -- that we can extend the
programming language via objects and operators and create just such a
language for ourselves? The basic grammar doesn't change, but we
build the terms and semantics to meet our application needs.
Go a little further, and the frameworks and libraries we build are meant
to deliver a custom notation (well, set of terms at least) for "business
programmers" who can work at a 'higher' level. Aren't we doing just
this?
And doesn't the ability in UML to change symbology and add stereotypes
start to lend itself to this as well? It's probably worth considering.
Hey, if some problems are easier to handle in some unusual lisp-derived
language, that's not all bad. The bad part is the barrier to entry that the
organization builds for new programmers, and that can be very bad,
indeed. But it's not a no-brainer in either direction.
Tim
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: I have looked at functional languages, read
: books, etc and don't find them compelling.
Jay Martin does not find them compelling and so FP is dead and anyone who
disagrees is a crackpot. Is this all you learned with your PhD? Didn't you
learn how to shift those blinders a bit to the left or the right once in a
while?
Neigh. (Sorry. You sound like a one trick pony to me.)
Patrick Logan
Phlip <te...@deltanet.com> wrote:
: Jay Martin & Patrick Logan wrote:
: > ..What on earth...Functional programming...dead...crackpots of
: > academia...one-trick pony...
: Uhm, could the group get a Definition of FP out of _both_ of you? Try to do
: better than this:
: The building block of a FP is the Function.
: The building block of an OOP is the Object.
: Yeah, and the building block of Assembler is the Electron. Could you guys take a
: definition to the next level?
Functional programming and object-oriented programming do not have just
one definition. You may already have given the best definition possible in
less than a page. Here is another attempt:
Functional programming relies on higher order functions. It's main power
is in the expressiveness of combining functions to make more powerful
functions. The foundation of FP is Church's lambda calculus.
Object-oriented programming can be seen as a subset of functional
programming where classes are syntactic sugar for defining related
functions. OTOH there are ways to reverse the relationship (e.g. Luca
Cardelli's work) and show that functional programming is a subset of a
calculus of objects.
Jay Martin
Patrick Logan wrote:
>
> Jay Martin <jaymm...@earthlink.net> wrote:
>
> : I have looked at functional languages, read
> : books, etc and don't find them compelling.
>
> Jay Martin does not find them compelling and so FP is dead and anyone who
> disagrees is a crackpot.
Well maybe "dead" is a little too strong, how about in a "coma".
And they are not in a "coma" because I didn't find them compelling,
they are in a "coma" because I don't see any real money going
into them via commercial or ARPA/NSF academic funding.
I would also say that AI is in a "coma". I am always looking
for something interesting in these fields and for them to
"wake up".
> Is this all you learned with your PhD?
Heh, I learned to be even more cynical!
I learned "academia has no clothes" (I used to think
they were stars). I learned "academia" mostly thinks software
is like "wiping your butt". I learned CS BS-ers can't
program their way out of bag straight out of college.
I still have to learn the fine art of hype, exaggeration
and obsfucation.
> Didn't you learn how to shift those blinders a bit to the left or the
> right once in a while?
I read some books just to "deepen" my hate of subjects.
I read some books because its neat but not very useful.
Just because you don't agree with something does not mean
you don't understand it.
> Neigh. (Sorry. You sound like a one trick pony to me.)
I guess I am a one trick pony, I like anal strongly typed
OO languages preferably very simple. (Java was my great hope until
Sun Marketing/Steele took it away from Gosling, now I am guarded)
My background is in programming in the large with dimwits
so "fancy languages for software studs" don't impress me.
Jay
Rainer Joswig
In article <34FF04EC...@earthlink.net>, Jay Martin
<jaymm...@earthlink.net> wrote:
> Every functional language went no where or is dead. Scheme/Lisp
> once popular are pushing up daisies (Good).
Fortunately we are making money with Lisp programming. And it
is also fun.
--
http://www.lavielle.com/~joswig/
Rainer Joswig
> And doesn't the ability in UML to change symbology and add stereotypes
> start to lend itself to this as well? It's probably worth considering.
The problem with UML and similar things is that they are very
weak on the theory side. Formal semantics is not their strong
point.
> Hey, if some problems are easier to handle in some unusual lisp-derived
> language, that's not all bad.
OO has a long tradition in AI. Researchers have learned their
lessons about the limited modelling capabilities of OO early
(frame systems, scripts, "What's in a link?", ...). Current
theory (for example in Description Logics) is taking a more
formal approach. They just want to know the formal properties
and expressivity of the languages they are designing. They
also want to enable computation with concept descriptions, etc.
There are many ways to understand the basics of OO. You can
try to understand it via object+messages, some extension to
lambda calculus or for example via logics (predicate calculus, ...).
The latter is very attractive.
--
http://www.lavielle.com/~joswig/
Charles Martin
Rainer Joswig wrote:
>
> In article <34FF7251...@oma.com>, Tim Ottinger <otti...@oma.com> wrote:
>
> > And doesn't the ability in UML to change symbology and add stereotypes
> > start to lend itself to this as well? It's probably worth considering.
>
> The problem with UML and similar things is that they are very
> weak on the theory side. Formal semantics is not their strong
> point.
... but check out Steve Cook's OO with Syntropy book -- he does a rather
nice job of defining a Dijkstra-esque imperative semantics for a
UML-like notation.
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: (Now that Scheme's creator is the controller of the Java language, I am sure that
: this feature will be in Java anytime now, if its not already.)
I doubt that Steele is in "control" of Java. I would bet Bill Joy brought
him in to ensure a formal treatment of the language specification. Since
Steele has experience with both Common Lisp and C specifications, among
other credentials.
As evidence he is at least not in complete control, he has written about
aspects of the language he does not care for, e.g. silent overflow of
integers. I suspect he would have changed some things already if he was in
control.
Rainer Joswig
In article <Pine.BSF.3.96.980304...@shell5.ba.best.com>,
Brian Rogoff <b...@shell5.ba.best.com> wrote:
> While I agree with your main point, the example is flawed. The reason you
> assume there is no difference in the two pieces of code is that in
> (R<n>RS and ANSI/IEEE) Scheme, tail calls are *guaranteed* to be compiled
> to jumps, so that tail recursive factorial is the same as the looping one.
> Neither Ada, nor ANSI Common Lisp for that matter, make that guarantee, so
> expressing loops as tail calls is likely to lead to stack overflow in
> these languages (and C++, Java, etc).
The Common Lisp community has left this to the implementors.
Most modern Common Lisp implementations are capable of
doing these optimizations.
--
http://www.lavielle.com/~joswig/
Jeff Younker
Jay Martin <jaymm...@earthlink.net> writes:
> Graham Hughes wrote:
> > For larger
> > problems, I find that a lazy evaluated stream style is *much* clearer
> > than the equivalent with C++ iterators or the like, and enough people
> > agree with me to make functional languages reasonably well spread,
> > even into industry (Erlang comes to mind).
>
> Functional programming is pretty much dead and is barely used and I believe
> its for a reason. I don't think its benefits justify a stampede to
> functional style. Only certain crackpot universities
> (on the east coast) are pompous enough to try push this stuff even though
Erlang is a functional language developed by, and used by, the telecom
equipment corporation Ericsson. Information about the language, and
it's applications can be found at:
http://www.erlang.se/erlang/sure/main/
http://www.erlang.se/erlang/sure/main/applications/
The video game crash bandicoot is written in a dialect of LISP. I
read an article about this in a video game industry rag, the name
of which I can't recall.
- Jeff Younker - je...@mdli.com - These are my opinions, not MDL's -
Jay Martin
Patrick Logan wrote:
>
> Jay Martin <jaymm...@earthlink.net> wrote:
>
> : (Now that Scheme's creator is the controller of the Java language, I am sure that
> : this feature will be in Java anytime now, if its not already.)
>
> I doubt that Steele is in "control" of Java. I would bet Bill Joy brought
> him in to ensure a formal treatment of the language specification. Since
> Steele has experience with both Common Lisp and C specifications, among
> other credentials.
>
> As evidence he is at least not in complete control, he has written about
> aspects of the language he does not care for, e.g. silent overflow of
> integers. I suspect he would have changed some things already if he was in
> control.
This may be backwards compatibility at this point. What I have read
is that Gosling did not design "inner classes" (which had Steele
and minions fingers all over it) and in an interview he
said that he was letting others design "Java templates". So it
now looks like Gosling is out of the loop which is sad as I don't
trust Steele or committees to design languages.
Jay
Brian Rogoff
On Fri, 6 Mar 1998, Jay Martin wrote:
> Patrick Logan wrote:
> > I doubt that Steele is in "control" of Java. I would bet Bill Joy brought
> > him in to ensure a formal treatment of the language specification. Since
> > Steele has experience with both Common Lisp and C specifications, among
> > other credentials.
> >
> > As evidence he is at least not in complete control, he has written about
> > aspects of the language he does not care for, e.g. silent overflow of
> > integers. I suspect he would have changed some things already if he was in
> > control.
>
> This may be backwards compatibility at this point. What I have read
> is that Gosling did not design "inner classes" (which had Steele
> and minions fingers all over it) and in an interview he
Not that facts will be able to sway your opinion, but the early papers
on the Java inner classes design pointed to BETA as the inspiration
for this feature, and BETA is the direct descendent of Simula, which
also has nested classes. This makes more sense than your bizarre theories,
as Ole Lehrmann Madsen (one of BETA's designers) was at Sun for a while
during the early growth of Java, though I'm only speculating now that
he had anything to do with this.
Personally, I like inner classes, though I'm not particularly fond of
Java as a whole.
-- Brian
Brian Rogoff
On Fri, 6 Mar 1998, Rainer Joswig wrote:
> In article <Pine.BSF.3.96.980304...@shell5.ba.best.com>,
> Brian Rogoff <b...@shell5.ba.best.com> wrote:
>
> > While I agree with your main point, the example is flawed. The reason you
> > assume there is no difference in the two pieces of code is that in
> > (R<n>RS and ANSI/IEEE) Scheme, tail calls are *guaranteed* to be compiled
> > to jumps, so that tail recursive factorial is the same as the looping one.
> > Neither Ada, nor ANSI Common Lisp for that matter, make that guarantee, so
> > expressing loops as tail calls is likely to lead to stack overflow in
> > these languages (and C++, Java, etc).
>
> The Common Lisp community has left this to the implementors.
Which was a wise choice, IMO.
> Most modern Common Lisp implementations are capable of
> doing these optimizations.
Yes, I was wrong to state that stack overflow was "likely". However, since
the thread seems to have moved to "culture", and you are a happy CL
programmer, I wonder to what extent tail calling is used for iteration in
the Common Lisp community. Certainly I didn't see it a lot; the code I was
exposed to tended to use the (heinous ;-) loop macro or other ways to
express iteration. Tail calling seems more popular amongst Schemers,
though I would expect Common Lisp programmers to be very familiar with it
too.
-- Brian
Jay Martin
John Rose wrote the inner classes spec. John Rose has papers co-authored with
Guy Steele and he wrote the following paper:
Rose, J.R.; Muller, H.
Integrating the Scheme and C languages.
IN: Proceedings of the 1992 ACM Conference on Lisp and Functional
Programming. (Proceedings of the 1992 ACM Conference on Lisp and Functional
ProgrammingProceedings of SIGPLAN Conference on Lisp and Functional
Programming, San Francisco, CA, USA, 22-24 June 1992). New York, NY, USA:
ACM, 1992. p. 247-59.
"Inner classes" is merely closures in a class scope. They may have looked to
Beta for details and gave generious attribution but I would say the main
motivation was grafting the ideas from closures on to Java at all costs.
If Gosling thought these features were the greatest thing since sliced bread,
they would have been fully integrated into the language at the beginning
instead of some lamely implemented add on. I was hoping we had finally gotten
rid of most nested scoping, silly me.
> Personally, I like inner classes, though I'm not particularly fond of
> Java as a whole.
I liked Java because it was a egoless minimal parring of C++, but
now they obviously want to be "genius language designers". Seems stupid
to blow away multiple inheritance because its "too complex" and
then later add a "class nesting hierarchy". Its too bad we not ever
really going see the language as it would have been
designed by Gosling.
Jay
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: Just because you don't agree with something does not mean
: you don't understand it.
True. But expressing ignorance *does* indicate you do not understand it.
: My background is in programming in the large with dimwits
I guess that's enough said. I guess there is no need to get into
discussions with you anymore.
Jay Martin
>Jay Martin <jaymm...@earthlink.net> wrote:
>: Just because you don't agree with something does not mean
>: you don't understand it.
>True. But expressing ignorance *does* indicate you do not understand it.
You have not contradicted a single one of my points. Pretty much
just personal attacks. So where is the ignorance?
I don't like "functional language style". I don't think it provides
the improvement in software efficiency justifying moving industry
from imperative style to functional languages. I don't
need to use recursion everywhere because I like loops, I like
iterators, etc.
>: My background is in programming in the large with dimwits
>I guess that's enough said. I guess there is no need to get into
>discussions with you anymore.
Until you understand that all programmers are not PHDs in functional
language theory from MIT, that "programming in the large" with
people requires certain compromises as your team may not all
Until you understand that all programmers are not PHDs in functional
language theory from MIT, that "programming in the large" with
people requires certain compromises as your team may not all
be geniuses, then I don't think you fully understand software
engineering.
Have you ever done large application development over a long
period of time? When you look at some language or theory do
you think of the lamest programmer (call him "John") on some
past team and think "what would "John" make of this shit".
I do.
Jay
Jay Martin
Heh, Lambda calculus? Stupid equivalency proofs? That and $3 will buy you
a latte. What does this have to do with software engineering? Jackshit if
you ask me and thats my main point of contention with Mr Logan. Formal
theory is just not important for doing practical software engineering.
Its then almost an "I am so knowledgable" intimindation technique. The best
approach is just to laugh at these bozos, they are truly living on another
planet. (Then they, heh, probably say that the theory tells them that they
should be hacking in Lisp, Smalltalk,etc). Maybe there should be a
"comp.object.theoretical.masturbation".
Phlip, I would suggest you peek in a programming language survey book
to the functional language chapter if you really want a really basic
overview of what functional languages are about.
Jay
Eliot & Linda
> Patrick Logan wrote:
> > Functional programming relies on higher order functions. It's main power
> > is in the expressiveness of combining functions to make more powerful
> > functions. The foundation of FP is Church's lambda calculus.
> > Object-oriented programming can be seen as a subset of functional
> > programming where classes are syntactic sugar for defining related
> > functions. OTOH there are ways to reverse the relationship (e.g. Luca
> > Cardelli's work) and show that functional programming is a subset of a
> > calculus of objects.
>
>
> Heh, Lambda calculus? Stupid equivalency proofs? That and $3 will buy you
> a latte. What does this have to do with software engineering? Jackshit if
> you ask me and thats my main point of contention with Mr Logan. Formal
> theory is just not important for doing practical software engineering.
Are you aware that the code inside Ford motor vehicle electronic
egnition systems is formally verified? This is to avoid law suits and
to allow Ford to demonstrate that their software is free from defects.
Sounds practical to me. For an account of informal approached I
recommend you read the special issue of the CACM on the Shuttle, and how
structured walkthroughs as a verification technique didn't prevent a
simulated mid-launch abort crashing into the middle of Madrid.
> Its then almost an "I am so knowledgable" intimindation technique. The best
> approach is just to laugh at these bozos, they are truly living on another
> planet.
If you find knowledge intimidating then I'm sorry for you.
> (Then they, heh, probably say that the theory tells them that they
> should be hacking in Lisp, Smalltalk,etc).
I must admit I like hacking in Smalltalk because its fun, its
high-leverage, and its beautiful.
> Maybe there should be a
> "comp.object.theoretical.masturbation".
Maybe there should be an ignorant.f***wit newsgroup too...
> Phlip, I would suggest you peek in a programming language survey book
> to the functional language chapter if you really want a really basic
> overview of what functional languages are about.
This month's SIGPLAN Notices has an article by Phil Wadler (yet another
British academic goes west :() describing a number of real-world
functional programming systems. Interesting reading.
There are a number of Prentice-Hall International Series in Computer
Science books that have good coverage of functional programming:
Implementing Functional Languages, Simon L. Peyton Jones, et al
These three are a great introductory text into some core computer
science
Programming Language Concepts and Paradigms
Programming Language Syntax and Semantics
Programming Language Processors : Compilers and Interpreters
all by David A. Watt
and
The Science of Programming (Texts and Monographs in Computer
Science)
David Gries / Paperback / Published 1987
is a good introduction into pre-condition/post-condition style formal
development for imperative languages.
_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace
Jay Martin
>Patrick Logan wrote:
>I guess that's enough said. I guess there is no need to get into
>discussions with you anymore.
I just noticed you are egregiously hacking my posts
mid sentence. This is highly obnoxious. Maybe you
shouldn't reply to my posts.
Jay Martin
Eliot & Linda wrote:
>
> > Patrick Logan wrote:
> > > Functional programming relies on higher order functions. It's main power
> > > is in the expressiveness of combining functions to make more powerful
> > > functions. The foundation of FP is Church's lambda calculus.
> > > Object-oriented programming can be seen as a subset of functional
> > > programming where classes are syntactic sugar for defining related
> > > functions. OTOH there are ways to reverse the relationship (e.g. Luca
> > > Cardelli's work) and show that functional programming is a subset of a
> > > calculus of objects.
> >
> Jay Martin wrote:
> >
> > Heh, Lambda calculus? Stupid equivalency proofs? That and $3 will buy you
> > a latte. What does this have to do with software engineering? Jackshit if
> > you ask me and thats my main point of contention with Mr Logan. Formal
> > theory is just not important for doing practical software engineering.
>
> Are you aware that the code inside Ford motor vehicle electronic
> egnition systems is formally verified? This is to avoid law suits and
> to allow Ford to demonstrate that their software is free from defects.
> Sounds practical to me.
Great for them. A application of theory I didn't know about, my
graduate courses in formal validation are not totally useless! Of course,
verification is not really viable for the vast majority of commercial
software.
> For an account of informal approached I
> recommend you read the special issue of the CACM on the Shuttle, and how
> structured walkthroughs as a verification technique didn't prevent a
> simulated mid-launch abort crashing into the middle of Madrid.
The problem is that the "ignition" system maybe slightly less complex
than the Shuttle software and thus much easier to formally verify.
> > Its then almost an "I am so knowledgable" intimindation technique. The best
> > approach is just to laugh at these bozos, they are truly living on another
> > planet.
>
> If you find knowledge intimidating then I'm sorry for you.
I don't have problems with knowledge, I have problems with snowing people
with scientific technobabble.
> > (Then they, heh, probably say that the theory tells them that they
> > should be hacking in Lisp, Smalltalk,etc).
>
> I must admit I like hacking in Smalltalk because its fun, its
> high-leverage, and its beautiful.
Heh, "Formal verification" and hacking in a weakly typed language, I sense
a contradiction....
> > Maybe there should be a
> > "comp.object.theoretical.masturbation".
>
> Maybe there should be an ignorant.f***wit newsgroup too...
Understanding when knowledge doesn't really apply is not ignorance.
Most formal theory currently does not apply to the vast majority
of software development
> > Phlip, I would suggest you peek in a programming language survey book
> > to the functional language chapter if you really want a really basic
> > overview of what functional languages are about.
>
> This month's SIGPLAN Notices has an article by Phil Wadler (yet another
> British academic goes west :() describing a number of real-world
> functional programming systems. Interesting reading.
Sounds interesting. I really don't have problems with functional
languages as the analness of say a strongly typed purely functional
language is appealing. What I don't like is overselling them and
then insinuating that "you are technically incompetent" if you don't
recognize the "mathematical" superiority of the approach. Also
being a research student, I am sensitive and a bit appalled on the
need to "sell" research.
> There are a number of Prentice-Hall International Series in Computer
> Science books that have good coverage of functional programming:
>
> Implementing Functional Languages, Simon L. Peyton Jones, et al
>
> These three are a great introductory text into some core computer
> science
>
> Programming Language Concepts and Paradigms
>
> Programming Language Syntax and Semantics
>
> Programming Language Processors : Compilers and Interpreters
>
> all by David A. Watt
>
> and
> The Science of Programming (Texts and Monographs in Computer
> Science)
> David Gries / Paperback / Published 1987
>
> is a good introduction into pre-condition/post-condition style formal
> development for imperative languages.
> _______________,,,^..^,,,_______________
> Eliot Miranda, ParcPlace
This stuff will just scare the living crap out of him.
Also my "antennas" just twitched on the phrase "core computer science".
(I believe you can go all the way to a PHD at my school and not touch
functional languages).
Jay
Rainer Joswig
In article <Pine.BSF.3.96.980306...@shell5.ba.best.com>,
Brian Rogoff <b...@shell5.ba.best.com> wrote:
> programmer, I wonder to what extent tail calling is used for iteration in
> the Common Lisp community.
Depends. In modern implementations this is a welcome optimization,
since tail calls are cheaper than ordinary function calls.
Using tail recursion is a little bit less used in Common Lisp.
Though I personally have written CL code which uses this. Basically
you get very clear implementations of algorithms (once you
understand and like recursion).
--
http://www.lavielle.com/~joswig/
Charles Martin
Jay Martin wrote:
> Heh, Lambda calculus? Stupid equivalency proofs? That and $3 will buy you
> a latte. What does this have to do with software engineering? Jackshit if
> you ask me and thats my main point of contention with Mr Logan. Formal
> theory is just not important for doing practical software engineering.
> approach is just to laugh at these bozos, they are truly living on another
> should be hacking in Lisp, Smalltalk,etc). Maybe there should be a
> "comp.object.theoretical.masturbation".
Or maybe there should be a "comp.objects.living.in.the.past".
A hint and/or a clue, Jay: the folks who are BUILDING those compilers
you're happy to use have a solid grounding in mathematical proof.
Rainer Joswig
In article <3500EC0B...@earthlink.net>, Jay Martin
<jaymm...@earthlink.net> wrote:
> Great for them. A application of theory I didn't know about, my
> graduate courses in formal validation are not totally useless! Of course,
> verification is not really viable for the vast majority of commercial
> software.
For a lot of software areas a formal verifiction is very desirable
(medicine informatics, trains, satellites, bombs, ...).
Just think about a software that generates proof plans for
electrical circuits that are part of the railroad system.
I'd rather have this software as correct as possible.
> I don't have problems with knowledge, I have problems with snowing people
> with scientific technobabble.
One could also make an attitude out of being against it.
> Heh, "Formal verification" and hacking in a weakly typed language, I sense
> a contradiction....
There was research in verified Lisp implementations (VLisp, ...).
The clean semantics is a great help.
> Understanding when knowledge doesn't really apply is not ignorance.
> Most formal theory currently does not apply to the vast majority
> of software development
Tell that the software engineering guys.
> (I believe you can go all the way to a PHD at my school and not touch
> functional languages).
Or microprocessor chip design?
Actually improving software quality is a worthy goal, IMHO.
--
http://www.lavielle.com/~joswig/
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: This may be backwards compatibility at this point. What I have read
: is that Gosling did not design "inner classes" (which had Steele
: and minions fingers all over it)
Do you have a reference that documents Steele's role in designing inner
classes? I find that difficult to believe. I have some connections into
that world, so I'll try to find out.
And who are the "minions"?
: and in an interview he
: said that he was letting others design "Java templates". So it
: now looks like Gosling is out of the loop which is sad as I don't
: trust Steele or committees to design languages.
I'd be surprised to find Steele a central figure in designing Java.
Documenting it, yes. Keeping the specification formal, yes. But I'd find
it difficult to believe he's behind inner classed and templates.
Do you have evidence other than prejudice?
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: John Rose wrote the inner classes spec. John Rose has papers co-authored with
: Guy Steele and he wrote the following paper:
: Rose, J.R.; Muller, H.
: Integrating the Scheme and C languages.
Guilt by association? My, you learned a lot on your way to a PhD.
: "Inner classes" is merely closures in a class scope.
No. They're worse than that.
: I was hoping we had finally gotten rid of most nested scoping, silly me.
You are welcome to use a different programming language.
: I liked Java because it was a egoless minimal parring of C++, but
: now they obviously want to be "genius language designers". Seems stupid
: to blow away multiple inheritance because its "too complex" and
: then later add a "class nesting hierarchy". Its too bad we not ever
: really going see the language as it would have been
: designed by Gosling.
I agree Java sucks. But how do you know Gosling is not a part of it now?
How do you know this current Java is what Steele would want it to be? If
one person has some good ideas in one context and other people take those
ideas and apply them in an awful way in another context, is it the fault
of the originator of those ideas? Let me see your brilliant logic work on
this.
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: Its then almost an "I am so knowledgable" intimindation technique.
Sorry. I am not trying to intimidate anyone. The lambda calculus takes
about half a page to describe. If you look at Scheme or Haskell, two
popular functional programming languages, the first thing you will notice
is their direct correspondence to the lambda calculus. If you read any
history of functional programming it will state that it all began with
Church in the 1930s.
: Phlip, I would suggest you peek in a programming language survey book
: to the functional language chapter if you really want a really basic
: overview of what functional languages are about.
Yes. Pick up the very good book _Haskell: The Craft of Functional
Programming_ and you will see that the entire book is about combining
functions into more powerful functions, just as I said in my previous
message.
Jay Martin
Patrick Logan wrote:
>
> Jay Martin <jaymm...@earthlink.net> wrote:
>
> : John Rose wrote the inner classes spec. John Rose has papers co-authored with
> : Guy Steele and he wrote the following paper:
>
> : Rose, J.R.; Muller, H.
> : Integrating the Scheme and C languages.
>
> Guilt by association? My, you learned a lot on your way to a PhD.
I learned you basically predict people positions by their past
work.
> : "Inner classes" is merely closures in a class scope.
>
> No. They're worse than that.
>
> : I was hoping we had finally gotten rid of most nested scoping, silly me.
>
> You are welcome to use a different programming language.
Every time I look at
>
> : I liked Java because it was a egoless minimal parring of C++, but
> : now they obviously want to be "genius language designers". Seems stupid
> : to blow away multiple inheritance because its "too complex" and
> : then later add a "class nesting hierarchy". Its too bad we not ever
> : really going see the language as it would have been
> : designed by Gosling.
>
> I agree Java sucks. But how do you know Gosling is not a part of it now?
I read interviews by Gosling.
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: Of course,
: verification is not really viable for the vast majority of commercial
: software.
Of course, verification is not really *attempted* for the vast majority of
commercial software.
: Heh, "Formal verification" and hacking in a weakly typed language, I sense
: a contradiction....
As you should know, Smalltalk is not a weakly typed language. Neither is
Scheme, it is also strongly typed and yet it has been formally verified.
Now what about C++?
: (I believe you can go all the way to a PHD at my school and not touch
: functional languages).
Which is a crying shame.
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: You have not contradicted a single one of my points. Pretty much
: just personal attacks. So where is the ignorance?
(1) I have attacked your logical reasoning, such as guilt by association.
(2) I have attacked your motives, which seem to be reducing all arguments
about anything related to software to one of socially organizing
"nitwits" (your term, I recall). Anything else to you is irrelevent.
As a result I have called you a "one trick pony", which is a metaphor
that discussions with you are frustrating because you do not engage in
any issue other than the one you can see right in front of you. (BTW
do you really enjoy working with "nitwits"? Why?)
(3) You have expressed falsehoods and innuendo. I have pointed these out
along the way.
Meanwhile *you* have called your co-workers "nitwits" and *all* computer
scientists you have grouped together as, what did you call them, idiots or
something?
Sheesh. I'd almost rather go back to useless discussions with Elliott
Coates.
: Until you understand that all programmers are not PHDs in functional
: language theory from MIT, that "programming in the large" with
: people requires certain compromises as your team may not all
: be geniuses, then I don't think you fully understand software
: engineering.
Until you understand that your co-workers are not "nitwits" I don't think
you fully understand software engineering either. (Or maybe you need a
different job. How much fun could it be?)
: Have you ever done large application development over a long
: period of time?
Yes. I have worked on five year projects involving hundreds of thousands
of lines of code.
: When you look at some language or theory do
: you think of the lamest programmer (call him "John") on some
: past team and think "what would "John" make of this shit".
When I look at some language or theory I think of how easy it is to
understand and how applicable it is today, or where it seems to be heading
tomorrow. I don't expect everyone to have the same interests, and I don't
expect to solve all the worlds problems either. I expect to continue
learning about things I find interesting and to continue discovering how
they can help today or how they may help tomorrow.
Patrick Logan
Jeff Younker <je...@snipe.mdli.com> wrote:
: Erlang is a functional language developed by, and used by, the telecom
: equipment corporation Ericsson.
: The video game crash bandicoot is written in a dialect of LISP.
Character generation for the Nintendo 64 games are done in Common Lisp.
Visa or one of the credit card companies has significant systems built in
Common Lisp. If you visit the sites of the CL vendors you'll find a lot of
applications written in that language.
Smalltalk is another semi-functional language that has a lot of "real
world" applications.
Jay Martin
Browser RANT : Sorry about the half done post. Netscape crap software has "send message"
set to cntl-enter. I truely hate this software. DIE Netscape DIE Netscape DIE...
(I am trying sooo hard not to use IE).
Patrick Logan wrote:
>
> Jay Martin <jaymm...@earthlink.net> wrote:
>
> : John Rose wrote the inner classes spec. John Rose has papers co-authored with
> : Guy Steele and he wrote the following paper:
>
> : Rose, J.R.; Muller, H.
> : Integrating the Scheme and C languages.
>
> Guilt by association? My, you learned a lot on your way to a PhD.
I learned you can basically predict people positions by their past
work. Most people can't face what they did or learned in the
past is basically worthless. Heh, I have no such limitations.
> : "Inner classes" is merely closures in a class scope.
>
> No. They're worse than that.
>
> : I was hoping we had finally gotten rid of most nested scoping, silly me.
>
> You are welcome to use a different programming language.
If the Java hype gets any bigger, then no one will basically have
a choice (I will then have to pronounce everything else as "dead").
Sometimes (usually after I look at "inner classes")
I hope MickeySoft crushes Java out of existence.
> : I liked Java because it was a egoless minimal parring of C++, but
> : now they obviously want to be "genius language designers". Seems stupid
> : to blow away multiple inheritance because its "too complex" and
> : then later add a "class nesting hierarchy". Its too bad we not ever
> : really going see the language as it would have been
> : designed by Gosling.
>
> I agree Java sucks. But how do you know Gosling is not a part of it now?
I read interviews with Gosling (I think at JavaSoft). I have seen him lecture,
I don't trust him as a language designer because I don't see he is dictorial
enough. A language needs a dictator for its architect if its going have a
clear vision for a coherent design. I have no problem with input, but there has
to be a "buck stops here" person. Otherwise, the language gets designed by
a committee and marketeers (which means its garbage).
The Java design is a closed process in a single company. Without spies we
will not know the true (and fun) politics occuring on the design.
Until they write a "the making of Java" paper we will probably not
know (and it probably won't have the juicy politics).
> How do you know this current Java is what Steele would want it to be?
I don't think its anything close. Too late in the game.
> If one person has some good ideas in one context and other people take those
> ideas and apply them in an awful way in another context, is it the fault
> of the originator of those ideas? Let me see your brilliant logic work on
> this.
Steele's name is on Java's Spec and is on the Java teem. Steele's research buddy
wrote the inner class spec (how did he get that job). You are saying there is
no connection at all? Steele was in the restroom when made all these decisions?
Jay
Eliot & Linda
Jay Martin wrote:
>
> Eliot & Linda wrote:
> > Are you aware that the code inside Ford motor vehicle electronic
> > egnition systems is formally verified? This is to avoid law suits and
> > to allow Ford to demonstrate that their software is free from defects.
> > Sounds practical to me.
>
> Great for them. A application of theory I didn't know about, my
> graduate courses in formal validation are not totally useless! Of course,
> verification is not really viable for the vast majority of commercial
> software.
Agreed. Doing formally-verified software is very expensive. Its much
more work with an even more limited skill-base. Hence it tends only to
get one when the costs of not doing it are very high; e.g. a
class-action law-suit by customers of a major car company when
electronic throttles fail open.
> > For an account of informal approached I
> > recommend you read the special issue of the CACM on the Shuttle, and how
> > structured walkthroughs as a verification technique didn't prevent a
> > simulated mid-launch abort crashing into the middle of Madrid.
>
> The problem is that the "ignition" system maybe slightly less complex
> than the Shuttle software and thus much easier to formally verify.
Right, but what about a nuclear power station? Or a nuclear weapons
system? Chernobyl was a mush more expensive disaster than Challenger.
>
> > > Its then almost an "I am so knowledgable" intimindation technique. The best
> > > approach is just to laugh at these bozos, they are truly living on another
> > > planet.
> >
> > If you find knowledge intimidating then I'm sorry for you.
>
> I don't have problems with knowledge, I have problems with snowing people
> with scientific technobabble.
That's cool. But Patrick was only trying to give a good definition;
something that's quite hard to do and that sets oneself up for
criticism. I agree that we should strive for jargon-free definitions,
but useful jargon can gain considerable concision [unlike e.g. my
writing style :/]
>
> > > (Then they, heh, probably say that the theory tells them that they
> > > should be hacking in Lisp, Smalltalk,etc).
> >
> > I must admit I like hacking in Smalltalk because its fun, its
> > high-leverage, and its beautiful.
>
> Heh, "Formal verification" and hacking in a weakly typed language, I sense
> a contradiction....
No contradiction. I always respected what could be achieved with
functional programming and formal derivation/verification, I just find
it "too hard" [there, you've said it, and you're still alive. Ed.].
Smalltalk suits me; I'm a visual thinker who always found symbol
manipulation (i.e. searching a space with re-write rules with no
intuitions to guide me) really frustrating. I suspect that the people
who are good at symbol manipulation develop powerful intuition to do it
"visually"; Einstein used to say he "felt mathematics in my chest";
that's a lot higher-level than where I feel it...
>
> > > Maybe there should be a
> > > "comp.object.theoretical.masturbation".
> >
> > Maybe there should be an ignorant.f***wit newsgroup too...
>
> Understanding when knowledge doesn't really apply is not ignorance.
> Most formal theory currently does not apply to the vast majority
> of software development
Agreed that formal approaches are not universally required, or even
possible. But that doesn't mean they're always inapplicable. It can
mean that we're not prepared to pay the up-front costs of avoiding
failure, and, as in so many other realms, we're prepared to leave others
to pay the much higher clean-up costs later.
After all, even if we don't program formally we construct formal
entities that follow rules, and (hopefully) we reason about these
entities to convince ourselves that they will work as intended.
> > > Phlip, I would suggest you peek in a programming language survey book
> > > to the functional language chapter if you really want a really basic
> > > overview of what functional languages are about.
> >
> > This month's SIGPLAN Notices has an article by Phil Wadler (yet another
> > British academic goes west :() describing a number of real-world
> > functional programming systems. Interesting reading.
>
> Sounds interesting. I really don't have problems with functional
> languages as the analness of say a strongly typed purely functional
> language is appealing. What I don't like is overselling them and
> then insinuating that "you are technically incompetent" if you don't
> recognize the "mathematical" superiority of the approach.
Agreed. I hold no particular candle for symbolic proof techniques; its
all reasoning and argument. And I'm a string believer in human "reason"
being based in informal perceptual mechanisms in the brain. e.g.
http://www.edge.org/discourse/index.cgi?OPTION=VIEW&THREAD=stanislas-dehaene/10-31-97/dehaene
My favourite example of the power of visual reasoning over symbolc
approaches is the following.
Give a proof of the possibility or impossibility of tiling an 8x8
chess-board which has two squares at opposite corners removed with 31
dominoes, each of which covers two ajacent squares.
Solutions will make my point.
But I think we're deluding ourselves if we think we can construct
systems without reason; symbolic, visual or otherwise. The superiority
of different approaches is something that can and should be measured,
and explored much like programming languages and environments have
been. Some in the formal verification community are trying to construct
interactive proof systems that are easy to use and understand in
analogous ways to the designers of environments like Smalltalk. Some in
the educational community are trying to help people visualize math, and
bring it alive away from dead symbols. Perhaps soon we'll look on proof
systems the same way we (or some of us) look at the evolution of
high-level languages, garbage collection, abstract data types and
interactive debuggers from machine code. One day proof systems may be
so easy to use and understand that they no longer intimidate.
This is actually very necessary. Remember the proof of Dykstra's
concurrent garbage collector? The proof was so complex and hard to
understand that bugs were found in it several times and several years
later [anyone have an accurate sequence of events?]. If proof systems
_can't_ be understood then their proofs won't convince, and hence won;'t
fit their purpose.
> Also
> being a research student, I am sensitive and a bit appalled on the
> need to "sell" research.
Quite. No comment :)
>
> > There are a number of Prentice-Hall International Series in Computer
> > Science books that have good coverage of functional programming:
> >
> > Implementing Functional Languages, Simon L. Peyton Jones, et al
> >
> > These three are a great introductory text into some core computer
> > science
> >
> > Programming Language Concepts and Paradigms
> >
> > Programming Language Syntax and Semantics
> >
> > Programming Language Processors : Compilers and Interpreters
> >
> > all by David A. Watt
> >
> > and
> > The Science of Programming (Texts and Monographs in Computer
> > Science)
> > David Gries / Paperback / Published 1987
> >
> > is a good introduction into pre-condition/post-condition style formal
> > development for imperative languages.
> > _______________,,,^..^,,,_______________
> > Eliot Miranda, ParcPlace
>
> This stuff will just scare the living crap out of him.
Nah...
> Also my "antennas" just twitched on the phrase "core computer science".
> (I believe you can go all the way to a PHD at my school and not touch
> functional languages).
That's a shame. I don't see how anyone can call themselves a computer
scientist if they don't have _some_ familiarity of imperative,
concurrent, functional, logic, and object-oriented "paradigms". Its
like being a western classical musician who's never even listened to
Indian classical music; its not clear one understands the breadth of
possibilities; one is limited by the lack of perspective.
I know I can't hope to be expert in all the disciplines of computer
science/software engineering, etc. But if I'm not aware of what's out
there how do I bring in people that are when its appropriate, and hence
how do I keep being effective?
One of the best things about a profession like ours is the joy of and
necessity to keep learning, and keep developing one's skills. One of
the saddest is seeing how inexperienced and armoured against learning
many new graduates seem to be. [But then USENET does provide a
self-selecting soap-box for pompous asses such as yourself, Eliot. Ed.]
_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace
Brian Rogoff
On Fri, 6 Mar 1998, Jay Martin wrote:
> Most formal theory currently does not apply to the vast majority
> of software development
OK, I can accept this. But there are may areas where formal theory is
important. I work in the EDA (electronic design automation) industry
and formal verification tools (right now, really just netlist equivalency
checkers, but they'll evolve) are pretty hot, most big companies have
substantial investments in this technology because simulatuion just isn't
enough.
> > This month's SIGPLAN Notices has an article by Phil Wadler (yet another
> > British academic goes west :() describing a number of real-world
> > functional programming systems. Interesting reading.
>
> Sounds interesting. I really don't have problems with functional
> languages as the analness of say a strongly typed purely functional
> language is appealing. What I don't like is overselling them and
> then insinuating that "you are technically incompetent" if you don't
> recognize the "mathematical" superiority of the approach. Also
> being a research student, I am sensitive and a bit appalled on the
> need to "sell" research.
Now, if you make these kinds of reasonable statements, rather than calling
people "crackpot" theoretical masturbators, I doubt you'd get much flack
(or attention :-). I took the same position vis-a-vis some extremists in a
polite news discussion myself; there is a bit of overselling of functional
programming, just like there is a lot of OO hype. Also, many useful
statically typed functional programming languages are not pure, and even
allow you to use loops rather than recursion (Caml).
(Personally, I'm not convinced that type inference is really good for
large scale software engineering since explicit types serve as useful
documentation, but it seems necessary for statically typed languages with
higher order functions. Fortunately Haskell lets you write out the
signature. More experience is needed.)
-- Brian
Jay Martin
> : verification is not really viable for the vast majority of commercial
> : software.
>
> commercial software.
>
> : Heh, "Formal verification" and hacking in a weakly typed language, I sense
> : a contradiction....
>
> Scheme, it is also strongly typed and yet it has been formally verified.
> Now what about C++?
Definition from PL book: "A language is said to be "strongly typed" if it
allows all type checking to be done statically."
Smalltalk and Scheme are "untyped" or dynamically typed which is why they
are not scalable programming languages. C/C++ is (heh) "just cast it" typed.
What has Scheme been formally verified to be, a toy? So someone wrote
a sematics for this tiny language. Does anyone care?
I find formal verification of programs and untyped languages
contradictory.
Rainer Joswig
In article <3501B48E...@earthlink.net>, Jay Martin
<jaymm...@earthlink.net> wrote:
> Smalltalk and Scheme are "untyped" or dynamically typed which is why they
They are hardly "untyped".
> are not scalable programming languages.
You can find type errors. Atleast at runtime. Then you can find
them easily. And debug and fix them. Some compilers will find
them at compile time. (In C you are having a hard time
finding them at compile time *and* runtime.)
Ironically these systems tend to be very stable. My Lisp machine
(which is a *development* system for me also) in office has an uptime
of ca. three months. The OS is a large soup of typed Lisp objects. I have seen
a lot other systems rebooting in the meantime.
> What has Scheme been formally verified to be, a toy? So someone wrote
> a sematics for this tiny language.
Great.
> Does anyone care?
Sure.
> I find formal verification of programs and untyped languages
> contradictory.
This may be only you.
--
http://www.lavielle.com/~joswig/
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: > Guilt by association? My, you learned a lot on your way to a PhD.
: I learned you basically predict people positions by their past
: work.
That has its flaws too. But you were not doing this. You were assigning
guilt by association. That is a different thing.
: > I agree Java sucks. But how do you know Gosling is not a part of it now?
: I read interviews by Gosling.
References?
Patrick Logan
Jay Martin <jaymm...@earthlink.net> wrote:
: Definition from PL book: "A language is said to be "strongly typed" if it
: allows all type checking to be done statically."
That is a misleading definition. In Smalltalk and Scheme it is impossible
to perform an operation on an object if that operation is not defined for
that type. How much more "strong" can it get?
: Smalltalk and Scheme are "untyped" or dynamically typed which is why they
: are not scalable programming languages.
Scalable in what way? There are *very* large systems written in Smalltalk.
Eliot & Linda
Jay Martin wrote:
>
> Patrick Logan wrote:
> > Scheme, it is also strongly typed and yet it has been formally verified.
> > Now what about C++?
>
> allows all type checking to be done statically."
The book is _wrong_. It is a bad definition. Try these...
A language is said to be "statically typed" if it allows
all type checking to be done statically at compile-time.
A language is said to be "strongly typed" if it ensures that
operations can only be applied to the correct data types.
A language is said to be "explicitly typed" if it maintains
type information by associating it with variables.
A language is said to be "implicitly typed" if it maintains
type information by associating it with data.
And the following pair are really implementation details;
common strategies for implementing the above policies:
A language is said to be "statically bound" if the determination
of which code an application of an operation invokes is made
at compile-time.
A language is said to be "dynamically bound" if the determination
of which code an application of an operation invokes is made
at invocation time.
>
> Smalltalk and Scheme are "untyped" or dynamically typed which is why they
> are not scalable programming languages. C/C++ is (heh) "just cast it" typed.
"Mostly dead is not all dead". "dynamically typed" can't mean
"untyped".
> What has Scheme been formally verified to be, a toy? So someone wrote
> a sematics for this tiny language. Does anyone care?
Scheme is being used to implement some extremely strategic software.
For example, Oracle are implementing their Java virtual machine, which
will run Java queries inside their database, in Scheme.
> I find formal verification of programs and untyped languages
> contradictory.
That's because you use a non-sequitur: "untyped". The only thing
untyped about the Lisp and Smalltalk group of languages is their
variables. Given that statically-typed systems still allow the writing
of type-correct programs exhibiting logic errors how do static type
systems provide program correctness?
_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace
Tim Ottinger
Jay Martin wrote:
> I learned you can basically predict people positions by their past
> work. Most people can't face what they did or learned in the
> past is basically worthless. Heh, I have no such limitations.
;-)
But remember that an expert is a person who knows what all the
mistakes look like. Your experiences have more value in the
abstract than in the details, maybe, but there is profit in all
labor.
> If the Java hype gets any bigger, then no one will basically have
> a choice (I will then have to pronounce everything else as "dead").
> Sometimes (usually after I look at "inner classes")
> I hope MickeySoft crushes Java out of existence.
You know, Python is growing like crazy and has a lot of things
torecommend it. It's not a
perfect "industrial" languge, but it's a mighty
productive one, and I think that it's becoming a real player when it
comes to scripting languages, web development and some other
applications (internal use stuff, GUI apps, etc). There's no reason I
know that you can't produce industrial apps with it, but I just haven't
tried.
There are lots of languages growing and developing.
Smalltalk isn't dead yet (and probably won't be as long as
they keep cranking out great frameworks and working apps
in it, esp now that you can get so many free versions), Eiffel
is still a possibility, and I hear that Ada 95 is really some great
stuff even though it's been slower to catch on.
So when Java and C++ get on your nerves, there are plenty
of viable escapist[sic] routes ;-) you can take. When I get
tired of C++, I escape to Python for a pause that refreshes.
Then I come back to C++. I'm playing with Java mostly as a
diversion and prep. I'm learning Smalltalk next year. It
eliminates that single-language myopia.
> I read interviews with Gosling (I think at JavaSoft). I have seen him lecture,
> I don't trust him as a language designer because I don't see he is dictorial
> enough. A language needs a dictator for its architect if its going have a
> clear vision for a coherent design. I have no problem with input, but there has
> to be a "buck stops here" person. Otherwise, the language gets designed by
> a committee and marketeers (which means its garbage).
Eiffel, Python, and Perl (which is becoming an increasingly "real"
language ;-) are run by benevolent dictators. I don't know how
Smalltalk and Ada 95 are in this regard.
Just some suggestions for happier living...
Tim
Brian Rogoff
On Sun, 8 Mar 1998, Eliot & Linda wrote:
> Jay Martin wrote:
> > Smalltalk and Scheme are "untyped" or dynamically typed which is why they
> > are not scalable programming languages. C/C++ is (heh) "just cast it" typed.
I don't see what dynamic typing has to do with scalability. The only
scalability issue I see with Smalltalk is its lack of a module system.
Any modular Smalltalks out there?
Also, type inference technology kind of blurs the issue of static and
dynamic typing, making Eliot's latent/explicit distinction the more
important one. Some recent Schemes (MzScheme from Rice U) use an ML style
type inferencer, and have powerful module systems.
> > I find formal verification of programs and untyped languages
> > contradictory.
>
> That's because you use a non-sequitur: "untyped". The only thing
> untyped about the Lisp and Smalltalk group of languages is their
> variables. Given that statically-typed systems still allow the writing
> of type-correct programs exhibiting logic errors how do static type
> systems provide program correctness?
Obviously they don't, but in the opinion of many people they provide an
additional level of safety which contributes to the correctness of a
system. Similarly, space leaks are still possible in garbage collected
systems, yet GC also contributes (greatly!) to the prevention of space
leaks.
That's not to say that I'm religious about static vs dynamic typing, or
explicit vs latent types. I like Ada *and* Lisp :-).
-- Brian