Comment Feed for Erik Meijer: Functional Programming (Going Deep on Channel 9)

Re: Erik Meijer: Functional Programming

evildictaitor — Tue, 12 Feb 2008 04:58:30 GMT

ivan_ wrote:

I haven't read all of the posts. But what does IO do besides telling me/compiler/whoever that the function is impure?

For example if I define a function which returns int, but could also have exceptions, than from a pure functional approach I can also get a super set of two. IE = {int U Exception} and let my funciton return IE, in that case it would be very "honest", wouldn't it? Why not have some suffix? int impure_function(x)....?

The point of the type-purity is not to help the programmer (e.g. function suffixing), but to help the compiler to optimise your code.

With regards to exceptions, they are generally a thing of the imperative world, since undefined behaviour is exceptional behaviour inside of functional languages by default, for example in C#:

int factorial(int i){
if(i == 0) return 1;
return i * factorial(i-1);
}

does bad things if you don't check for (i < 0) and throw an exception - factorial(-2) should throw an exception. However, in Haskell:

Factorial :: Int -> Int
Factorial i
| i == 0   = 1
| i > 1 = i * (Factorial (i-1))

throws a pattern-match failure (read "argument exception") when you try Factorial -2.

You can, of course, implement exceptions:

Factorial :: Int -> (Maybe Int)
Factorial i
| i == 0   = Just 1
| i > 1     = Just (i * (Factorial (i-1)))
| i < 0     = Nothing -- Read "exception"

It seems a lot of people are getting hung up on the notion of "honest". The point is not that the programmer is "honest" about his intentions - it's that the compiler can prove things about the program - the contracts in Haskell and in other functional languages which employ such safeguards cannot be trivially broken, so it guarrantees honesty - breaking it takes some real effort.

Re: Erik Meijer: Functional Programming

ivan_ — Mon, 11 Feb 2008 18:53:52 GMT

I haven't read all of the posts. But what does IO do besides telling me/compiler/whoever that the function is impure?

For example if I define a function which returns int, but could also have exceptions, than from a pure functional approach I can also get a super set of two. IE = {int U Exception} and let my funciton return IE, in that case it would be very "honest", wouldn't it? Why not have some suffix? int impure_function(x)....?

Re: Erik Meijer: Functional Programming

sylvaan — Sat, 02 Feb 2008 05:57:04 GMT

I'm just joining this discussion. But, I can't help being reminded about where I was at in 2002 with C++ claiming that template basesd metaprogramming was revolutionary, when in fact, it was too complicated for most people to use to solve real world problems, and as a result of that (and other things) alot of those developers moved to the much more "designed with the needs of the developer" C# / .NET 1.1.

I bought pared down generics, made sense to type collections for many reasons. Solved a very common problem.

Now, I think that some of this stuff wont ever be used as much more than an intellectual curiosity - just like bind2() and whatnot wasn't ever used in C++ on any large scale, stl/boost whatever. They just didnt't meet any real need in particular, other than the needs of the developers to feel smart - and they had developers writing code that DID NOTHING (it was generic though, and it WOULD work on antyhing), but would if only if YOU used it correctly (Assuming you could figure out how). Which restates the last bit - lots of work went into writing generic libraries which never were used because they were felt to be WAY out of touch with the needs joe blow coder.

A path siimiar to this killed C++ in my mind. Why do you feel that this wont end in the same result.

Also - why do you have to even bother the developer with this at all. Can you do this using the intermediate representation? just like out of order execution of CPU instructions.

The last thing that a developer likes to see are things in his code that he doesnt fully understand - those most likely get rewritten in the real world - since who wants to maintain code they dont understand.

Re: Erik Meijer: Functional Programming

evildictaitor — Thu, 31 Jan 2008 22:42:07 GMT

punkouter wrote:

not exactly, i mean, if right now i have a solution which i built using C#, and then suppose I want to make a 'parallel' library using Hashkell/CLR (if there is such a thing), or a FP, Erik said that it can be done by compiling the code to assembly and when I load it up to my C# solution ignoring the monads (IO(), etc ) will make it usable (or maybe, compiling it to CLI will strip the monads altogether). But, how about the other way around? Suppose that my FP library needs to use a business object (not necessarily a complex one, maybe a transfer object) from my C# assembly, can it be done?

There is such a thing - it's called F#, which is a sort of Haskell/CLR thing.

If you're developing a program in F#, you can also do the reverse, and load a program written in C# or VB.NET - since both are compiled to CIL, F# reflects out the program, and attempts to work out which functions are monoidal and which are computational, and labels them accordingly.

So in conclusion, yes, an F# application can use C# logic, and a C# solution can use code written in F#.

Re: Erik Meijer: Functional Programming

punkouter — Thu, 31 Jan 2008 02:33:26 GMT

evildictaitor wrote:

punkouter wrote:
Erik, thanks for the great video. However I have a question, you said that we can integrate FP with imperative programming by ignoring the monads (IO()) from the type. I think this is feasible, but you can't do the other way around right?

You mean integrate imperative programming into functional programming by inserting a monad into the type signature? That's certainly feasible.

For a good example of a functional programming living alongside imperative programming, I'd really recommend having a bash at F# - it's all the power of C# with all the conciseness of Haskell.

Although I'll never forgive Microsoft for having more people working on Haskell than Sun has working on Java

not exactly, i mean, if right now i have a solution which i built using C#, and then suppose I want to make a 'parallel' library using Hashkell/CLR (if there is such a thing), or a FP, Erik said that it can be done by compiling the code to assembly and when I load it up to my C# solution ignoring the monads (IO(), etc ) will make it usable (or maybe, compiling it to CLI will strip the monads altogether). But, how about the other way around? Suppose that my FP library needs to use a business object (not necessarily a complex one, maybe a transfer object) from my C# assembly, can it be done?

Re: Erik Meijer: Functional Programming

evildictaitor — Thu, 31 Jan 2008 01:48:23 GMT

punkouter wrote:

Erik, thanks for the great video. However I have a question, you said that we can integrate FP with imperative programming by ignoring the monads (IO()) from the type. I think this is feasible, but you can't do the other way around right?

You mean integrate imperative programming into functional programming by inserting a monad into the type signature? That's certainly feasible.

For a good example of a functional programming living alongside imperative programming, I'd really recommend having a bash at F# - it's all the power of C# with all the conciseness of Haskell.

Although I'll never forgive Microsoft for having more people working on Haskell than Sun has working on Java :P

Re: Erik Meijer: Functional Programming

punkouter — Thu, 31 Jan 2008 01:43:36 GMT

Erik, thanks for the great video. However I have a question, you said that we can integrate FP with imperative programming by ignoring the monads (IO()) from the type. I think this is feasible, but you can't do the other way around right?

Re: Erik Meijer: Functional Programming

Erik_H — Fri, 25 Jan 2008 09:51:35 GMT

Thanks, Sylvan.

I'll see if I can express it in C# myself =).

I had another (stupid?) idea:

With all the talk about SOA, would it be possible to hide the complexity of a webservice call in a monad, so that you could combine functions across a network seamlessly?

/Erik

Re: Erik Meijer: Functional Programming

aL_ — Thu, 24 Jan 2008 23:36:45 GMT

sylvan wrote:

My totally un-diplomatic answer is: Yes, it does, which is why dynamically typed languages will prove to be a dead end for anything but the simplest of shell scripting.
...
We need more static checking, not less.

Thats exactly my feeling as well.. in college we had a course in smalltalk and our professor happily exclaimed that "its a great language, you can change anything! you can change the way everything from how strings behave to the core of the runtime behaves" and i was like.. what? how can you possibly test that? or how could you possebly run anything not written (and rememberd) by yourself if some peice of code somewhere can change ToString to return strings backwards (just an example)
i got the awnser that "ofcourse you whouldnt do anything like that!" well.. lets hope so.. perhaps nothing so extreme but.. still.. :P
i do think there is a place for dynamic languages in gp programming and im sure there are lessons to be learned there :) but as the sole language for large scale programs? i dont know..

perhaps in c#4.0 we'll have a "inpure" (or pure) keyword that marks the purity of a return value :) i really do feel that optimal is some kind of middle road between totaly pure and inpure..

sylvan wrote:

Exactly, the IO monad simply doesn't have a way to get out of it*. It's "sticky" and infects anything it touches.

cool :) thanks for clearing that up :) it seems more and more like the built in monads are things that make haskell program practical, just like the .net framework and the java framework makes c# and java practical :) i wonder if you could port those monads to c#.. they whould make a nice addition to the .net framework i think :) (perhaps they are already in there somewhere?)

Re: Erik Meijer: Functional Programming

sylvan — Thu, 24 Jan 2008 20:31:10 GMT

Erik_H wrote:

Say, for instance, that I have an IO layer over a file system or a database that returns the IO monad, and I want to combine that with the maybe monad. Do I create a new monad that combines them, or do I wrap the Maybe monad on top of the IO monad?

I'm not sure I can convert all of this into pseudo C# so I'll just use Haskell. Shouldn't be too hard to follow.

In Haskell you have something called "Monad transformers". It's basically a monad which takes an "inner monad", and let's you access that inner monad using the function "lift". The convention is that the monad transformer's types end with "T".
Sadly there is no MaybeT, but it can easily be defined ( http://www.haskell.org/haskellwiki/New_monads/MaybeT ).
I'll use the ErrorT transformer instead.

So a transformer for "errors" is called "ErrorT". It basically takes an error type, and an "inner monad", and allows you to call "throwError" to signal an error, and if anything signals an error the whole thing will signal an error.

Anyway, here's the Haskell type when the error type is a string "like an error message).

type ErrorIO a = ErrorT String IO a

This just declares a type synonym (for convenience) called ErrorIO with one type parameter, and says that it's equal to the error monad with an error of type String, and an IO as the inner monad. These transformers nest, so you can wrap another transformer around the ErrorIO monad to stack even more features on.

And an example usage:

test :: Bool -> ErrorIO Int
test fail = do {
    lift $ putStrLn "Hello!";
    when fail $ throwError "Error!!!";
    return 5;
}

Notice the "lift" in there which lets you get at the inner monad (IO in this case, which we use to print "Hello!" to he terminal).
Normally when you do this you'd define shorthands for all the methods you want to use from the various inner monads so you don't have to use "lift" everywhere (which can get messy when you want to access a monad that's several layers deep since you have to apply "lift" several times). Or if you want easy access to any monadic actions in the inner monads you would define shorthand "lift" functions for each of the inner monads so you at least only have to use a single lift function ("liftIO", "liftState", etc.).

And here's some exploring in GHCi (interactive GHC), which "runs" the monadic value returns by the function test. This simply "unwraps" the transformer and returns the inner monadic value (if there were no errors):

*Main> runErrorT ( test True )
Hello!
Left "Error!!!"
*Main> runErrorT ( test False )
Hello!
Right 5

This just tries the "test" function in the two cases, the first one returns "Left" which signals that the ErrorT monad failed, and the error message is "Error!!!". The second one returns "Right" (memory rule: "Right means Correct") and the value that came out of the inner monad.

*Main> :type runErrorT ( test False )
runErrorT ( test False ) :: IO (Either String Int)

This just shows the type inferred for the return value when running the outer error monad. As you can see it unwraps the outer monad, and returns an action of the type of the inner monad, that returns "Either" the error type (String) or the value type (Int).

*Main> runErrorT ( test True `catchError` (\err -> do {lift $ print "error!"; return 0; }))
Hello!
"error!"
Right 0

This uses the "catchError" function to catch an error, which just prints the message "error!" on to the screen, and then returns 0 (without errors), and as you can see we get "Right 0" at the end. The stuff to the right of catchError is a lambda expression which takes the error, and returns a monadic expression that handles it (which may throw a new error).

Re: Erik Meijer: Functional Programming

akopacsi — Thu, 24 Jan 2008 16:23:04 GMT

If you are new to functional programming you might be interested in this tutorial:
http://www.cs.utah.edu/~hal/docs/daume02yaht.pdf
I found it very useful and interesting.

Re: Erik Meijer: Functional Programming

Erik_H — Thu, 24 Jan 2008 16:07:11 GMT

Hi.

A question for the monad experts (I don't know alot about monads but I want to learn):

How are monads combined, and what would that look like in C#?

Say, for instance, that I have an IO layer over a file system or a database that returns the IO monad, and I want to combine that with the maybe monad. Do I create a new monad that combines them, or do I wrap the Maybe monad on top of the IO monad?

/Erik

Re: Erik Meijer: Functional Programming

sylvan — Tue, 22 Jan 2008 19:25:22 GMT

aL_ wrote:

but isnt it sort of the point of functional programing to prove the correctness of a program by using a static analysis? (im sure the awnser is "sort of" but i hope you get my point :)) doesnt use of dynamic typing sort of negate that?

My totally un-diplomatic answer is: Yes, it does, which is why dynamically typed languages will prove to be a dead end for anything but the simplest of shell scripting.
The benefits of dynamically typed languages usually have nothing to do with the lack of static type checking (easy access to data structures, high level expression-based syntax, etc.). And almost all of those benefits can be had in statically typed languages too.

Programs are getting more complex, not less, and anything that can go wrong, will eventually go wrong (Murphy's law). So the more potential crashes that the compiler can rule out entirely with 100% guarantees, the better.
We still need testing, but testing is a poor substitute for proof (especially when those proofs can be had for a price as cheap as just running the type checker).

Furthermore, types aren't a burden, they're a big help. Do people complain about the burden of drawing their OOP classes out in UML before starting to program? Types give an overal shape of a program (especially in FP - UML may be better when everything is based on state).

We need more static checking, not less.

</rant>

aL_ wrote:

oh and btw, is it really impossible to be dishonest in haskell (or f# for that matter)?
cant you do something like:

int DoSeeminglyPureStuff(int input){
//disregarding the input int and doing evil things instead
IO<int> myIoInt = sourceOfInpureInt();
return myIoInt.Value; // i.e. the "real/pure" int
}

(sorry i dont know haskell syntax)
but perhaps the IO monad doesnt have something like "Value" to get the value inside the monad? or is there something else stopping you from doing something like this?

Exactly, the IO monad simply doesn't have a way to get out of it*. It's "sticky" and infects anything it touches.
However there are other monads that do have functions that can "run" a monadic value. For example the ST monad can work with mutable variables (only, no networking, or disk writes etc.), and once you've written your algorithm that requires mutable state, you pass it to "runST" which will give you back a pure value.
The STM monad can deal with concurrent acccess to shared mutable state (only), and once you've written an STM action (a "transaction") you pass it to "atomically" which will run it atomically, and return... an IO action! So you can get from ST to pure, and from STM to IO, and you can get from pure to any monad via the "return" function.

This gives you a nicely "layered" program, where you have this thin layer of IO at the bottom that does your IO, and then some STM on top of that which handles your concurrency synchronisations, then the bulk of your program is pure, but some of those pure calls may use the ST monad for local encapsulated mutable state.

* actually there's the unsafePerformIO which let's you escape when you really need it, and when you really know what you're doing. If you do use this, just must absolutely guarantee that the thing you're wrapping actually does have pure semantics (and even then things can go wrong - so you really need to know what you're doing!).

Re: Erik Meijer: Functional Programming

aL_ — Tue, 22 Jan 2008 13:36:23 GMT

brianbec wrote:

I think there is a lot of misunderstanding "in the air" about "dynamic typing." I think it's often confused with "weak typing."

true, true. i do know the diffrence between static/dynamic typing and strong/weak typing (belive it or not :P) even though i slipped up and use the wrong trem in my post. my bad :)

what i meant was that for a haskell programmer, c# seems to have weak typing because its not visible in the types if there are any side effects.. but in like (as you mention)javascript, vb(not vb.net) and possebly c/c++, the types are even weaker, there you dont even know what you get back. true? (this is meant as an observation)

after some consideration it seems to me that FP and dynamic typing dont really conflict with one and other. i whould simply get "cant implicitly convert IO<int> to int" errors at runtime and not at comiple time. right?

but isnt it sort of the point of functional programing to prove the correctness of a program by using a static analysis? (im sure the awnser is "sort of" but i hope you get my point :)) doesnt use of dynamic typing sort of negate that?

that whould be make very interesting interview :)

oh and btw, is it really impossible to be dishonest in haskell (or f# for that matter)?
cant you do something like:

int DoSeeminglyPureStuff(int input){
//disregarding the input int and doing evil things instead
IO<int> myIoInt = sourceOfInpureInt();
return myIoInt.Value; // i.e. the "real/pure" int
}

(sorry i dont know haskell syntax)
but perhaps the IO monad doesnt have something like "Value" to get the value inside the monad? or is there something else stopping you from doing something like this?

Re: Erik Meijer: Functional Programming

aL_ — Tue, 22 Jan 2008 12:24:31 GMT

brianbec wrote:

Here's the doctor's prescription for you:
In your daily work, use C#, VB, and F#.
Get, read, and work EVERY problem in Structure and Interpretation of Computer Programs, by Abelson and Sussman. (Use PLT Scheme to do the problems).
When done with SICP, get, read, and work EVERY problem in Expert F# by Don Syme, et al. Use F#, obviously
When done with that, come back for a Haskell prescription. The stuff above should take you three years.

so no python, ruby, smalltalk or indeed c then? :)

Re: Erik Meijer: Functional Programming

aL_ — Tue, 22 Jan 2008 12:22:35 GMT

evildictaitor wrote:

If you have 100 errors in your program, wouldn't you prefer to see them before you ship your application, rather than only catching 99 of them in test?

I whould prefer to find errors at complie time. but im a static typing kind of guy :) i totaly agree that its better to find errors at compile time and not run time. but alot of people prefer languages without and static checks at all. are they "wrong"? or are we (the static guys) "wrong"? perhaps there is something inbetween? i just think thats an interesting discussion.. (and one that can lead to infinite flame wars im sure :P)

evildictaitor wrote:

True, although you have to be careful with Ruby. It's actually strongly typed behind-the-scenes, which helps catch a number of errors, even if you don't force the types at compile time - it can usually infer them from context.

alright :) i dont know very much about the internals of ruby. but meant general dynamicly(i.e not staticaly) typed languages.

evildictaitor wrote:

One could argue that these uses are sufficiently small that the benefits of FP and static typing don't come through, (although I would disagree).

i do too. i vastly prefer static typing to dynamic.

but my point was that a lot of people feel that dynamic typing is the way to go and looking at the jaoo vids for example one get the feeling that more dynamically typed languages are coming back(as well functional languages).
the DLR, iron python and iron ruby are hot stuff right now too :) for general computing too it seems if one listens to some of the guys at jaoo:)

im not dissing FP or static typing at all, i'd pick static typing over dynamic any day of the week. i just think its interesting that both types of programing "are the future" at the same time :) it'd be interesting to have an interview with the masters (brian erik and anders among others) to talk about that.. or perhaps to hear some dynamic typing buffs view on say haskell and f# :)

but yeah, i share your feeling that dynamicly typed languages are best suited for small programs/scripts and staticly typed languages are better for larger ones

Re: Erik Meijer: Functional Programming

staceyw — Tue, 22 Jan 2008 02:30:11 GMT

Thanks Erik. Helped me understand more about FP and what you and BrianB have been talking about in last few videos. I think this was the first time I heard clearly that "state" is needed and not bad. We "state" folks are not all in the weeds rubbing our gold rings. At the same time I am more confused (which is good):

1) If we had "public void IO GetSum(1,2,3) {...}", does this really help? In a typical windows app, most functions will now have IO tacked on. But does that make my app better/easier to understand? Moreover, I can still lie. I can say func Throws Exception1, but still throw Exception2. Or would compiler prevent such madness from me? I am a baby on FP, but I can find precious little functions that would not need IO in my current WinForms app (btw, using Linq and local DB for Disconnected operation - Thanks much!).

2) If I declare all possible exceptions that a function "may" throw; a moderately complex function may have reams of ThrowsException attributes. By calling .Net libs which may call other libs, which may call Win32Apis, you could end up with all Exceptions in the world under that call tree. Not to mention some Exceptions we can't know (i.e. OutOfMemory, ThreadInterupt, ThreadAbort) in advance. So we are kinda forced to lie with the unperfect information we have and external forces. How would this be handled, or did I miss the idea (which is probable).

3) I heard state was good and FP was good, and started to see some light on "IO". But I did not "gleen" the solution path from the video. Do you see a clear path opening here?

4) It seems like Windows message pumb was ahead of its' time! Single threaded with a Message Queue (rock on Erlang). Even with that "good" design, we still have challenges in that area (i.e. invokes, dead locking ourselfs, live locks, etc) As you say, given just a sliver of daylight, we can/will hang proverbial self.

William

Re: Erik Meijer: Functional Programming

staceyw — Tue, 22 Jan 2008 01:35:58 GMT

brianbec wrote:

aL_ wrote:

dynamic languages are, according to to those who know, great because one is not "restricted" by the type system (like the one in java/c#) and can do anything.
but say haskell, (as i understand it) has a whole lot stronger type system, so for a dynamic guy, shouldnt that be even worse than say c#?

I think there is a lot of misunderstanding "in the air" about "dynamic typing." I think it's often confused with "weak typing." Scheme is a great example of a "dynamically typed" language that is also (mostly) "strongly typed."

"Dynamically typed" just means that types are carried around with data and are checked at run time, not at compile time.

"Strongly typed" just means that there are not a lot of implicit conversions going on. If you call a function that expects a double and you pass it a string, you will get an error. In a statically typed, strongly typed language, you will get the error at compile time. In a dynamically typed, strongly typed language, you will get the error at run time.

Math.Sin("32.6") --> compile-time error if statically typed, strongly typed.

Math.Sin("32.6") --> run-time error if dynamically typed, strongly typed.

"Weakly typed" just means the compiler and run time will do lots of implicit conversions for you, so, it will convert your string to a double or your double to a string or what not. You may still get an error at run time, but the conversion routine will throw it rather than the ultimate function you're trying to call:

Math.Sin("32.6") --> Math.Sin(StringToDouble("32.6")), rewritten by compiler if weakly typed, either static or dynamic.

Math.Sin("ABC") --> Math.Sin(StringToDouble("ABC")), run-time error if weakly typed, static or dynamic (though some super dynamic languages might do the following (sketching):

Math.Sin("ABC") -->
Math.Sin (
try { StringToDouble("ABC"); }
except { try { AnyToDouble(LookupVariable("ABC")) } } )

I think Javascript will do that.

It would be nice if we could:

DateTime dt = "1/1/08";
int i = textbox1.Text

Naturally, we are saving the manual Convert which will throw anyway if the parsing fails so don't think this change would hurt.

At a minimum, having Operator Extention methods would allow our programs to opt-in to this.

Re: Erik Meijer: Functional Programming

RichardRudek — Mon, 21 Jan 2008 22:42:05 GMT

stevo_ wrote:

So ok, great, we have a system where everything is 'honest' about it's workings, why is that useful?

It's useful because it not only allow more robust systems, but also allows various other "optimisations".

This idea of (bad) side-effect free permeates most of modern day computing. For example, at the macro-level, we have Operating Systems with protected memory systems, privilege levels, etc, which then allows robust multi-tasking, etc.

Moving to the micro-level, we have instruction-level parallelism, which CPU designers (at the chip, transistors level) needed in order to improve throughput [1]. Things like super-scalar, pipelining, out-of-order execution, etc, I believe, can all trace their roots back to this idea of (bad) side-effect free operations. Sure, they had to introduce a slew peripheral hardware to cache or hide the various (good and bad) side-effects, but they did it.

Now were moving into the age where they are trying (again) to do it at the programmer level. At least, that's my take on it... ;)

[1] The root causes for this are many. But from my perspective, the primary cause is the unwillingness of the 'industry' to move to vastly faster memory sub-systems - orders of magnitude, in some cases. (And yes, it would be extremely expensive, which is why it's not being done, considering ->). So far, they've been able to hide the huge differences between the the throughput achieveable from the various 'levels' in the memory heirachy: register to register, register to L1 cache, register to L2 cache, etc.

Re: Erik Meijer: Functional Programming

brianbec — Mon, 21 Jan 2008 18:00:15 GMT

aL_ wrote:

dynamic languages are, according to to those who know, great because one is not "restricted" by the type system (like the one in java/c#) and can do anything.
but say haskell, (as i understand it) has a whole lot stronger type system, so for a dynamic guy, shouldnt that be even worse than say c#?

I think there is a lot of misunderstanding "in the air" about "dynamic typing." I think it's often confused with "weak typing." Scheme is a great example of a "dynamically typed" language that is also (mostly) "strongly typed."

"Dynamically typed" just means that types are carried around with data and are checked at run time, not at compile time.

"Strongly typed" just means that there are not a lot of implicit conversions going on. If you call a function that expects a double and you pass it a string, you will get an error. In a statically typed, strongly typed language, you will get the error at compile time. In a dynamically typed, strongly typed language, you will get the error at run time.

Math.Sin("32.6") --> compile-time error if statically typed, strongly typed.

Math.Sin("32.6") --> run-time error if dynamically typed, strongly typed.

"Weakly typed" just means the compiler and run time will do lots of implicit conversions for you, so, it will convert your string to a double or your double to a string or what not. You may still get an error at run time, but the conversion routine will throw it rather than the ultimate function you're trying to call:

Math.Sin("32.6") --> Math.Sin(StringToDouble("32.6")), rewritten by compiler if weakly typed, either static or dynamic.

Math.Sin("ABC") --> Math.Sin(StringToDouble("ABC")), run-time error if weakly typed, static or dynamic (though some super dynamic languages might do the following (sketching):

Math.Sin("ABC") -->
Math.Sin (
try { StringToDouble("ABC"); }
except { try { AnyToDouble(LookupVariable("ABC")) } } )

I think Javascript will do that.

Re: Erik Meijer: Functional Programming

brianbec — Mon, 21 Jan 2008 17:42:55 GMT

Charles wrote:

I'm glad you put the term honest in quotes. I don't think it's the precise way to express what Erik is talking about (then again, I'm not precisely qualified to debate Erik - he's a programming language expert. I'm not.). Perhaps a clearer (and less contentious) way to think about the this is in terms of surpise-capable(unexpected side effectual) versus surprise-free (a priori side-effectual or side effect free (also known as 'useless')) functions. So, if you call a 'pure' function then you can expect, and rely upon up front(prior to execution of said function - a priori...), no invokations of Surprise that could end up breaking your algorithm or befuddling your critical operation because, well, that what Surprises are - you are not expecting them and therefore you have no way to handle them since you didn't write code that expects them (and code that calls your code is in the same boat so the Surprise bubbles up through the system surprising callers, which is not very composable, right?

Does this make sense?

C

Charles speaks the truth :)

I like to focus on the type system: if the type system cannot tell you the difference between a side-effecting function and a non-side-effecting function, then the type system isn't telling you "the whole truth." That is, it's not telling you everything about your program that it is possible, mathematically, to say.

How about this:

side-effecting function = useful function
non-side-effecting function = useless function

type system that can always tell the difference = wholly truthful
type system that can't always tell the difference = partially truthful

monadic function = useful function, helps a partially truthful type system to tell the whole truth.

Re: Erik Meijer: Functional Programming

Charles — Mon, 21 Jan 2008 17:33:43 GMT

stevo_ wrote:

It took me a while to understand what was being expressed in the video.. but still I think I managed to miss the usage concepts..

Ok, so we have functions (methods?) that are more transparent about how they work, they provide an overview how the return data is aquired, I don't think you said anything about if exceptions are noted here (like with; as was noted, java)..

So ok, great, we have a system where everything is 'honest' about it's workings, why is that useful?

I'm glad you put the term honest in quotes. I don't think it's the precise way to express what Erik is talking about (then again, I'm not precisely qualified to debate Erik - he's a programming language expert. I'm not.). Perhaps a clearer (and less contentious) way to think about this is in terms of surpise-capable(unexpected side effectual) versus surprise-free (a priori side-effectual or side effect free (also known as 'useless')) functions. So, if you call a 'pure' function then you can expect, and rely upon up front(prior to execution of said function - a priori...), no invokations of Surprise that could end up breaking your algorithm or befuddling your critical operation because, well, that's what Surprises are all about - you are not expecting them and therefore you have no way to handle them since you didn't write code that expects them (and code that calls your code is in the same boat so the Surprise bubbles up through the system surprising callers, which is not very composable, right?)

Does this make sense?

C

Re: Erik Meijer: Functional Programming

stevo_ — Mon, 21 Jan 2008 17:19:01 GMT

It took me a while to understand what was being expressed in the video.. but still I think I managed to miss the usage concepts..

Ok, so we have functions (methods?) that are more transparent about how they work, they provide an overview how the return data is aquired, I don't think you said anything about if exceptions are noted here (like with; as was noted, java)..

So ok, great, we have a system where everything is 'honest' about it's workings, why is that useful?

Re: Erik Meijer: Functional Programming

brianbec — Mon, 21 Jan 2008 16:08:41 GMT

aL_ wrote:

and yet, both these paradigms are on the rise.. am i missing something? whats a simple programmer to do

Here's the doctor's prescription for you:

In your daily work, use C#, VB, and F#.

Get, read, and work EVERY problem in Structure and Interpretation of Computer Programs, by Abelson and Sussman. (Use PLT Scheme to do the problems).

When done with SICP, get, read, and work EVERY problem in Expert F# by Don Syme, et al. Use F#, obviously

When done with that, come back for a Haskell prescription. The stuff above should take you three years.

Re: Erik Meijer: Functional Programming

evildictaitor — Mon, 21 Jan 2008 12:48:06 GMT

aL_ wrote:

again, im not trying to imply that FP is bad or something but surely there must be areas where its less useful than say imperative techniques? i think those areas are as important to highlight as the ones where FP is very useful such as concurrency. knowing the pros and the cons will make it easier for noobs such as me to understand fp, because we wont try and apply it in unneccesarily difficult situations.

Yes. It's worth pointing out that there are a number of areas that for the foreseeable future functional programming techniques won't be playing a part.

Basically as Brian said, languages like C and Fortran start with the machine and add from there, whereas languages like Lisp and Haskell start with the math and subtract from there, so in applications that are very close to the machine your languages like C and C++ are going to remain more popular for a reasonably long time. Examples include the low level operating system, device drivers and the 3D rendering agent inside 3D programs (e.g. games).

This being said, most tasks are problem-orientated, rather than machine-orientated, and it is these types of problems that are often best solved in languages like Haskell and Lisp. Where problem-oreientated programs turn into rich client applications, languages like F# bridge the final gap between solving the problem and allowing the user to use it.

aL_ wrote:

as a side note, again from a semi noob in both areas, i find it sligtly odd that both dynamic languages and FP languages are haveing a second coming at the same time. they seem to be at opposing ends of the spectrum somehow.

dynamic languages are, according to to those who know, great because one is not "restricted" by the type system (like the one in java/c#) and can do anything.
but say haskell, (as i understand it) has a whole lot stronger type system, so for a dynamic guy, shouldnt that be even worse than say c#?

For someone like me who's worked quite a lot with C and C++, I know first hand the problems that can happen when you pass something around which isn't what you thought it was, usually crashing the application at point-of-use. The type system in C#, Haskell etc counteracts this to a large extent - instead of crashing the application at point of use, it stops the compiler at compile-time, which is nearly always a better idea. If you have 100 errors in your program, wouldn't you prefer to see them before you ship your application, rather than only catching 99 of them in test?

Languages such as PHP and other essentially type-less languages help you to make errors by their lack of type checking. Consider the code:

echo "Twelve is " + ("1" + "2");
echo "Twelve is ". ("1" . "2" );

Note that in PHP the dot '.' is the string-concatenator, and + is a mathematical operator. In the first example (which happens remarkably often), I've accidentally used plus instead of dot. PHP doesn't mind however, since it can convert a string to an integer silently. "Twelve is" doesn't look like an integer, so becomes the value 0, "1" and "2" become 1 and 2 respectively and although echo expects a string, and (0 + 1 + 2) is an integer, it doesn't matter because PHP can convert it straight back into the string "3"!.

If this little code snippet occurred hidden away somewhere, and I didn't test for it, I might never notice that I've used this incorrectly. Haskell would object to my using + with strings and echo with ints respectively, and would never have run the first time.

Ultimately this means that type-less or mostly type-less languages are great for scripting small programs, but when it comes to proper applications of more than a couple of hundred lines, it becomes incredibly important to have strong type checking, to reduce the strain of testing, and to catch as many of the obvious little errors before you ship your application to users.

aL_ wrote:

and it goes both ways, if youre a haskell guy and you think c#/java is bad because of all the potential side effects, whouldnt say, ruby be even worse? in ruby one dont even know what type you get back from a function, much less if it has a side effect.

and yet, both these paradigms are on the rise.. am i missing something? whats a simple programmer to do

True, although you have to be careful with Ruby. It's actually strongly typed behind-the-scenes, which helps catch a number of errors, even if you don't force the types at compile time - it can usually infer them from context.

Basically, the benefits in FP and strong static typing come through most promintently in large, real world apps. They catch silly mistakes and abstract things like concurrency so the programmer doesn't have to think about it.

The languages where strong static typing are not commonly used are nearly invariably designed to be used as small, quick scripts, such as Bash, or on webpages such as PHP and Javascript. One could argue that these uses are sufficiently small that the benefits of FP and static typing don't come through, (although I would disagree).

In all real world applications there are errors (yes, even in Microsoft programs), however the number of these can be reduced by extensive testing (expensive) or by automatic detection, which is what static typing is designed to do. By enfocing this by using strong static typing, you guarrantee that errors are errors of logic or input, rather than silly errors such as forgetting what parameters a function takes, using the wrong operator etc.