More coding fun

[andrewducker]

Julie was around for the weekend, although she then vanished off this afternoon to slave over a report. It was very relaxing - and I'm leaving plenty of holes in my schedule to make sure we both get more relaxing time, at least until her work calms down again.

Meantime, I've discovered that C# 3.0 allows you to write code like this:

doggies.ForEach(
    dog => dog.Paws.ForEach(
        paw => paw.Claws.ForEach(
            claw => claw.Clip())));

which is the equivalent of the code from the other day, only even more concise. I don't think it's actually any more readable though. Lambda functions seem to be pretty neat - but I haven't spotted many places I'll be using them so far. Maybe when I've played with them a bit more...

Comments

[martling.livejournal.com]

Ever used a functional language?

[figg.livejournal.com]

If the answer is no, you should consider changing it to a yes.

Aside, here is a raytracer written in LINQ (Those C# 3.0 extentions)
http://blogs.msdn.com/lukeh/archive/2007/10/01/taking-linq-to-objects-to-extremes-a-fully-linqified-raytracer.aspx

[call-waiting.livejournal.com]

If you mean 'changing it to a yes because C# 3.0 has functional features', I'd say that should still be no since C# is 'multi-paradigm' rather than 'functional' and it's possible to use it for years without using a single functional feature or idiom ;)

[andrewducker]

Yup. But not since university.

[khbrown.livejournal.com]

But is there anything that LISP didn't do better, 40 years ago, other than gain market and mindshare?

[andrewducker]

Meh. LISP looks great for manipulation of list structures, but I'm not sure how you'd use it to write UIs, manipulate XML, etc.

[khbrown.livejournal.com]

Are these examples of fundamental inadequacies in the language itself, or just a reflection of its emerging prior to these technologies?

Presumably you can write anything in any Turning-complete language with a greater or lesser degree of difficulty, depending on what libraries and so forth are available to make the job easier?

[andrewducker]

Oh, I'm sure you could. But a brief look at XML handling code for LISP made me feel somewhat terrified.

I _like_ strong typing, Object Orientation, etc. In fact, the thought of writing UI code in something that wasn't OOP fills me with dread.

[drdoug.livejournal.com]

I don't think using a functional language for UI code is a good plan anyway - it's the wrong tool for the job. Like trying to use a scalpel to cut down a tree, or a baseball bat to play snooker. You could probably do it if you're careful but you'll get little pleasure from the exercise, and the skills you need to do it are not really the ones that show the tool to its best advantage.

[andrewducker]

That was my feeling. Lots of programming languages (and language types) are very good for certain things, and very bad for other ones. COBOL is amazingly fast at processing millions of lines of text serially. And it makes complexity obvious, so you avoid tying up the mainframe unnecessarily. I wouldn't use it for writing games in though.

[khbrown.livejournal.com]

Useful to remember for the next time the LISP does/did X line comes up :-)

[call-waiting.livejournal.com]

I think there's a fairly clear consensus is that OO is more or less 'the' way to do GUI programming, as it's fundamentally an object oriented task, and both are quite closely related to the way humans perceive and comprehend their physical environment. In fact, I find it hard to imagine a sensible way of programming GUIs in, say, a pure functional language that didn't involve reinventing OO to a large degree.

A case in point seems to be this 'simple' example of a trivial GTK+ application written in Haskell:

http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html

Ow, my aching head.

[andrewducker]

To expand slightly - I liked playing with functional languages. I also liked playing with Prolog. I learned a lot about writing recursive code from them (amongst other things). Nowadays I'd rather have something OOP that allows me to have functions as part of the language but doesn't force me to work that way.

[martling.livejournal.com]

Yes, I've always wanted a language that would let me do some bits procedurally, some functionally, etc.

F# looks potentially interesting.

[andrewducker]

It does. But I didn't see much there that you can't do in C#.

[martling.livejournal.com]

Can you have higher order functions in C#?

That's what really gives you the ability to reduce stuff like the above example to a one-liner along the lines of:

map(clip, descend([paws, claws], doggies))

[andrewducker]

What's a higher order function?

I could certainly write a "descend" function that would look through "doggies" for "paws" and then through that for "claws" - using reflection. Ooh - in your example there, what type are "paws" and "claws"? I assume that the first parameter of descend() is an array of something - I'm just not sure what...

Oh - and yes, you can pass around function pointers, if that's what you mean. And they're strongly typed. Look up "delegates".

[martling.livejournal.com]

What's a higher order function?

A function that deals with other functions, i.e. takes them as arguments and/or returns them.

The "descend" there is a function that takes a list of functions and then a list of values.

If the values are of type dog, the functions must be of types that chain together from that, e.g. paws is a function of type (dog -> list of paws), claws is (paw -> list of claws), and then the return value of the overall descend will be a list of claws.

The fact the type system is able to understand and enforce things like that is the cool thing.

With function pointers alone, any implementation of descend would have to set in advance the types of the functions it took. Using common forms of reflection, you'd pass in the names of functions as strings and have to do any type checking at runtime.

The descend function would be a line or two in a functional language and implicitly typed, yet formally provable to be typesafe at compile time.

[andrewducker]

The problem with delegates in C# is that they're a pointer to an instance of a function on a particular instance of an object.

C# has some type inference, I'm just trying to work out if I can use it in the way you're talking about. I don't think so though. At compilation it would have to look at the collection, find what type it was a collection of, check that that class had a particular method on it, check that whatever class that method returned had the next method in the array on it, and so on.

I can see how it works, but C# isn't going to allow that. Oh well.

You _can_ pass function pointers about - but not as flexibly as you need in your example while being assured that it would pass type checking when you got there.

[martling.livejournal.com]

More generally, the limitation on function pointers is that they must be pointers to predefined functions. You can't e.g. take a function, compose it with another function, and return the result as a new function. Although C# delegates appear to give you a limited form of closures (where you take a function, bind some but not all of the arguments to given variables or constants, and return the resulting function that now takes fewer arguments).

[andrewducker]

True, you can't do that. Unless that function is designed to take a function as one of its parameters.

And functions can't have bits of their parameters filled in before they're passed on, so you can't do that. You could fake it in various ways, but it wouldn't be caught by the compiler.

Gosh. All sorts of things I didn't even know I was missing!

[andrewducker]

Looking around today, when I had some time, it seems that I was right in thinking that MapReduce is fairly trivial in C# (and it's easier in version 3.0, with lambda expressions rather than delegates).

Descend is still clearly beyond it - and some googling isn't finding me much about its use. Can you point me at a good resource?

[johnbobshaun.livejournal.com]

Neat. That kind of syntax always brings to mind Ruby to me, although Smalltalk works in much the same way. I *think* this would be the equivalent in Ruby (although I'm a little rusty).

doggies.each do |dog|
dog.Paws.each do |paw|
paw.Claws.each do |claw|
claw.Clip()
end
end
end

[andrewducker]

You really should wrap a <pre> around that code :->

But yeah, reminiscient.

Of course, once you get used to imperative languages the basic stuff (loops, branches, assignments) all starts to look similar.

[johnbobshaun.livejournal.com]

Oops. Forgot that it would kill my formatting.

And, yes, totally.