Die Kraft der Faulheit in der Programmierung

Thanks for coming here. Let's talk about, let's get lazy, exploring the real power of screams.

My name is Ben Katsubramanyam. I'm going to talk about what is lazy valuation, what are some of the reasons why we are really interested in it.

And we'll talk about how laziness can be implemented in a number of different ways.

But before we get started, just a quick show of hands. How many of you are lazy?

That's great. I just want to make sure I'm in the right place. Fantastic.

So let's talk about, you know, lazy valuation. What does it really mean to be lazy?

Well, when it comes to functional programming, we often hear people talk about how immutability is so important.

We talk about higher order functions. And in my opinion, the problem with such discussions, and I've done this also myself,

is telling programmers that they should program immutability is like telling children they have to eat vegetables.

And nobody likes it. So why do we really care about immutability, water some of the reasons?

And I want to really talk about why that is so critical to do.

As you're listening along, if you have questions, I do request you to raise the questions through the app,

and we will have the questions at the end of the session, and also take your time to rate the app talk as well towards the end.

So let's talk a little bit about what is the reason for such importance to immutability and such.

Well, I'm going to actually ask the question, what is really functional programming?

And I'm going to argue that functional programming really is little to do with immutability.

Functional programming really is little to do with higher order functions.

To me, the really core features of functional programming is two things.

One is that we are really interested in functional composition.

And functional composition gives us the ability to express our code really well in terms of flow of the data through processing that we do.

And I'm going to say one of the most critical aspects of this is,

functional composition plus lazy evaluation.

And I remove laziness from this equation.

I think it's pretty pointless to talk about functional programming.

So lazy evaluation is probably one of the most critical aspects of programming functionally in a sense.

And so laziness is very absolutely critical.

Look at any sensible functional programming language you will see lazy evaluation in it.

So this is one of the most critical things to do consider.

But when it comes to programming, there are different programming languages out there.

And unfortunately the world has really settled upon a few mainstream languages.

There are literally so many languages, which is thousands of languages out there.

But yet we are focusing on a handful of them.

But it does have most of the mainstream languages we program in.

Are tilted towards one way or one style of programming.

Which is nerve wrecking because we could go through an entire career in programming.

These mainstream languages are not even get an opportunity to realize a whole new different world that's out there.

What one such thing is what's called applicative order versus normal order.

It's really funny in our field how we name things.

It turns out normal order is actually quite abnormal.

We don't use it as too often.

But what does it really mean?

Let's take a look at one example here for a minute.

Here is a little Java code.

And in the Java code I'm going to go ahead and call a function flu.

And I'm going to call another function let's say add over here.

Now I'm going to pass one and two.

We clearly know how Java works in this case.

It's going to call add and then it's going to call the function flu.

But it doesn't have to be that way.

And that order of execution is called the applicative order.

The word applicative really means in the order in which we apply it.

But the normal order actually does things pretty different.

Let's take a look at what that really means with a little example.

I'm going to write a very small example here in Haskell.

I'm going to say add a b equal to a plus b.

So it's a fairly simple function.

It's pretty self explanatory what this function is doing.

I'm just adding two values right here.

Then I'm going to call evaluate and pass a value to it as a parameter.

And all that the evaluate function is returning is the value back to us.

Now I'm going to call a print function.

I'm going to call the print function.

I'm going to call print right here.

I'm going to call evaluate and call add one and three.

One and two here.

I'm going to execute this little code.

And it produces a value of three.

However, how does Haskell really work?

In the case of Haskell, Haskell you go to Haskell and say Haskell call add.

And Haskell would say, but why?

Well, because I want to pass the result of that to evaluate,

then Haskell says, then go call evaluate.

Why do you bother me?

Well, OK Haskell call evaluate.

Like why?

Because I want to call print.

Well, then go call print.

Why are you bothering with the evaluate?

Well, I'm going to prove this.

But how do we prove it?

And unfortunately, in Haskell haskell being a functional programming language,

you cannot just drop impurity anywhere you want to.

So if I were to go here and put a print statement,

Haskell will yell at me and say, what are you trying to do in a pure function?

So I was kind of sitting and scratching my head.

How do I prove the obvious here?

And I never thought I would use a debugger to prove anything in my life like that.

So I'm going to just do exactly that right here.

So I'm going to bring up GSEI, which is the Haskell Ripple.

I'm going to load up right here.

The sample dot h is the file I just wrote right now.

I'm going to put a break point on line number one, character number 16.

And the break point is right there.

I'm going to call the main function.

And I'm showing you the obvious right here.

It is waiting as you can see on line number one.

And it is waiting at the break point.

Now, of course, I'm going to say continue if you will.

So I'm going to go ahead and type continue.

And as I type continue, you can see that it is actually displaying the result of three.

Approved that it actually called the add function because it was stopping on line number one.

Well, of course, I took all this effort to show you the obvious, which is kind of pointless, isn't it?

But let's get back to this code for a minute.

I'm going to go back to the evaluate function.

And I'm going to return the value of 42 right here.

What I run the coded printed 42.

But this time, I'm going to go back to Haskell and say call add and it says why.

Well, I want to call evaluate.

Then call call evaluate.

When it turns out Haskell never actually calls the add function in this case.

How do I know? Let's prove this again.

Let's go back to the command prompt.

Let's open up the Rappel one more time.

Let's load up the program again.

Let's set the break point one more time.

Now that the break point is set, I call the main function.

And notice it never bothered to break on line number one.

That's approved that it never actually bothered to stop on the add function.

So what are we really proving with this little example?

Well, that is a normal order of execution that you're seeing right there.

And it turns out that most languages we use in the main stream use applicative order.

But normal order is rather uncommon and abnormal in a way.

And a lot of languages don't use it.

But one language that does that is, of course, Haskell.

You saw that really doing it.

Well, it turns out that some languages are born lazy.

They are born by the beach and they just sit there and have a good time.

But some languages have to work really hard to be lazy.

They're kind of like me.

I'm always agitated.

I'm always up to something.

And my wife says, why do you relax?

I'm like, how do you do that?

And that's the way we are like, you know, some languages are absolutely eager.

They're not really lazy.

But it turns out that lazy evaluation is absolutely critical.

So what is the benefit of laziness?

The benefit of laziness is really efficiency.

So if you want to really make your program efficient,

efficiency is not running things faster,

but by avoiding things that shouldn't be done in the first place.

So imagine taking the chunk of computation and not running them

because you don't really need the results of it,

this can become really powerful.

Like what?

Imagine this for a minute about postponing evaluation.

On January the second, the boss calls you into the office.

And the boss tells you, one January the second,

that you're going to work on an important project,

and the result, the report of it is due on April the 15.

What do you do?

You come out of the boss's office on January the second,

go to your desk and start on this right away, correct?

Of course not.

You will start on it promptly on April the 14,

because it's you on the 15th, isn't it?

What is that call being smart?

And that's what you would do.

I remember the time when I was in school.

I was really a terrible student.

And I would see all these students working really hard for the exam

for months away.

And I would always look at them and say,

what are you doing, preparing so hard for the exam?

Because you see there's a lot of things can happen

between now and the exam.

On the exam day, potentially there could be a really heavy snowstorm

or a thunderstorm and the whole school could be cancelled.

The professor may die before the exam.

There's a lot of things that can happen, isn't it?

So what do you do as a very efficient student?

You wait until the night before the study.

Well, that's kind of like what I really like.

It's laziness leads to efficiency.

And just in time, we call it,

or we call it the last responsible moment

while all these things are really good things.

So how do we really achieve this?

Let's take a look at one example of this.

How to really be able to achieve something like this.

So in order to understand this,

let's take an example here in two different languages,

if you will.

I'm going to write a little example here in school.

I just do entering the thought.

Other languages do this as well.

Like, for example, grew, we cartlin.

You can do these things in multiple different languages.

Let's take a look at an example of this right here.

I'm going to define a function.

And the function I'm going to define here is called Compute.

And this takes a value integer.

And all I'm going to do within this particular function

is return n times to just, you know,

very trivial function.

But good enough for us to start with.

So that is my compute function ever

here in in a column.

But here on the Java side,

let me go ahead and write the same function here.

I'm going to say Compute where I'm going to take a number.

And all I'm going to do is simply return number times 2.

So pretty much about the same code in both languages.

But on the scale side, what I'm going to do is say x is equal to,

let's say 4.

And I'm going to say, in this case,

similarly on the Java side, I'll say,

a final x is equal to 4.

But I'm going to simply say, if on the other hand on the other side,

I'm going to say, if x is greater than 5,

and the compute, let's call the compute function.

And I'm going to say compute of,

let's say, about x is greater than 7,

then I want to print out,

let's go ahead and say result 1.

Otherwise, I'm going to say result,

and I'm going to print out, let's say result 2.

I want to do something very similar to this on the side of Java as well.

So let's go ahead and write the before we try to execute this.

So I'm going to say, if x is greater than 5,

and compute of, let's say x is greater than 7,

I want to simply output result 1.

Otherwise, I'll simply output over here.

Let's go ahead and say result 2.

So these two are pretty much similar functions between Scala and Java here,

as you can see.

But I'm going to execute this little code.

And my question really at this point is,

will the compute function be called?

What do you think?

No, I see people saying no over there.

Well, it will not be called,

and let's verify that it's actually not being called.

So when I go back and run this code,

what does the output say?

It says result 2, and clearly compute was not called.

But I'm going to ask the question,

why was compute not called?

Anyone recognizes the reason for it?

Come on, don't be shy.

Yeah, that's why charts are queuding, isn't it?

So we know this is a charts are queued feature,

and guess who, let's go ahead and say called over here,

guess who introduced that feature?

Well, it turns out charts are queuding,

has been in languages for a very long time.

John McCarthy introduced charts are queuding,

as part of list programming,

and languages have ever since used this.

It's a folklore, isn't it?

Everybody knows about charts are queuding.

We all come to expect it.

On the other hand, I'm going to go back to this code

and say a temp over here,

and I'm going to then say,

valve temp is equal to compute of x.

Now I save the variable into a temporary variable,

and then I'm going to pass and use that variable.

Similarly, I'm going to say over here,

a temp is equal to,

let's say, compute of x,

and I'm going to change this to a temp over here.

And back to the scholar code,

my question is, will compute be called now?

What do you think?

A little question mark on people's face,

not sure.

Let me change the question.

Should compute be called now?

Yeah, that's a no, right?

We shouldn't call compute,

and yet when you run the code,

compute is actually called.

How sad that is, isn't it?

Now, why is compute really called?

Well, the reason compute is called,

is, hey, what if there is a side effect?

You say, wait a second,

you're talking about side effects suddenly,

but a minute ago,

you were having exactly the same compute method,

you had it in the short circuit situation,

and even if there was a side effect,

why in the world did you not call it?

Well, the short answer to that question

is language specification.

You can never argue with language specifications.

The language specification says,

even in the event of a side effect,

if you're in a short circuit situation,

we have the right not to call the function.

On the other hand, in a regular conditional statement,

the language says, oh, my gosh,

what if really we are going to have a side effect,

I better call it,

so as a result,

as you can see in the case of scholar,

and in the case of Java,

it ended up calling the function.

But I know you all said,

it shouldn't be called,

I totally agree with it,

so what you can do is you can say lazy right there,

and by saying lazy,

you can see that scholar is no longer calling the function,

because it determines that it is not really needed.

Without the word lazy,

you can see that it's actually calling the function,

but when I drop the word lazy in there,

you can see it's no longer calling it.

But just to illustrate this,

if the value of x was 14,

you can see that it is calling the function,

but if the value of x is 4,

it is no longer calling the function.

So by marking it lazy,

you're able to achieve that in the case of scholar.

Likewise in the case of Java,

I'm going to go ahead and say lazy right there,

and when I run the code,

it doesn't work.

I know for a minute you were like,

gosh, this is awesome, isn't it?

Sorry I disappointed you,

so no it doesn't work.

Well, but you know,

you say like, but I want it,

I why can't I have this particular feature?

And so the answer to that question is,

yes, you can have it,

but how can you introduce laziness on your own?

And that is one of the questions to really think about.

And for this, I want to step back a minute

and talk about one statement,

and I would argue,

this is probably the most profound statement ever in our field.

There's not a single day that I sit and programming

when I don't pause and appreciate this particular statement.

I don't think there's anything more profound in our field,

and this was said by a gentleman named David Wheeler,

and David Wheeler probably said,

the most wisest thing ever.

And he said, all problems in computer science

can be solved using one more level of interaction.

And this to me is the most phenomenal statement ever.

Now if you really think about it,

level of interaction is the master design

of all designs in my opinion.

Because this is the master as and fundamentally

skillful way of doing things,

and this is the most phenomenal mastery of design

if you think about it.

Because a level of interaction simply says,

rather than solving this here,

solve a problem that in turn will solve the problem.

We use this a lot in computer programming.

In C programming languages,

we use pointers as level of interaction, for example.

Well, it turns out in functional programming,

the level of interaction is there too.

The level of interaction in functional programming

functional programming comes from,

well, where does it actually come from?

Well, if this is one of my realization call me silly,

but I get excited about these things when I program

is when you could be programming for several years,

and one day suddenly something really dawns on you

that maybe it's obvious to everybody around you,

but you realize like, whoa, this is really awesome.

And to me, that is in level of interaction

functional programming comes from a lambda expressions.

So this to me is a,

a moment because lambda's give you that level of interaction.

So what does a lambda say?

A lambda says, rather than calling this function now,

call this anonymous function,

which is a lambda expression,

which in turn can call this function at a later time.

So to me, this is one of the really critical aspects of

lambda's is that they give you the level of

interaction in functional programming.

And then once we look at it this way,

it changes the whole world for me because it's a design tool

that I can look at and appreciate now

when I program in functional style,

because it's something that changes the way that I perceive

and use the solution at this point.

So what I can do here in the code is,

I can now say here a lazy,

if you will, of integer,

and I'm going to then say 10,

and then I will say,

notice over here,

I'm going to say new lazy,

and look at this very carefully.

If I call the compute method right here,

this is a applicative order.

Java will immediately call this function

because that's what Java does.

It's an applicative order language.

But what I can tell Java is,

do me a favor,

don't call the compute now,

instead call it later.

This error is almost like a level of

interaction isn't it?

So it is saying,

don't execute compute now,

execute it a little later.

So this is the degree of postponing

the evaluation,

and you're saying,

not now a little later,

please,

and that little parenthesis

is an indication of a lambda postponing

evaluation of the compute method.

So what we could potentially do here

is we could create a class called lazy,

where the class lazy could hold onto

an instance,

if you will,

and it could also hold onto

a little supplier of P,

where the supplier comes from

the functional interface

in the case of Java,

and then I can,

of course,

the supplier will call it the supplier,

and then of course,

what I can do is create the lazy constructor,

which is taking the supplier,

and what I can do is simply take the supplier,

store it away a supplier equal to the supplier,

but then I can write a method called get,

where the method get can say,

if the instance is equal to now,

then of course,

I could say,

this is equal to the supplier.

Get the value,

get rid of the supplier at that point,

we don't really care about it anymore,

and then return the object

that is held within the object.

So you could start writing things,

of course,

I'm writing this code here,

but you could use it from third-party libraries,

if you want to,

or you can put it in a separate utility,

and reuse it in your own applications.

But writing this lazy evaluation,

I'm saying,

postponing this to a later time.

As a result,

I can come in here,

and get the value of them

when I really made it,

and ignore the warning just for a minute,

and you can see at the very bottom,

the result too,

is being displayed right in there.

On the other hand,

if I were to modify this to a 4p in,

you will notice at the very bottom,

it is called and result 1.

So the calling of that is postponed,

until you no longer can postpone it,

so you can have laziness built in

to your applications that way,

and that comes from the level of

indirection that I was talking about a minute ago.

So laziness comes with a lambdas in most of these languages,

and that gives us a level of indirection,

we can benefit from really nicely.

Well, this leads us to how we can actually benefit

from this kind of laziness in programming.

So to understand this,

let's talk about laziness in collections of objects.

This is a very critical aspect to think about,

because functional programming gives us elegance in code.

It gives us beautyiness in code,

but at the same time though,

we have to be very careful because we cannot really be happy

with elegance and beauty,

we really attended the day,

have to really look for performance as well.

So to understand this,

let's take a little example and play with it.

Let's say for a minute,

given a collection, let's say collection of numbers,

well, of some ordered collection of numbers,

we'll say given a ordered collection of numbers,

I'm going to say find the double of the first number,

greater than three, and this even.

So I want to find the first number that's greater than three,

and that is even.

How do I do this in the imperative style of programming?

Well, in the imperative style of programming,

we're all used to doing this a lot in our experience.

So I'm going to start with a list of integer,

we'll call it as numbers equal to,

and let's say list off,

and what am I going to provide for this particular list?

I'm going to say this is going to be my list of numbers,

let's say 1 to 10, but with a small difference.

I'm going to say 5 and 4 as a sequence of numbers.

So notice I have 1, 2, 3, 5, 4, 6, 7, 8, 9, and 10.

But how do I do this in the imperative style?

Well, in the imperative style of programming,

what we're going to do is to first of all say,

end to result is equal to 0.

And of course, at the very end, I want to output the result,

but what do I do here?

For end, I equal to 0, I less than number start,

and I'm going to think about what to call here.

Is it length, is it size, is it count?

We cannot have a standard in our industry,

because that would make life easy.

So in this case, of course, it's a size of its list.

It's a length of its an array.

It's a count of its a different language.

And then, of course, you have to make another choice.

Is it plus or I plus plus or plus plus I?

And then you pause for a second as the question,

is that less than or less than or equal to every single time you write it?

Somebody asked the other day, what is the symbol stand for?

I said, that's the international symbol for, I'm confused.

Because every time we have to pause and ask the question,

now, to be fair, of course, you don't have to struggle that hard anymore,

you could have said, given an element that comes from numbers,

and what am I going to do now?

I can simply say over here, if element is greater than 3,

and if element, more 2 is equal to 0, then, of course,

result plus equal to element time 2.

Now, as an observant reader, you probably look at this code and say,

you're wrong, you are forgetting to put a break right here.

Now, if you don't put a break in the best case,

you will get a poor performance in the worst case,

you will get a wrong result.

But it's your responsibility to do all of this in your code.

And notice when I run this code, it produces the result of 8.

But the problem with imperative style code as imperative style code

is very misleading.

In imperative style code, I'm going to say,

has a built-in accidental complexity.

So, what is complexity?

Accidental complexity comes from solution space.

Now, the solution is complex because you're reading this code

and trying to figure out if it's right,

and typically what happens in my case is,

I put this code out in a few days later,

you know who walks in my tester,

and my tester says, your code sucks.

And I always tell my tester, don't tell me my code sucks,

tell me how it sucks today,

because every day it seems to suck differently.

But the point really in this case is,

the tester says, well, I tried your code

with an empty collection of data,

and your result was zero when the results would be non-existent.

I tried your code with a collection of only numbers

that are odd numbers you gave a wrong result.

I tried with numbers less than three gave me wrong results.

It failed in so many ways.

Well, the reason it failed in so many ways is

the result of zero is rather invalid.

So, once the user at a tester tells me it's wrong,

what am I going to do now?

I'm going to go back to this code and say,

all right, I'll fix it.

I'm going to say, integer result is equal to now,

and then, of course, the question is,

how do you feel about this?

Now, of course, is a smell,

and this is not going to be very much fun to write the code.

It only goes worse at this point than it was before.

So, we struggle with all this and say,

gosh, there's gotta be a better way to write this code.

Well, it turns out there is actually a better way,

and that is the functional style code

has reduced complexity in general.

Well, of course, functional style code removes this

accidental complexity from our code,

and part of the reason is that the code

reads like the problem statement.

So, one of the real beauties of this is,

the code begins to read like the problem statement.

So, what I can do here is, I can say,

output, and at this point,

I'm going to say numbers.stream,

and there comes the stream,

which is an internal iterator.

So, I say numbers.stream,

a dot filter, and what I'm going to do here in this example is,

I'm going to start with the filter function.

So, give me a second.

I want to reward back to what we had a minute ago,

because I want to show a difference between those two as well.

So, in this case, of course,

what I'm going to show you here is,

that the functional style code has reduced complexity.

The code begins to read like the problem statement

as we saw here.

So, let's ignore that for a minute.

Let's go ahead and put an int right here.

But at this point, what I want to do really is,

talk about how the functional style code is less complex.

So, for that reason,

let's go ahead and leave that code out there for a second.

Let's go ahead and say,

output numbers.stream.

But this time, I'm going to say,

filter, given an element,

element is greater than three,

and filter again,

given an element,

element more two is equal to zero,

and then I'm going to say,

map to int.

Well, in this case,

I'm just a map,

and I'm going to say,

given an element element times two,

but I'll say,

find first at this point.

And if the value doesn't exist,

maybe give me a zero or whatever I want to choose,

instead of it,

I can definitely make that decision.

So, given this code,

when I run the code,

both the pieces of code give me exactly the same result,

the imperative and the functional style code.

But on the other hand,

the functional style code is a code

begins to read like the problem statement,

given a collection of numbers,

get me numbers that are greater than three,

get me the numbers that are even,

get me the double of that,

and then get me the first one,

and if not, you may as zero.

Well, if you look at this code,

this code is elegant.

This code is,

I'm going to simply say,

this code is cute,

and we can absolutely agree with that,

and we can say this code is cute.

But unfortunately, though,

a lot of languages give you this.

Java does this,

C-sharp does this,

but Ruby and Python and small talk and,

and, and,

Ruby and JavaScript,

a lot of languages give this.

But I've come to a grim realization in life,

and that is,

a cuteness is not sustainable.

And this is the sad part,

when I want to go to see a very small child,

a friend, a relative call,

see one says,

we have a baby,

and we go to visit the baby.

This is just so small baby.

And of course, when you go to see the baby,

the first thing my wife wants to say is,

how cute,

and I go to the child and say,

kid, it's not going to sustain.

And this is the truth, isn't it?

Because the child is so cute

for two years of the human life.

And then if two years,

what do we say?

You're annoying.

You speak too much.

And that's called the terrible two.

So, cuteness is not sustainable,

unfortunately.

And that is exactly true,

what for functional style code.

You cannot look at this code and say,

it's cute.

And the next thing somebody sells to you is,

yeah, alright.

What's the performance look like?

Well, if you cannot give performance,

all the cuteness is a total waste in our life.

So, we want to be cute,

but we can,

but we want to give performance as well,

that's absolutely critical.

So, in other words,

efficiency,

efficiency rules at the end of their day.

Right?

So, this is the true fact of life,

efficiency rules at the end of their day.

So, you cannot just simply say,

it's cute and walk away,

what about performance that becomes absolutely critical.

So, what do we do about efficiency of this code?

What if I look at line number 26 and say,

I compute the result for every single value,

and then for even numbers,

and then double those values,

and then I return the first throwing away

all the other computation,

what a real waste.

Now, let's think about what's going to happen

in this particular case.

So, going back to this code,

let's refactor this just a little bit.

I'm going to write a function here called Boolean,

and the Boolean is going to say,

E is greater than 3,

takes a number,

and it simply returns the number,

a greater than 3 for a minute.

Similarly,

I'm going to write two other functions.

The next function is going to be E's even,

and all that it's going to do is return

more 2 is equal to 0,

and finally,

this is going to be a double it,

and which is going to simply return the value

and times 2.

So, given this code,

of course,

what I want to do is use that code in here.

Now, look at the imperative style code

for just a minute.

How does the imperative style code work?

Just the highlighted part,

if you focus on.

We pass a 1,

it says,

1 is not greater than 3,

2 is not greater than 3,

3 is not greater than 3,

or 5 is greater than 3,

but it's not even,

but 4 is greater than 3,

and 4 is even,

double it.

So, that was eight computations

to get the result in the imperative style code.

Let's prove it.

So, to prove it,

I'm going to say,

E is greater than 3 right here,

and I'm going to then say,

E is even of N,

or our E rather here,

and then finally,

I'm going to simply call a double it over here,

and of course,

as a result,

we can pass the data.

When I run the code,

what is it going to do?

Well,

in this case,

of course,

it is going to provide that value.

Let's go ahead and make sure that I'm using the right function here.

So, when I go back and call this function,

you can see,

it is telling me that it is going to be eight computations

to run this code.

So, what is this really provide for us?

Let's go ahead and put that little statement right here.

I'll say,

call the E is greater than,

we'll say E is greater than 3,

and then we'll say,

called over here,

and we'll say,

E is even,

and finally,

called over here,

we'll say,

double it.

And when I run this code,

what is it called for?

Well,

we'll go ahead and say,

let's go ahead and say,

plus N here.

So, we can actually appreciate the value,

it's calling that for,

and then we'll simply stay plus N.

So, when I execute this code for the imperative style code,

you can see that it performed a total of eight computations right there,

1, 2, 3, 4, 5, 6, 7, 8.

So, eight units of work,

and we got the result in the imperative style of code.

But the question to ask is,

what about the functional style code?

Well,

if I'm taking 10 values and comparing greater than on 10,

that is 10 computations.

That is,

that is,

on a rival,

isn't it?

10 is greater than 8.

Let's add,

instead, to injury,

this is going to compare the even for seven values in the collection.

This is going to double four values,

and then it's going to return the first value.

So, that is going to be 10 plus seven is 17 plus four,

is 21 computations.

So, what if I say,

the functional style is cute,

but you're going to spend 21 computations versus eight,

you're going to say,

get out of here.

So, we are not going to be tolerating a functional style code,

if it results in poor performance.

So, what do we do about it?

Well, thankfully,

this is one of the things that streams really provide very elegantly.

So, what does the stream really do?

Streams are really built on top of laziness.

So, what does it really mean that streams are really lazy?

Well, to understand this,

let's go ahead and convert this code real quick,

and we will go ahead and call the ease even right here,

and then finally,

of course, we'll go ahead and call the double it function right here as well.

But before we run this,

let's talk about how this is going to work.

Now, when you look at the stream,

the streams are fundamentally lazy.

I've only seen this characteristics between my own children

and streams.

My children are fundamentally lazy.

I'll share with you an experience I've seen in my house.

My wonderful wife will tell my son,

you know, a torn off the TV.

It's like no words were spoken.

And then she will tell him,

what the trash out and no muscles were really moved.

And then she tells him,

do your homework not a pencil was picked.

At this point, she simply says,

call daddy and everything works.

And so, they're going to rename this as call daddy.

So, the point, and somehow,

since it's called mommy,

it depends on the household,

I always say parents play a good cop in a backdrop role,

you cannot know what I play.

So, the point really is that these are called terminal functions.

The terminal functions are the ones

that trigger the evaluation.

So, the way that streams work is,

when you go to a stream and say filter,

it's like, yeah, maybe later.

Hey, filter again, maybe another time.

Map, well, some other time,

and find first, or dear, let's do it.

And at that point,

it's going to do it minimally, what's expected.

So, if I run this code,

notice that we have exactly the same sequence of evaluation,

eight calls to this function,

no more and no less in this particular case.

So, the functional style code is as efficient as

the imperative style code,

when it comes to the number of computations,

it performs, and laziness really brings us for that.

And without laziness,

there would be no fun using the

expressive nature of function of style of programming.

This is especially true with big data projects.

I work with clients who are dealing with literally

millions of data that they have to process,

and when we deal with 70 or 80 millions of data,

we cannot be doing inefficient computations,

laziness really saves the day for us,

and that becomes absolutely critical.

So, with that said, we have laziness,

but what is laziness really lead to?

So, to wrap this up, I want to really,

come back to this,

immutableity is essential for lazy evaluation.

This is absolutely true.

Immutableity is essential for lazy evaluation.

If you don't have immutableity,

if you're mutating data,

you cannot postpone evaluation.

You would always worried about

what's the value going to be now,

and if it is mutating,

your question is to use the value before mutation

or after mutation.

But if the value is immutable,

it doesn't matter.

It is not going to change.

You can evaluate now.

You can evaluate later,

or not bother evaluating at all,

and you can postpone that quite a bit.

Well, with that said,

lazy leads to two things.

One is efficiency.

But it also leads to one other beautiful thing,

which is infinite, infinite streams.

So, infinite streams are pretty darn good way

to express certain ideas in code.

It leads to efficiency,

but it also leads to infinite streams.

The idea of infinite stream is to be able to

generate a boundless collection of data,

but how in the world can we create boundless collection of data?

We can enjoy these ideas

if we get a good hang of laziness.

So, to understand this,

let's take a look at a slightly different example here,

let's go ahead and say that I want to start with

a little example of a sample,

where I have a method called esprime.

It returns whether a number is prime or not.

But notice the main function.

The main function says,

n is equal to 101 and n equal to 51.

It calls a compute,

but what does the compute do?

Compute is going to return the total of square root

of the first k prime number of starting with n.

That's a simple problem.

Let's try to implement it in the imperative style first.

So, I want to say double result is equal to zero,

and I want to return the result when I'm done with it.

But then what I'm going to do within this is,

I'm going to say over here,

what is this index is equal to zero,

or rather,

into equal to n,

in count is equal to zero.

Well,

if you notice over here,

we set up some variables,

but then I say,

while count is less than k,

and I come to a grinding halt

and ask the question,

is it less than k or less than

or equal to k?

Not sure,

still.

Then I say if,

and I'm going to take the index value

and say,

e is prime of index,

then what am I going to do?

Then I'm going to say,

a result is plus equal to

math dot square root of index.

Now,

if they ask you if the code is correct,

you're going to say,

no,

it's not correct.

Why not?

You have to increment the index.

Well,

then you say you have to increment the count as well.

Then you tell me,

you have to increment the index inside,

but you have to increment the count,

or rather,

count inside and index outside.

How do you feel about code like that?

This is an example of accidental complexity.

Now,

if you write a code like this,

you are staring at it to find out what the code is doing.

And that faithful movement,

the business analyst comes to you and says,

hey, how's it going?

And your response normally is,

I'm trying to find out what the code is doing,

you shut up.

That's all we feel about it,

right?

We get irritated.

What if the code can be really expressive,

wouldn't that be really nice after all?

Well,

that code ran,

but let's try to do this in the functional style,

how do we really execute it?

Well,

what I'm going to do here is,

returnstream.eternrate,

and I'm going to take the value end to begin with,

given an element,

element plus one.

Stop right there and look at that code for a minute.

What in the world is this code doing?

This is an example of an infinite stream.

This stream says,

I will give you value n,

n plus one,

n plus two,

n plus three,

n plus five n plus six,

and keeps on going,

never to ever stop giving you that value.

I know what you're thinking,

you're thinking,

oh my goodness,

if the stream is really infinite,

where in the world will you store it on the cloud,

of course.

But the point really is,

that this stream is absolutely boundless.

Well,

the beauty of the stream is,

it is lazy evaluation.

It is smart enough to say,

I will give you infinite stream,

if you dare to ask for infinite stream.

Of course,

we don't ever ask for something infinite.

So this is on demand.

It's like all the movies and Netflix.

You only watch what you ask for,

not everything else that's there.

It almost feels like there's infinite number of them, isn't it?

That's the whole point is,

you're going to generate this on the fly on the demand,

and that is laziness right there.

But then what I can do here is,

I can say,

and the filter simply says,

a given a collection of numbers,

get me only the prime numbers,

not anything else.

So given all the numbers starting with n,

give me all the prime numbers that start with n,

then I say,

and I'm going to ask for met square root.

So given all the numbers that start with n,

give me all the prime numbers that start with n,

but give me the square root of all those numbers,

and you say dot limit k.

Well, is it k or less than k or less than k,

or less than k,

it's k damn it,

don't have to worry about it,

move on,

and then you can perform the sum operation on it,

very easily,

as you can see,

to get exactly the same result as the other one.

So you can see how the code becomes very highly expressive,

and that's an example of using an infinite stream,

to solve the problem.

You can,

there's a slew of problems,

we never really experienced in languages like Java,

because we never had the ability to so easily create an infinite collection.

But now that we have the ability to have a level of interaction,

the ability to really postpone computations,

we can benefit from solving problems

that were otherwise even hard to imagine,

and we can use laziness,

and we can use infinite streams to solve the problem.

So to me that ability to do really infinite streams,

is one of the charming capabilities of the language,

that gives us the ability to look at some algorithms,

and solve those algorithms in ways we probably never really imagined solving in the past.

So to summarize what we talked about here,

laziness really is important,

because I want to reiterate what we talked about.

Efficiency is not about running a fast.

It is about avoiding a task that should not be executed,

in the first place.

So in other words,

this is really the core of efficiency,

if you really think about it.

Efficiency is not about running fast.

It is about avoiding tasks that shouldn't be done in the first place.

So as you are formulating your ideas and algorithms,

if there are computations that can be saved away,

as an example,

one of the things that leads to also is,

ability to really postpone computations,

the point where maybe you never have to execute it.

And if you never have to execute it,

why?

Because your code says,

if I don't have a reason to run this,

I can completely discard this evaluation,

and I don't bother running it,

and that is a very powerful way of executing,

expressing code.

So it's not just the expressiveness of the code,

but the efficiency of the code will bring to you as well.

As an example,

let's go back to this code and look at it one more time.

If I were to go to this code where,

I am implementing this code as a laziness,

if you will,

what I want to do is the ability to postpone operations.

Now, the code can be very efficient

to the point where you can never be more efficient than

not executing a piece of code, isn't it?

Because if when a code is not even executed,

it takes the least amount of time than any other thing you can provide.

So going back to this example real quick,

if you will,

when I run this code,

you can see it called all that function right there.

On the other hand,

let's go ahead and remove this for just a second,

and I'm going to simply stop at the fine first right here,

and at the very end of this,

I'm going to simply say,

done.

When I execute this code right here,

you can see all that output and it's said,

done,

but the beauty of this is,

I'm going to simply go back to this code,

and I'm going to comment out just the last part in the code,

and I'm going to simply restart this code,

and you can see it said,

done,

it did not bother to really execute the ease even function,

or the ease greater than three,

or the double it,

and to me,

that is the ultimate efficiency you can get,

is that you can draw this pipeline of these,

this functions,

and but the function pipeline is not exercise until

you attach a terminal operation to the pipeline.

If you don't attach a terminal operation,

obviously then the execution doesn't really,

based its performance,

and efficiency is by avoiding all the tasks

that has no real benefit,

no real advantage,

and that is where the efficiency comes through.

So if you're interested in downloading the code,

examples,

you're most welcome to download from my website,

I'll be delighted to hear questions that you may have.

Thank you very much.