A very impressive speaker with a reflective approach to programming, that keeps me on the edge of my seat. Highly appreciated.

"we as a species figured out how to electrify rocks and make them do what we want" ... made my day

Thank you so much for actually understanding and expressing what the OO paradigm is! Very rare to hear.

This lady is really talented at speaking on these subjects, all of her talks are an easy watch.

So happy I found this talk. The metaphors are simply amazing.

This is one of the best tech talks I've listened to. Thank you, Anjana. Best wishes.

An excellent explanation of programming paradigms. Well researched and delivered. Thank you.

Watched the whole video on one breath. Excellent speaker!

What a great talk!

Fantastic presentation! Love the more philosophical talks :)

Exceptional talk, really got me thinking about my own paradigms in the real world; and of course in programming.

She is one of the best speakers!

love her way to share tech from philosophy perspective by making complex problems into a very understandable way, love her passion. Really help me to understand.

This is such a great talk

a lot of time and caffeine would have invested in coming up with such a unique way of explaining paradigms(not only programming) and how to attend them given multiple situations!!! Great work!!!

Thanks for the talk it was very informative.

thanks for the great presentation!

So well presented, explained and executed.

Great researcher and very well presented topic!

Best technical talk I’ve ever encountered

Really well presented. Interesting topic. Good stuff!

Anjana is the best!

That was fantastic

informative nice talk, thanks for sharing

Brilliant analogies 👏

great presentation

Excellent talk! At 41:40 on multi-paradigm languages part, I was thinking Javascript :D

10:22 "commands, that we human overlords; for now" i died

Even though I know all the ideas she talked about, I doubt I could express it as clearly as she did.

Love you Anjana

brilliant .

So glad we have someone in the programming community to teach us be open minded and humble

Reminds me of Joe Amstrong's talks... great!

Very good.

nice presentation and sound better

Oh man 26:32 killed me! Great presentation!

Ah, no wonder I thought she was familiar, I watched her functional programming talks, she seems like a really cool person.

GOOD RESEARCHER

Trabalho da facul, é noixxx

Good communicator! This example at 39:49 should not be attributed to functional thinking, however. This is example of data-oriented thinking.

22'10" paradigms chart 23'30" OOP Vs Functional programming 27' Example

where is the example when this breaks down? i.e state change that is remembered by the object. this is just a query

I am new to programming, about 9 months, and I am trying to up my game and implement functional(ish) programming in javascript and I have a question about mutability. Is it ok to mutate data if it is only happening during the generation of a new value? For example if I do something like this with reduce? It seems like technically I am mutating the object as reduce recursively traverses the pairs array but I don't see the issue with that. I understand why we don't want to mutate data but are there any exceptions for that? Here is some code to better explain what I am talking about. const queryURL = "user.name.first=Patrick&user.name.last=Holtzman&user.favoriteLanguage=JavaScript"; const convertQueryToMap = query => { const pairs = query ? query.split("&") : []; return pairs.reduce((obj, pair) => { const keyAndValue = pair.split("="); const key = keyAndValue[0]; const value = keyAndValue[1]; return extendObject(obj, key, value); }, {}); } // here I am mutating the object as it builds out with reduce const extendObject = (obj, key, value) => { let currentObject = obj; const attrs = key.split("."); attrs.slice(0, -1).forEach( attr => { currentObject[attr] = currentObject[attr] || {}; currentObject = currentObject[attr]; }); const lastAttr = attrs[attrs.length - 1]; currentObject[lastAttr] = value; return obj; }

Speaking about being open to shift, have you investigated TLA+ and the underlying programming model/paradigm? I created the SAM pattern from it (sam.js.org). There is something incredibly natural when it comes to program with SAM. Interestingly it has a bit of all the other paradigm (including Reactive Programming and State Machine semantics, not to mention OOP, FP, DP).

I prefer the form "we electrocute rocks to trick them into thinking for us."

Hot take: we don't need more paradigms. We need more imaginative/creative programmers. The 4 major paradigms are like the primary colors; one can mix-and-match the primaries to get different colors that can be used to paint an beautiful painting.

The point is obfuscated by language, or rather how we respond to the message. A programmer is bound to a world view of how code works, not hardware that processes it They carry object models from one problem to another. Anjana "paradigm" to model the physics of a function ..in detaching high level language implementations , into declarative expressions, Now we have context aware API in F# . The missing link is Adaptive Fabric to solve problems with change to hardware , not twisting syntax in fixed load store register base

what even are microservices? any good talk about them?

@leocomerford

6 жыл бұрын

Try kzread.info/dash/bejne/qGVrpq-idqvUcps.html and kzread.info/dash/bejne/qZuYpLiCiJzPlqQ.html ?

I doubt that anyone working in modern Scrum will be able to develop a new paradigm...

Hmmm. Call me skeptical. AFAIK, the typical programmers that I work with struggle with being effective in one or two paradigms, let alone being able to pull in ideas from a lot of different paradigms. In trying to be more effective and pulling in additional folks to make progress faster, I constantly struggle with selling ideas to folks that don't directly align with experience and skills that folks already have. Typically, it seems like it is in their own best interest to just go along with what they've done to get to where they are now.

OOP with a functional style, like rxjs...

Slides link showing error

@GOTO-

5 жыл бұрын

Thanks for noticing. We will fix this asap.

One word: Scala.

crush

@ravishankar3885

6 жыл бұрын

bhabhi hai teri

@saringali9439

6 жыл бұрын

lol .... maidan pe aaao sab jo jeeet wohi sikandar :D

"I'm not your guy, buddy" xD

@redhen

7 жыл бұрын

"...I'm not your buddy, guuuuy" xD xD

@PatrickHoltzman

6 жыл бұрын

const canadian = { respond: (a, b) => console.log(`I'm not your ${a}.. ${b}! `) } function selectNextName(name){ switch(name){ case "guy": return "buddy"; break; case "buddy": return "friend"; break; default: return "guy"; break; } } const backAndForth = min => max => name => { const nextName = selectNextName(name); if (min backAndForth(1)(duration)("buddy"); typicalCanandianConversation(10000000000);

How many years of paid development? Just silly! I believe in encapsulation because I normally see problems in code by finding data that isn’t correct. It takes much less effort to correct the code if it is close to that data rather than looking all over. Many people criticize global variables (and rightly so in some cases) because it is difficult to find the offending code. This attribute of OOP has nothing to do with cells or any other real world parallel. I program mostly in C and some of my functions are “pure”, some are procedural and some are a form of OOP. I just love to get lectured on development by rank amateurs.

@salvadorfajardo4639

3 жыл бұрын

funny you're doing what her conclusion says is the best thing to do, but your comment reads as if you don't agree with her speech.

Aaannnd ... she lost everyone on the Scheme (LISP) example ... lol. Nice talk otherwise.

@victorklimov5254

7 жыл бұрын

Not everyone)

well functional programming is an apt comparison to capitalism, you just keep creating new things and let someone else clean up the mess

this is first comment :D

@SamVsCode

7 жыл бұрын

No shit!

I'm afraid what she calls functional programming lacks purity as she is using closures. Which means, that the same input must yield the same results ALWAYS, but that's not the case, as the closure is holding on to some state. That's the basis of functional programming Referencial Transparency which is violated in the example at 28h minute.

@frydac

7 жыл бұрын

If I understand the wikipedia article on referential transparency correctly, the 'free variable' the closure captures is the name of a function, which is statically bound. Which would mean there is still referential transparency in that example.

@mcalavera81

7 жыл бұрын

Captures the variable friends which can be mutable. friends=['alan', 'alonzo'] buddy = Friend(friends) print(buddy('is_friend_of','guy')) ## False friends.append('guy') print(buddy('is_friend_of','guy')) ## True

@sasha_chudesnov

7 жыл бұрын

well, there was no .append in her example, and of course there's a way to 'fix' yours - make .append return a new instance rather then extending the existing one.

@NWCalvank

6 жыл бұрын

In the example given in this thread, friends is passed into the closure by reference, but in hers it is passed in by value. In her code, friends is not accessible via a shared variable in an outer scope. So, while it could technically be mutable, there isn't a way to reference it from another scope in order to mutate it. So, the closure is referentially transparent. Mind you, being that it's Ruby, making friends into a constant should also work in order to prevent mutability if the value needed to be passed into multiple methods -- so long as all the data is known at the time the code is written.

A little disappointed. To understand most of the programming paradigms presented, one must have a little experience in each of these paradigms. If one does have experience, its almost easy to predict where the lecture is headed (which is what happened in my case). As a result, one gets little out of the video. So, a little disappointed. Learned a few great quotes though. Thanks.

@IMHGfk

7 жыл бұрын

I am wondering if you missed the point of this talk a bit. I think, this was not about giving an introduction into different programming paradigms, but rather creating an awareness of what a paradigm as such is needed for and furthermore the need for developers to be able to think and move "between" paradigms. The little introduction to those few paradigms she mentioned seemed to be rather a framework - or a backdrop so to say - against which she was able to explain her and others thoughts about programming paradigms.

@gmnboss

6 жыл бұрын

Why don't you create a talk to meet your criteria?

"I'm, I'm, I'm, I'm, ...", a little narcissist to my taste.