Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1884

Re: functions as objects

Show all headers | View raw

On 7/4/2012 3:20 PM, Dmitry A. Kazakov wrote:
> On Wed, 04 Jul 2012 14:02:24 -0500, BGB wrote:
>
>> On 7/4/2012 11:12 AM, Dmitry A. Kazakov wrote:
>>> On Wed, 04 Jul 2012 10:08:25 -0500, BGB wrote:
>>>
>>>> On 7/4/2012 2:28 AM, Dmitry A. Kazakov wrote:
>>>>> On Tue, 03 Jul 2012 14:56:49 -0500, BGB wrote:
>>>>>
>>>>>> or better yet, to have a language which (actually) supports closures.
>>>>>
>>>>> A closure carries an implicit context allowing accessing it at the callee's
>>>>> side. Since the effect of a call is not limited to the arguments declared,
>>>>> closures are barely testable and lack contracts to be verified upfront.
>>>>> Even most vegetarian downward closures may cause troubles.
>>>>>
>>>>> The advantage of having an object is that all things the operation would
>>>>> touch could be placed in there. It is not always a better choice than a
>>>>> downward closure, but frequently it is.
>>>>
>>>> the problem though with an object is that often creating them requires
>>>> more code, calling them requires more code, ...
>>>
>>> More code than a closure? Certainly not. Techniques used to pass the
>>> closure's context are more heavy weight than an object passed by value or
>>> reference.
>>>
>>> Clearer contracts work better for both the programmer and the compiler.
>>
>> typical languages allowing closures allow the programmer to write
>> something like "foo(x, y);" to make a call, and "bar(function(x,
>> y){...});" to construct and pass a closure.
>
> I see, I thought code = object code. Sparing a pair or two of characters is
> addressed below.
>
>>>>>> "type safety" is IMO often more of a "false concern",
>>>>>
>>>>> Really? If the "true concern" for you is the program length, then it seems
>>>>> that you have problems of handling that program. Why do you have them?
>>>>> Because of bugs? So, safety still seem to be a concern. Now, how strong
>>>>> typing is false safety and pointers [to functions] is true safety?
>>>>
>>>> it is not about program length, but rather about productivity.
>>>
>>> So safety is no more a concern? It is "productivity" now. But productivity
>>> includes maintainability. Remember that writing code is about 10% of total
>>> cost.
>>
>> yes, but there is already a fair amount of type-safety in nearly any
>> "reasonable" statically-typed language.
>>
>> having an awkward-to-use language does not help with safety, just makes
>> doing things more painful, but it is common to equate the pedantic error
>> messages and awkwardness with the type safety.
>
> I don't see the point. Bad languages prove nothing. To make your point you
> have to show that statically typed languages are inherently awkward. Yes, I
> know, you probably have a prejudge against static typing and are expecting
> bells ringing to anybody else. But they don't to me. (:-))
>

I was never saying I opposed static type-checking, or that it was 
inherently awkward, just the particularly ways certain languages, 
especially Java (especially older versions of the language, and 
"idiomatic" ways of using the language), handle some things, is a bit 
awkward.


namely, I generally much prefer writing code in certain other languages, 
such as, C, C++.

there is also C#, which I would like (IMO it has a better language 
design), except that .NET is itself a bit limiting (namely in that Mono 
on Linux kind of sucks, as it doesn't really work with C++/CLI, ...).

this leaves C and C++ as my main languages.


>> I tend not to believe code is more "type-safe" because it requires 2x as
>> many explicit casts.
>
> Why there should be casts? And how is this related to closures vs. objects?
> If the language for any reason needs casts, it will require them for
> closures, their parameters and results in the same amount it would do for
> other objects. This is an independent issue.
>

you need casts because the Java compiler requires them, and because many 
people equate the use of all the explicit casts with being "type-safe".


I disagree though that type-checking based on a class or interface is 
more "type-safe" than type-checking based on having a compatible 
function signature.

say, we have a "delegate" keyword, which may be used something like:
delegate int Foo(int x, int y);

int someFunc(Foo fcn)
    { return fcn(3, 4); }
int anotherFunc(int x, int y)
    { return x+y; }
...
someFunc(anotherFunc);



which is this really, less type-safe than, say:

private interface IFoo
{
    public int foo(int x, int y);
}

public int someFunc(IFoo fcn)
    { return fcn.foo(3, 4); }

private class SomeClass implements IFoo
{
    public int foo(int x, int y)
       { return x+y; }
}

...

someFunc(new SomeClass());

or:

someFunc(new IFoo() {
    public int foo(int x, int y)
       { return x+y; }
});


>> like, the language is "type safe" because you have to manually up-cast
>> and down-cast your numeric values, ...
>
> Fix the language.
>

well, that is the problem.
I don't control the language in question here.


I control a different language, and use different type-conversion rules, 
namely having implicit type-promotion but warning on implicit 
type-reduction.


>>>> productivity is often closely linked with code-output volume,
>>>
>>> Nope, it is linked with the complexity of the code and its quality.
>>
>> which is also linked with how much code a person has to write to
>> complete a given task.
>
> Wrong. You assume that the time spent on solving a task depends on the
> amount of code. This is plain wrong. As a counterexample consider well
> documented structured code and one compressed by zip. The latter is
> sufficiently shorter.
>

I am assuming sensibly written code here, and note that I am mostly 
writing about things like it being necessary to declare classes and 
instantiate objects for things, rather than about things like 
keywords-vs-operators or similar.

for example, in early Java it was necessary to specify the class to 
access static members, so:
"Math.sin()", "System.out.println();", ...

whereas later versions added "static import", making this optional (if 
compiling for a newer version), at a new cost:
many people believe "static import" is evil and should not be used.


>> if more code is required to complete a task in a given language, very
>> often, it is boilerplate, and thus could be better if it were not required.
>>
>> for example, is:
>> if(stra.compareTo(strb)>0) { ... }
>>
>> really "safer" than, say:
>> if(stra>strb) { ... }
>
> I don't understand this example. Both look like a mess to me, especially
> the first one.
>

the first one is how string compares are generally done in Java.

some other languages make '>' and '<' and friends just so happen to work 
on strings.


>>>> the problem is that many of the "type safety" rules are themselves
>>>> frivolous,
>>>
>>> Fix the language.
>>
>> depends on the language.
>
> Yes, ones fixed and ones not yet fixed.
>
>>>> example:
>>>> the programmer might care that they are implicitly converting from a
>>>> float to an int or short (or long);
>>>> they probably don't need to care that they are implicitly converting to
>>>> a double;
>>>
>>> Never.
>>>
>>> 1. One is not substitutable for another. Which precisely means that
>>> implicit conversion may change the semantics of the program, e.g. raise an
>>> exception, evaluation of garbage etc. The language shall not make
>>> assumptions.
>>>
>>> 2. Now if not all range of the corresponding types are used then it is the
>>> programmer's fault not to declare the range and the language fault not to
>>> allow such type declarations, so that the compiler have no information to
>>> prove the conversion safe. See? The problem is less typing, not more
>>> typing.
>>>
>>> Either #1 or #2.
>>
>> I disagree.
>
> Then show #3.
>

int x;
long y;
y=x; //?

compiler shouldn't need to complain about this, it should just convert 
the stupid type.

likewise:
float f;
double d;
d=f; //?


but probably not:
long x;
int y;
y=x; //?

because in this case, x may hold values that don't fit in y (x has less 
range).


another example (different language):
unsigned int x;
long long y;

if((x+y)<0)
{
	//?
}

in C and C++ rules, execution will never get to the point in question, 
because the "unsigned" is sticky, so the type of "x+y" is "unsigned long 
long".

better would be if the compiler would instead note that the entire range 
of "unsigned int" will fit inside "long long", and then promote to a 
signed type.

if still following the C rules, better for this case is to have the 
compiler issue a warning.


there is no direct Java analogue, since Java lacks explicit unsigned types.


>>>> now, for type-safety and function-pointers:
>>>> it should be sufficient to check that they have the correct signature.
>>>
>>> How do you check them without typing? Correctness check requires at least
>>> comparing types of the arguments and results.
>>
>> the language knows the types
>
> Thus the whole rant against type was bogus.
>

it was not against static types in the first place, but rather about the 
perceived need for explicit casts and then equating this with being 
type-safe, rather than having the compiler just be like "well, whatever, 
I will convert the types to a common super-type and do arithmetic on 
this..." (like it does in C and C++).


it is roughly along similar lines to the whole "goto == evil" thing, or 
the issues on when and where braces are used (opening brace on the same 
line or the next, ...).


>>> And again, pointers have all sorts of issues, like storing them in a global
>>> variable and calling the procedure later when its context is already dead
>>> and gone. Downward closures are much cleaner, at least. For callbacks, I
>>> would always use objects.
>
> [...]
>> a lot of this stuff can be statically determined at compile time.
>
> With objects there is no problem in first place.
>

yes, but the problem of "objects" is when you have to also write out the 
class declarations.

typical closures do so without requiring any sort of class definitions.

"anonymous classes" and JDK7+ lambdas fall into a grey area (lambdas 
resembling a closure, but are built on top of SAM interfaces and 
anonymous classes).

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

functions as objects bob <bob@coolfone.comze.com> - 2012-07-02 08:15 -0700
  Re: functions as objects Rui Maciel <rui.maciel@gmail.com> - 2012-07-02 17:42 +0100
  Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-03 14:56 -0500
    Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 09:28 +0200
      Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 10:08 -0500
        Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 18:12 +0200
          Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 14:02 -0500
            Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-04 22:20 +0200
              Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-04 19:42 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-05 11:30 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-05 10:33 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-06 10:50 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-06 08:32 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-06 16:45 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-06 10:48 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-07 21:28 +0200
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 16:33 +0100
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-08 18:20 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-08 16:27 -0500
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-09 09:35 +0200
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-09 09:48 +0100
                Re: functions as objects "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-07-09 11:40 +0200
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-09 11:02 -0500
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 16:34 +0100
                Re: functions as objects BGB <cr88192@hotmail.com> - 2012-07-08 16:11 -0500
                Re: functions as objects "BartC" <bc@freeuk.com> - 2012-07-08 23:35 +0100

csiph-web