andrewducker: (Default)
andrewducker ([personal profile] andrewducker) wrote2009-04-09 03:38 pm

Musings

I've been coming to the conclusion that I don't like the way that methods return variables in C-like languages.  Having a single prioritised output parameter seems counterintuitive to me, and leads to two outcomes:
1) It's very easy to ignore/forget the return value.
2) If you have multiple return values then either one of them is the "proper" return value and the other one is passed back as a reference, or you pass back a tuple of some kind, or you have no return value and they both come back as references. 

It seems to me that it would be clearer and simpler if you always specified what parameters were in and out.

Rather than
string Reverse(string inputString)
you'd have
Reverse (string inputString, out string outputString)

This doesn't make a lot of difference when it comes to a simple method like that.  But if we take one with two outputs:

Do we use:
1) int GetMonthAndDay(DateTime inputDate, out int day)
2) MonthDayPair GetMonthAndDay(DateTime inputDate)
3) void GetMonthAndDay(DateTime inputDate, out int month, out int day)

The first one is clearly awful, the second one requires me to create an extra class, and the third one seems entirely clear.

Also, the use of different parameters means that you have smart method selection going on.
Convert(DateTime inputDate, out long seconds)
Convert(DateTime inputDate, out string nicelyFormatted)
makes it obvious from the parameters exactly what you're expecting to get back from it.

Of course, it does complicate very simple things:
DateTime tomorrow = today.AddDay();
would become
DateTime tomorrow;
today.AddDay(out tomorrow);

I suspect I'm just working on stuff where there are always multiple ins and outs, and also using generics and type inference, which doesn't work on return values, just parameters, and this is leading me to odd conclusions.

[identity profile] figg.livejournal.com 2009-04-09 04:19 pm (UTC)(link)
Um, no, It works quite well for prolog.

The problem is that function composition is a bitch
instead of doing


y = f(g(x)), you have to do f(x,x1), g(x1,y)

this gets very clumsy and annoying after a while.

Functions are useful for the common case of a single return, and in more mature languages you can return multiple values as pairs.

[identity profile] figg.livejournal.com 2009-04-09 05:25 pm (UTC)(link)
Prolog isn't object orientated, and abstract datastructures are a piece of piss.


To be frank, I haven't encounted such a problem with python, named parameters and easy tuples make this sort of problem a breeze.

Oh, and you're confusing strict and strong typing. Strict typing is type definition at compile time, and dynamic is at runtime.

Strong typing is the lack of implicit casts, and weak typing has implicit casting.


Oh, and saying 'hey intellisense makes this easy' is akin to 'hey this crutch makes it easy to walk with a broken leg'.

[identity profile] martling.livejournal.com 2009-04-10 10:33 am (UTC)(link)
Tuples are part of the core type system in Python. You don't have to declare a class to hold your tuple, you can just return "foo", 3. The same is true of most functional languages, e.g. (string, int) is a valid type in ML.

It's a shame this is missing from Java, it seems it was planned originally: http://gbracha.blogspot.com/2007/02/tuples.html

I gather that adding this to C# would be difficult now because essentially the CLR type system doesn't have the underlying support. F# has tuples in the language but the underlying implementation is a hack.

Incidentally, has [livejournal.com profile] figg told you about the gathering he is organising for people interested in programming languages?

[identity profile] martling.livejournal.com 2009-04-10 11:50 am (UTC)(link)
Oh, sure, it's still Python and therefore a non-confidence-inspiring dynamically typed mess. But the basic principle of tuples as a core part of the type system could be added to to any language - it's just sadly pretty rare outside of functional languages.

If you had them in a statically typed C-like language you could do this:

(int month, int day) GetMonthAndDay(DateTime inputDate) {
    return (inputDate.getMonth(), inputDate.getDay());
}


And then call like this:
(int month, int day) = GetMonthAndDay(date);


Note that as first-class types, tuples would also be usable for input parameters, variables, etc.

(int month, int day) month_and_day;
month_and_day = GetMonthAndDay(date);
int day = month_and_day[1]; // address like arrays.
int month = month_and_day.month; // or like structs, if contents named
 birthdays = GetBirthdays(month_and_day);

[identity profile] martling.livejournal.com 2009-04-10 12:28 pm (UTC)(link)
I don't see any reason why the tuple members couldn't be accessed by name, if names were given for them where the tuple was declared. I suggested this in the the penultimate line above.

The function in that style:
(int month, int day) GetMonthAndDay(DateTime inputDate) {
    return (month = inputDate.getMonth(), day = inputDate.getDay());
}


I'd think of them rather as anonymous C-style structures than as classes - there's nothing specifically object-oriented here.