Try Haskell. You can basically do all the logic stuff Prolog can do (like pattern matching! Yay!) plus a lot of really neat functional programming things. It will break your brain in a good way.
Sam MacKinnon Yeah, I've learned a bit of Haskell, and got quite into the functional way of doing things. So you're saying it can be used as a logic programming language?
Yeah, I think if you take advantage of pattern matching, you can do a lot of the same things -- I took a course where we learned Prolog in the first month and a half and Haskell for the second half, and a lot of the Prolog logic ideas could be carried over and expanded on in Haskell. That being said, I clicked into the functional stuff more than the logic stuff, so it may just be that I understood Haskell better than Prolog :P
Sam MacKinnon Using Haskell as a logic language is less than ideal. While it looks like they have similar features, their fundamental understandings of computation is vastly different. If you really wanted to do logic programming with Haskell, you'd use the type system as a theorem prover, which it was not designed for. An illustrative example is Aphyr's "Typing the Technical Interview" post.
I once saved a massive project by implementing 68K assembler's link instruction (learned on Commodore's Amiga) in CICS COBOL II on a mainframe to create a stack frame. The mainframe guys hadn't even heard of pointers, let alone realised that that was how the Linkage section worked, and COBOL II had just introduced pointer functionality so having 3 lines of code that solved their problem it seemed like magic to them.
@kwccoin3115 Of course it was available in assembler but not COBOL. The linkage section works by pointers but it wasn't until COBOLII that you could use "set address of..." to use them yourself.
Long time ago, about twenty years, I had to solve the same problem with the same language (PROLOG) at the university. Many things have changed but I never thought to find the solution 20 years after.
After watching this I feel more comfortable venturing onto other languages. I was always afraid it would somehow confused me and lead me to forgetting my primary language but now I see it will only make me better if anything especially if it is another style of programming
You must be from outside of California where jobs aren't in massive quantity for programmers. I see alot of programmers from CS degrees who simply dont have such basic concepts down. Sadly, I have known plenty of CS degree indivduals who sadly never took the time to do this and kind of just treated these classes like general ed (memorize and forget momentarily after test and semester)
@@theblackhundreds7124 Unfortunately, that is what at least 2-4 year schools I have had experience seem to do. They have a series of general criteria they want the students to learn, in a somewhat tight time-frame, and you test them for that. There is no emphasis on a deeper or better understanding, they leave that to the student (who usually doesn't feel the inclination to do too much extra with all the other large bits of course-work for other classes). I think how financial aid and government laid down dos-don'ts has gotten in the way for a lot of how these colleges operate, and not for the better.
This is what they SHOULD be able to do... But most schools are too busy running up the tab on their student loans and indoctrinating them into the liberal cult to actually teach them.
I thoroughly enjoyed this talk. Some negative comments have been made but I don't think the intent of the talk was for you to follow every example completely and understand every detail. I think the intent is to show that different languages embody different mindsets when solving a problem. More importantly, you can learn new languages and think differently about solving problems and you should.
Near the first 10 minutes I had been doing a search on CAR and CDR. I got pretty much everything but what they said the acronyms stood for. When that guy went "ahhh" in the background much later, it shocked me out of my stupor (mind on tangents) and I heard the echo of what he was responding to. Only because of him did I get to go back and catch what she had just ran past. The object of my heart's desire. I programmed in assembly in college so it was familiar. I just didn't expect it to be mentioned in...was it Racket or Prolog...
I did know it existed, and I did know the philosophy behind how it's supposed to work, and I did try to learn/understand its basics some time ago... and failed. This talk succeeded. :)
Indeed this is a true gem! Sadly most of videos which public sees are just “recipes” on language syntax or framework, whereas this presentation marvellously shows cross paradigm programming and unlocks your mind from being locked onto syntax. A++ ps. I also like Kevlin Henney s videos : he also looks at code in more profound and conceptual way rather than just syntax.
Already loving this talk. After having an informal learning experience with code, it is very helpful in understanding the actual concepts of the language more in depth. Reallys helps my understanding of C# and makes me more comfortable venturing into C++
I think that what many people do not realize is that we *think* in the same way that LISP programming is done. It's actually IMPOSSIBLE to know that you are adding two numbers (in your head) without telling yourself that you're going to add two numbers. Therefore, the operator should come first. Even if someone grabs an arbitrary collection of numbers, and you tell them "okay, now add them", just by saying that have placed higher priority on the operator than you have on the operands.
I see your point but you do say: „a times b”, which to me sounds more like an infix way, rather than prefix („multiply a by b”). Obviously, whichever works for you :) - I just prefer to visualise infix operators as functions, eg. „add(a,b)” or „multiply(a,b)”. BTW, that looks quite similar to Excel formulas ;P
@Bob It's called a curated list. And AFAIK Coding Tech never posts without authorization from the source if the license does not allow re-posting. And if you still want to piss all over the Cheerios you can go watch the original, it's linked to in the Description.
It is mostly used for parsers or theorem solvers or modeling of non-deterministic automatons. And to be honest, it isn't really good for anything else. It is inherently slow, requires huge amount of RAM and it obviously has a significant mental overhead.
This was a great talk. Kudos. I was educated in machine code, assembly, basic, c, b, fortran, cobol, and cpp. I've sent things to space and made machines interact with humans in physical and direct mental ways. I understand why we need higher level languages and object oriented programming, but the fundamental problem of the "task at hand" getting beyond the brain of the programmer remains. The technological singularity is probably the moment we program the perfect programmer. But we can't have the perfect programmer until we have the perfect language. And by language, I mean human language, not programming language. From that, all else should be a trivial exercise for the common reader. We need a new language, one that is perfect, without ambiguity. It's just around the corner, we are almost there. This is scary, to be honest. I sure hope the TS is our servant, and not our master. Agriculture and domestication of animals was an order of magnitude advance for mankind. The industrial age was 2.5 orders of magnitude advance. The TS is an infinity power advance. We can't even imagine what the exponent is. Godspeed, fellow humans. You've been given an incredible beyond belief blessing, if you can keep it in your control. Make sure you always control it!
Racket is designed from the ground up to teach functional programming. It is the rename of PLT Scheme, which is inseparable from the DrScheme IDE, which is as much a tutorial app as it is an environment. I assume you know the relationship between Scheme and LISP. Symbolics Inc. and TI and Xerox used to make LISP Machines in the 80s, whose OS was in LISP in the 80s. I believe LISP or LISP-like code was embedded in their CPUs. I used to daydream about getting my hands on one of those.
@@casperes0912 All those parentheses are part of the power of Lisp. Lisp's syntax is very uniform, making it easy to write macros that generate Lisp code. These macros make up a large part of the power of Lisp.
Ultimate lecture!!! Ma'am you rock - reminded me of my CS307 course at UT. ( loved that course). Your lecture Bought back memories of my undergraduate studies at UTCS before I 'chickened' out to UTECE. ( pan to fire). But UTCS forcing me into polyglotism made me better Computer Engineer. Being in EDA requires you to be a polyglot.
From the register names in the IBM model 704 on which LISP was originally developed. Incidentally FORTRAN was also written for the 704 and it's instruction set weirdness accounts for the odd way memory was laid out in original FORTRAN and for the notorious 3-way branch.
i've watched so, soo many of these tech talks over the years + rarely ever do they contain ads that distract from your attention.. 10 mins in, and they've already played 3.. beyond excited for this talk but it's sad to see a favor of monetization over the integrity of the content/knowledge..
What a great talk, I know javascript but it gave me a lot of pain when I try to learn java and kotlin to build my first android app. Kind of miss the most fundamental different since I don't take any computer science degree.
'Assembly... Very very limiting' Have just remembered my study times when I had to solve problems in Post Machine language... Believe me, assembly is a very very syntax rich language ))
I'll never understand why people usually study a primary discipline with multiple languages. I mean, I get that each language is based on a more appropriate paradigm. But I think learning languages is a secondary thing, that you do based on your needs. You just have to understand in first place what means object oriented, functional, logic and procedural programming, not the languages themselves. That's why I teach Programming Paradigms in Python, which is "multi-paradigm" and easy to learn. Logic programming is the only paradigm we approach with other language, PROLOG.
It's really nice of her to use modern languages. That makes this video digestible for even the beginners. Jokes aside, I find this really interesting but I'm obsessed with learning new languages, I would have assumed that most people would be turned off from the talk with such obscure languages used for the examples.
Procedural is just how any sane person solves tasks - top to bottom. It's just PURE procedural/functional without much abstractions is hard to wrap your brain around.
40:36 THIS. I mean... thanks, the talk was great, I finally understood the basics of prolog, but... 40:36 THIS... Info about this book existing was such a huge, HUGE BEAUTIFUL GIFT for me... thank you...
The answer to the logic programming joke is 'Yes'. 'No' implies that there are no logic programmers who can screw in a lightbulb. 'Yes' implies that there is at least one answer to the query, and that the query itself was malformed in the first place, as the query *should* be something like, "?- logic_programmers_needed_to_change_lightbulb(X)."
This is an excellent talk - well presented and fascinating. The speaker is great and has a nice sense of humour. If you're serious about programming you should definitely watch it - even if you've touched on the topics (see "The Red Willow" below) previously.
29:48 the prolog code is wrong. The recursive call in the second clause must have R instead of [F|R], because when you put F there, it allows you to "re-use" a coin that has already been deposited. The way it is here, ?- change(5, [2,1,1,1], C). gives you C=[2,2,1], so two 2s, although there was only a single 2 in the available coins.
By the way: this also works with 2 lines less: change(0,_,[]). change(S,[F|R],[F|X]) :- change(Q,R,X), S is F + Q. change(S,[_|R],X) :- change(S,R,X). (it is slower though, because it goes through all sub-lists and selects all that have the right sum).
Object orientated programming is fundamentally flawed at its core - fite me irl if you disagree. The problem with the object in OOP is that it's fundamentally only a good representation of a static map of the real world. In theory objects look like a good way to represent the world as we have a 2019 Mercedes G-Class (which is apparently the coolest new SUV according to Doug DeMuro in the sidebar) which is a type of SUV, which is a type of car, vehicle, etc. And we can have another class tree called a dealership (shop>utility building>building>etc) which perhaps has a list of vehicles and we can easily add that SUV in. That's great, when you freeze time and put everything in the world into this object mold you can pretty accurately get what is essentially a map. The problem is these maps don't work in a changing world at all. Somewhere down the line the requirements are going to change, and let's say after 6 months the following changes have gradually been made: The dealership also starts selling timeshares. State law requires dealerships to keep a record of all of the dealerships their vehicles have ever been at. We need to keep a list of employees who work at the dealership We need to keep a list of which, when and where employees drove any vehicle (including their own - liability for hitting parked vehicle) We've expanded and need to keep track of multiple dealerships - employees and vehicles can be moved between them The new team wants to take a bunch of statistics - which customer test drove what, for how long What you'll see is that unless you are willing to do basically entire ground-up rewrites (+ if you have an API then fuck 'em) for most of those features then you quickly end up: Needing to access, e.g. the dealership class from everywhere. There's now probably references to it inside vehicles, employees, etc. In the original map we could use the traditional OO inheritance map to send messages between the dealership class and the vehicles, but now that has broken down. Instead of using the inheritance hierarchy we end up just sending the dealership class everywhere, and/or: we end up doing something worse and creating a pseudo-global variable class. Maybe we don't do this when we suddenly need the dealership class reference everywhere, but in the later changes we end up needing references to employees everywhere as well. It's not easy for us to come up with a communication method without a significant rewrite, so instead what we may end up doing is creating some sort of class called "CompanyMetadata" and in it we just store a list of employees and dealerships, then we just pass a reference of this all over the place. And we've essentially created global variables. We're also feeling that chaos coming into the code as we start seeing the other problem with OO, which is we're creating classes for the sake of it. We've also got another problem now, which is that the dealership is being referenced everywhere and it's becoming hard to manage the dealership itself. This is where we start feeling more chaos as we're about to start creating classes to deal with the dealership which will have stupid names like "manager", "controller" and other nouns. Now we've ended up with some sort of DealershipController class which has code to manage the dealership. Now someone could come in here, and build a nice OOP way to rewrite all of the code, where everything communicates nicely in its hierarchy, and various classes can be decorated with things like employee, etc. And the model they come up with looks as brilliant as the original for the project did. This is how so many projects tend to end up looking, and you can generally tell right away because you're jumping all over, up, down, left and right through a bunch of different files before you find the most basic functionality of the project. I think this is where we get the big problem with OOP, which is that it's only good for describing a map of the world. It fails because in reality which objects end up needing to talk to one another has no relation to any sort of hierarchy and the more and more unpredictable interactions between objects we need to account for, the worse and worse the code generally seems to get.
Good example and fair point, but OPP is one style of several, as mentioned in the talks languages are a tool and some work much better than others. There are good ways to write code that should be requirements people don't do due to lack of time for project or laziness. What type of language are you more of a fan of?
Yep, spaghetti code from hell. The world is NOT static. Nor is action and thing the same as oop generally aims for. The data and the code are separate things. Either should be changeable in detail without screwing up the usability of the other. You cannot do that very easily where the data must have it's own special handler basically baked into.
"Different problems match different solutions." - "No they don't here, have one example of something that creates problems in OOP, therefore it is com pletely useless, fight me!"
This is just a general problem in programming, one of the biggest strong point of OO is that it can deal with this. Good OO keeps coupling low and has high cohesion, this makes it easy to extend. Trust me this is the first question they will ask in an OO course, "now adapt your design to an extended situation". This is actually where OO really shines, you can reason about and extend very large and complex software. I would be curious why you think any other paradigm does this better.
The make-change function in Racket broke me, I mean the whole point of the function is to return a list with the change we're giving back to the customer, but the function she showed just keeps recursively calling itself with a decreased value of x, until eventually x reaches 0 and the function returns an empty list! Please correct me if I'm wrong
As a CS grad, I can tell you, we keep up with this shit only when there is no way around it. When one of our profs decided she wants us to use only Lisp in her class, everyone dropped it for something else
I think a bit misleading to show assembly for procedural. Java, C, C++, etc are all procedural but can also be functional -- they are hybrids and flexible. I like procedural as the core for logic, functional for pieces in which breaking a problem down is intuitive, and Objects for fragile state that should be packaged together and guarded.
the one thing I'd like to criticize: Assembly is not 'old school'; Assembly is, for the most cases where it is actually used, just a transcription of machine language. It will always be used to get the basis of a physical system running unless we get a major paradigm shift from all current architectures.
Haskell is pure functional unlike Racket, but much shorter and does not need the sea of parenthesis. Same algorithm: make_change 0 _ = [] make_change _ [] = error "Can't make change" make_change x (d : ds) | x < d = make_change x ds | otherwise = d : make_change (x - d) (d : ds)
Fantastic talk! I believe there might be an oversight tough? Assembly language is technically not procedural, right?. It's very low-level imperative, but it is not structured or procedural. Procedural implies subroutines / functions, which are not a feature of assembly languages. Assembly is a paradigm in itself, but it doesn't seem to follow procedural patterns natively? Or which procedural patterns did we see in the procedural examples? Loved everything about this video, but had this thought / nitpick / doubt.
In the first example, wouldn’t it be more efficient to put a loop around each currency denomination, breaking out when the denomination is greater than the change owed, rather than having one really big loop that goes through a whole bunch of conditionals each time?
2:49 Objected-oriented programming w/Ruby
10:48 Functional programing w/Racket
19:46 Logic programming w/Prolog
32:08 Procedural programming w/Assembly
Thank you very much, you made my life much easier :)
thanks for your kindness
Tysm
thank you
Thank you man you saved my 40 mins ❤️
13:15 "math is not particularly interesting on its own"
*angry mathematician noises*
@@JinnGuild good
There are a select few who love math for what it is. Most love it for what it can do, or they "hate it".
After going through LISP and Prolog I was actually relieved when assembly came up!
I love this talk. She did a great job with this.
This was actually pretty fascinating. I kind-of want to learn a logic programming language now.
Object Oriented ones are the simplest imo
Try Haskell. You can basically do all the logic stuff Prolog can do (like pattern matching! Yay!) plus a lot of really neat functional programming things. It will break your brain in a good way.
Sam MacKinnon Yeah, I've learned a bit of Haskell, and got quite into the functional way of doing things. So you're saying it can be used as a logic programming language?
Yeah, I think if you take advantage of pattern matching, you can do a lot of the same things -- I took a course where we learned Prolog in the first month and a half and Haskell for the second half, and a lot of the Prolog logic ideas could be carried over and expanded on in Haskell. That being said, I clicked into the functional stuff more than the logic stuff, so it may just be that I understood Haskell better than Prolog :P
Sam MacKinnon Using Haskell as a logic language is less than ideal. While it looks like they have similar features, their fundamental understandings of computation is vastly different. If you really wanted to do logic programming with Haskell, you'd use the type system as a theorem prover, which it was not designed for. An illustrative example is Aphyr's "Typing the Technical Interview" post.
I once saved a massive project by implementing 68K assembler's link instruction (learned on Commodore's Amiga) in CICS COBOL II on a mainframe to create a stack frame. The mainframe guys hadn't even heard of pointers, let alone realised that that was how the Linkage section worked, and COBOL II had just introduced pointer functionality so having 3 lines of code that solved their problem it seemed like magic to them.
train me
@kwccoin3115 Of course it was available in assembler but not COBOL. The linkage section works by pointers but it wasn't until COBOLII that you could use "set address of..." to use them yourself.
23:00 The :- in prolog is a logical implication from right to left, not left to right.
wow now it actually made more sense to me :) thanks
Oh, thank you! Now i understand the example at 31st minute
that’s right. “if A then B” means “A implies B”, not “B implies A”.
You missed the opportunity to say "vs. Infix Postfix"
hahahahaha
That was amazing
Infix Postfix vs.
Missed or avoided
@@markstevens7699 Good question
Long time ago, about twenty years, I had to solve the same problem with the same language (PROLOG) at the university. Many things have changed but I never thought to find the solution 20 years after.
After watching this I feel more comfortable venturing onto other languages. I was always afraid it would somehow confused me and lead me to forgetting my primary language but now I see it will only make me better if anything especially if it is another style of programming
This chick has mad skills. I have a whole new respect for prolog. Awesome talk.
If you are wondering what CS grads can do, this is one of the most prominent examples there is. They eat fundamental concepts for breakfast.
You must be from outside of California where jobs aren't in massive quantity for programmers. I see alot of programmers from CS degrees who simply dont have such basic concepts down. Sadly, I have known plenty of CS degree indivduals who sadly never took the time to do this and kind of just treated these classes like general ed (memorize and forget momentarily after test and semester)
@@theblackhundreds7124 true
@@theblackhundreds7124 Unfortunately, that is what at least 2-4 year schools I have had experience seem to do. They have a series of general criteria they want the students to learn, in a somewhat tight time-frame, and you test them for that. There is no emphasis on a deeper or better understanding, they leave that to the student (who usually doesn't feel the inclination to do too much extra with all the other large bits of course-work for other classes). I think how financial aid and government laid down dos-don'ts has gotten in the way for a lot of how these colleges operate, and not for the better.
This is what they SHOULD be able to do... But most schools are too busy running up the tab on their student loans and indoctrinating them into the liberal cult to actually teach them.
@The Illusionist Idk, sounds like a bad CS course to me.
I thoroughly enjoyed this talk. Some negative comments have been made but I don't think the intent of the talk was for you to follow every example completely and understand every detail. I think the intent is to show that different languages embody different mindsets when solving a problem. More importantly, you can learn new languages and think differently about solving problems and you should.
at 33:38 I lost my shit.
The dude that says ahh in understanding was so unexpected
I didn't hear it until you pointed it out
@@tech6hutch but I did! :D
This is huge.
Near the first 10 minutes I had been doing a search on CAR and CDR. I got pretty much everything but what they said the acronyms stood for.
When that guy went "ahhh" in the background much later, it shocked me out of my stupor (mind on tangents) and I heard the echo of what he was responding to. Only because of him did I get to go back and catch what she had just ran past. The object of my heart's desire.
I programmed in assembly in college so it was familiar. I just didn't expect it to be mentioned in...was it Racket or Prolog...
bruh you got that shit cranked up
Kind of appreciate C++ which doesnt force you to use a certain style and allows you to pick the best of each
Unbelievably good talk. As a junior MLE looking to learn more about programming fundamentals she crushed it.
Amazing talk! I totally didn't expect this. I didn't even know language like Prolog exists. Thank you. Learned a lot
I did know it existed, and I did know the philosophy behind how it's supposed to work, and I did try to learn/understand its basics some time ago... and failed.
This talk succeeded. :)
13:10 "Math is not interesting on its own" I died inside lmao! Great talk though
Really really well done. I watch a lot of videos like this and this one is a gem.
Indeed this is a true gem! Sadly most of videos which public sees are just “recipes” on language syntax or framework, whereas this presentation marvellously shows cross paradigm programming and unlocks your mind from being locked onto syntax. A++ ps. I also like Kevlin Henney s videos : he also looks at code in more profound and conceptual way rather than just syntax.
The syntax to abstract concept is the key.
Always hated math and scripts in highschool. Total 360 degree turn, obsessed with this stuff now, a beautiful and powerful art.
Already loving this talk.
After having an informal learning experience with code, it is very helpful in understanding the actual concepts of the language more in depth.
Reallys helps my understanding of C# and makes me more comfortable venturing into C++
My biggest takeaway is I need to avoid languages where the number of brackets required for the most basic thing exceeds the number of fingers I have 😅
The biggest takeaway for me was that I need to confront more languages like that
I think that what many people do not realize is that we *think* in the same way that LISP programming is done. It's actually IMPOSSIBLE to know that you are adding two numbers (in your head) without telling yourself that you're going to add two numbers. Therefore, the operator should come first. Even if someone grabs an arbitrary collection of numbers, and you tell them "okay, now add them", just by saying that have placed higher priority on the operator than you have on the operands.
interesting thought
I see your point but you do say: „a times b”, which to me sounds more like an infix way, rather than prefix („multiply a by b”). Obviously, whichever works for you :) - I just prefer to visualise infix operators as functions, eg. „add(a,b)” or „multiply(a,b)”. BTW, that looks quite similar to Excel formulas ;P
god i love this video.... but damn that lisp language is ugly
Wildly useful. Thanks Aja and Coding Tech.
Coding Tech did nothing but steal this video from some where else.
It's nice to meet you too, Bob. I hope you're having a nice day.
+Bob , there's something known as Creative Commons Attribution license.
@Bob It's called a curated list. And AFAIK Coding Tech never posts without authorization from the source if the license does not allow re-posting. And if you still want to piss all over the Cheerios you can go watch the original, it's linked to in the Description.
This is only from March, but I've referred to this video a number of times already. Great presentation!
Interesting talk. Logic programming was pretty weird but I'm tempted to try it out.
It is mostly used for parsers or theorem solvers or modeling of non-deterministic automatons. And to be honest, it isn't really good for anything else. It is inherently slow, requires huge amount of RAM and it obviously has a significant mental overhead.
Hobbyist with no formal comp sci background. Both func and logic look insanely fun to play around with. Def gonna try it out
Nice. That's the clearest explanation of Prolog I've seen.
This was a great talk. Kudos.
I was educated in machine code, assembly, basic, c, b, fortran, cobol, and cpp. I've sent things to space and made machines interact with humans in physical and direct mental ways.
I understand why we need higher level languages and object oriented programming, but the fundamental problem of the "task at hand" getting beyond the brain of the programmer remains.
The technological singularity is probably the moment we program the perfect programmer.
But we can't have the perfect programmer until we have the perfect language. And by language, I mean human language, not programming language. From that, all else should be a trivial exercise for the common reader. We need a new language, one that is perfect, without ambiguity.
It's just around the corner, we are almost there. This is scary, to be honest.
I sure hope the TS is our servant, and not our master.
Agriculture and domestication of animals was an order of magnitude advance for mankind. The industrial age was 2.5 orders of magnitude advance. The TS is an infinity power advance. We can't even imagine what the exponent is.
Godspeed, fellow humans. You've been given an incredible beyond belief blessing, if you can keep it in your control. Make sure you always control it!
xu do se bangu la lojban
@@Twisted_Logic I fully agree!
@maxmakman2682 I moved into a remote mountain homestead 1 year ago. That probably tells you everything.
Shit, what an interesting talk. I wish I was there.
But then again, I'm glad I'm not in New Orleans, lol.
Lol
This is one the best tech talks i have ever seen, thanks!
What a cool talk.
Makes me want to learn LISP.
People say that it abuses the characters '(' and ')'.
They might as well say there is no other valid flaw. It must be good!
Racket is designed from the ground up to teach functional programming. It is the rename of PLT Scheme, which is inseparable from the DrScheme IDE, which is as much a tutorial app as it is an environment. I assume you know the relationship between Scheme and LISP. Symbolics Inc. and TI and Xerox used to make LISP Machines in the 80s, whose OS was in LISP in the 80s. I believe LISP or LISP-like code was embedded in their CPUs. I used to daydream about getting my hands on one of those.
@@casperes0912 All those parentheses are part of the power of Lisp. Lisp's syntax is very uniform, making it easy to write macros that generate Lisp code. These macros make up a large part of the power of Lisp.
I think the "that's not really OO" might have started me down the road to finding out about smalltalk/squeak/pharo/SuperCollider.
Ultimate lecture!!! Ma'am you rock - reminded me of my CS307 course at UT.
( loved that course). Your lecture Bought back memories of my undergraduate studies at UTCS before I 'chickened' out to UTECE. ( pan to fire).
But UTCS forcing me into polyglotism made me better Computer Engineer.
Being in EDA requires you to be a polyglot.
Finally someone who could explain the weird origins of car and cdr.
I like her presentation style, he organization, and that she's a cat person.
Somehow ruby syntax draws me off. I know I shouldn't be so serious about syntax, but programming languages are primarily designed to aid humans.
I'm guessing there are a lot of Ruby programmers out there who either didn't go to college or didn't do so well there. It really explains a lot.
Wow this was a lot to take in. She's cool for this one
In lisp, "car" stands for "contents of address register" and "cdr" stands for "contents of decrement register."
From the register names in the IBM model 704 on which LISP was originally developed. Incidentally FORTRAN was also written for the 704 and it's instruction set weirdness accounts for the odd way memory was laid out in original FORTRAN and for the notorious 3-way branch.
@@davedaley9093 It's been so long that I had forgotten about those! Thanks for the trip down amnesia lane! ;)
This what I needed. Finally got something to comprehend these computer heavy terminologies.
i've watched so, soo many of these tech talks over the years + rarely ever do they contain ads that distract from your attention.. 10 mins in, and they've already played 3.. beyond excited for this talk but it's sad to see a favor of monetization over the integrity of the content/knowledge..
What a great talk, I know javascript but it gave me a lot of pain when I try to learn java and kotlin to build my first android app. Kind of miss the most fundamental different since I don't take any computer science degree.
This video is fantastic - brief, informative, and providing extra resources to go in depth.
I wrote an assembler for nand2tetris assembly. One of the coolest assignments I've had to do.
in the functional programming part. she taught the lisp how the Sicp teaches scheme, pretty reminiscent. loved it
Loved this talk
'Assembly... Very very limiting'
Have just remembered my study times when I had to solve problems in Post Machine language... Believe me, assembly is a very very syntax rich language ))
I'll never understand why people usually study a primary discipline with multiple languages. I mean, I get that each language is based on a more appropriate paradigm. But I think learning languages is a secondary thing, that you do based on your needs. You just have to understand in first place what means object oriented, functional, logic and procedural programming, not the languages themselves. That's why I teach Programming Paradigms in Python, which is "multi-paradigm" and easy to learn. Logic programming is the only paradigm we approach with other language, PROLOG.
I use assembly on a regular basis - now get off my lawn, kids!
These whippersnappers will never understand the glory of assembly with their new-age techno languages like C and FORTRAN
@@moonbeam2926 omg man, thanks :D top
@@moonbeam2926 Luxury... When I was a lad, I had to assemble my own binary before I could use it.
You aren't a real programmer unless you physically switch the transistors into the configuration of the code.
bro, I remember using stones and seashells to program. those were the good ol days.
This is such a clear-cut explanation. Awesome
It's really nice of her to use modern languages. That makes this video digestible for even the beginners.
Jokes aside, I find this really interesting but I'm obsessed with learning new languages, I would have assumed that most people would be turned off from the talk with such obscure languages used for the examples.
Brilliant talk: I am going to use it to introduce law students to ideas about computation and programming languages.
Thank you for uploading this video! It's really awesome and makes things very clear!
Before this talk, I was afraid of functional programing... now I'm also afraid of logical and procedural.
Procedural is just how any sane person solves tasks - top to bottom. It's just PURE procedural/functional without much abstractions is hard to wrap your brain around.
That was excellent! Wish I saw this before some of my college courses.
12:22 - 13:13, if you just think of (+ a b c d .....) as add(a, b, c, d......), it's not that bad.
Fantastic video! I definitely want to learn more about Prolog!
That Assembly code blew my mind as much as the Prolog code did. Way cool!
that was one shitty instruction set. it makes today's x86-64 instruction set look high level.
40:36 THIS.
I mean... thanks, the talk was great, I finally understood the basics of prolog, but... 40:36 THIS... Info about this book existing was such a huge, HUGE BEAUTIFUL GIFT for me... thank you...
Where were you when i took my first comp sci courses in the late 70s!! Wonderful talk. I am keen to learn Prolog now.
Excellent talk & pace, great stage presence, neat examples. Thanks very much 👍 Appreciated
Minor correction, LISP actually stands for "Lots of Irritating Superfluous Parentheses"
Seriously tho, great talk. I really enjoyed the breakdown.
Excellent stuff! Thanks for sharing!
The answer to the logic programming joke is 'Yes'. 'No' implies that there are no logic programmers who can screw in a lightbulb. 'Yes' implies that there is at least one answer to the query, and that the query itself was malformed in the first place, as the query *should* be something like, "?- logic_programmers_needed_to_change_lightbulb(X)."
i thought she said None
Query Delacroix ohhh thank you
EXCELLENT TALK ! ! ! REALLY HELPFUL ! ! !
THANK YOU AJA ! ! !
This is an excellent talk - well presented and fascinating. The speaker is great and has a nice sense of humour. If you're serious about programming you should definitely watch it - even if you've touched on the topics (see "The Red Willow" below) previously.
29:48 the prolog code is wrong. The recursive call in the second clause must have R instead of [F|R], because when you put F there, it allows you to "re-use" a coin that has already been deposited. The way it is here, ?- change(5, [2,1,1,1], C). gives you C=[2,2,1], so two 2s, although there was only a single 2 in the available coins.
By the way: this also works with 2 lines less:
change(0,_,[]).
change(S,[F|R],[F|X]) :- change(Q,R,X), S is F + Q.
change(S,[_|R],X) :- change(S,R,X).
(it is slower though, because it goes through all sub-lists and selects all that have the right sum).
She is really smart. Man oh man do I wish my brain was this powerful.
The question does not specifically ask for the area, in some contexts 1/4 of the circle may be shaded
I'm sorry but the choice for the functional programming language looks awful to me. Haskell is way more elegant and readable
And it is actually purely functional, as well.
Awesome, fell in love with prolog
I think I want to learn Prolog... ugh. Great presentation.
Thanks for this. It helped clear up a lot. Great presentation.
Object orientated programming is fundamentally flawed at its core - fite me irl if you disagree.
The problem with the object in OOP is that it's fundamentally only a good representation of a static map of the real world. In theory objects look like a good way to represent the world as we have a 2019 Mercedes G-Class (which is apparently the coolest new SUV according to Doug DeMuro in the sidebar) which is a type of SUV, which is a type of car, vehicle, etc. And we can have another class tree called a dealership (shop>utility building>building>etc) which perhaps has a list of vehicles and we can easily add that SUV in. That's great, when you freeze time and put everything in the world into this object mold you can pretty accurately get what is essentially a map.
The problem is these maps don't work in a changing world at all. Somewhere down the line the requirements are going to change, and let's say after 6 months the following changes have gradually been made:
The dealership also starts selling timeshares.
State law requires dealerships to keep a record of all of the dealerships their vehicles have ever been at.
We need to keep a list of employees who work at the dealership
We need to keep a list of which, when and where employees drove any vehicle (including their own - liability for hitting parked vehicle)
We've expanded and need to keep track of multiple dealerships - employees and vehicles can be moved between them
The new team wants to take a bunch of statistics - which customer test drove what, for how long
What you'll see is that unless you are willing to do basically entire ground-up rewrites (+ if you have an API then fuck 'em) for most of those features then you quickly end up:
Needing to access, e.g. the dealership class from everywhere. There's now probably references to it inside vehicles, employees, etc. In the original map we could use the traditional OO inheritance map to send messages between the dealership class and the vehicles, but now that has broken down. Instead of using the inheritance hierarchy we end up just sending the dealership class everywhere, and/or:
we end up doing something worse and creating a pseudo-global variable class. Maybe we don't do this when we suddenly need the dealership class reference everywhere, but in the later changes we end up needing references to employees everywhere as well. It's not easy for us to come up with a communication method without a significant rewrite, so instead what we may end up doing is creating some sort of class called "CompanyMetadata" and in it we just store a list of employees and dealerships, then we just pass a reference of this all over the place. And we've essentially created global variables. We're also feeling that chaos coming into the code as we start seeing the other problem with OO, which is we're creating classes for the sake of it.
We've also got another problem now, which is that the dealership is being referenced everywhere and it's becoming hard to manage the dealership itself. This is where we start feeling more chaos as we're about to start creating classes to deal with the dealership which will have stupid names like "manager", "controller" and other nouns. Now we've ended up with some sort of DealershipController class which has code to manage the dealership.
Now someone could come in here, and build a nice OOP way to rewrite all of the code, where everything communicates nicely in its hierarchy, and various classes can be decorated with things like employee, etc. And the model they come up with looks as brilliant as the original for the project did.
This is how so many projects tend to end up looking, and you can generally tell right away because you're jumping all over, up, down, left and right through a bunch of different files before you find the most basic functionality of the project.
I think this is where we get the big problem with OOP, which is that it's only good for describing a map of the world. It fails because in reality which objects end up needing to talk to one another has no relation to any sort of hierarchy and the more and more unpredictable interactions between objects we need to account for, the worse and worse the code generally seems to get.
Good example and fair point, but OPP is one style of several, as mentioned in the talks languages are a tool and some work much better than others. There are good ways to write code that should be requirements people don't do due to lack of time for project or laziness.
What type of language are you more of a fan of?
Yep, spaghetti code from hell. The world is NOT static. Nor is action and thing the same as oop generally aims for. The data and the code are separate things. Either should be changeable in detail without screwing up the usability of the other. You cannot do that very easily where the data must have it's own special handler basically baked into.
"Different problems match different solutions." - "No they don't here, have one example of something that creates problems in OOP, therefore it is com pletely useless, fight me!"
He doesnt mention any superior alternatives. Obvious flaw in your argument.
This is just a general problem in programming, one of the biggest strong point of OO is that it can deal with this. Good OO keeps coupling low and has high cohesion, this makes it easy to extend. Trust me this is the first question they will ask in an OO course, "now adapt your design to an extended situation". This is actually where OO really shines, you can reason about and extend very large and complex software. I would be curious why you think any other paradigm does this better.
Alternative title: Woman flexes for 40 minutes
The make-change function in Racket broke me, I mean the whole point of the function is to return a list with the change we're giving back to the customer, but the function she showed just keeps recursively calling itself with a decreased value of x, until eventually x reaches 0 and the function returns an empty list!
Please correct me if I'm wrong
nice lecture for quick review
This was the missing piece that helped me understand infix and prefix 💯
My brain is melting and I love it.
As a CS grad, I can tell you, we keep up with this shit only when there is no way around it. When one of our profs decided she wants us to use only Lisp in her class, everyone dropped it for something else
I think a bit misleading to show assembly for procedural. Java, C, C++, etc are all procedural but can also be functional -- they are hybrids and flexible.
I like procedural as the core for logic, functional for pieces in which breaking a problem down is intuitive, and Objects for fragile state that should be packaged together and guarded.
the one thing I'd like to criticize:
Assembly is not 'old school'; Assembly is, for the most cases where it is actually used, just a transcription of machine language. It will always be used to get the basis of a physical system running unless we get a major paradigm shift from all current architectures.
that instruction set she used is very old school. that looks like the early days of assembly language
very useful talk. she did a great job
Wow! Amazing speaker. I hope she does more
Thank you for sharing your knowledge and thought process :)
Very fundamental! Amazing talk!
Haskell is pure functional unlike Racket, but much shorter and does not need the sea of parenthesis. Same algorithm:
make_change 0 _ = []
make_change _ [] = error "Can't make change"
make_change x (d : ds)
| x < d = make_change x ds
| otherwise = d : make_change (x - d) (d : ds)
Fantastic upload!
Dang, prolog is hard! To the point where I was happy when I saw assembly. XD
OOR and Func programming looks ight. That other stuff is going to be a HARD pass for me.
Fantastic talk! I believe there might be an oversight tough? Assembly language is technically not procedural, right?. It's very low-level imperative, but it is not structured or procedural. Procedural implies subroutines / functions, which are not a feature of assembly languages. Assembly is a paradigm in itself, but it doesn't seem to follow procedural patterns natively? Or which procedural patterns did we see in the procedural examples? Loved everything about this video, but had this thought / nitpick / doubt.
prolog just blew my mind
I'm in love. That was amazing :)
Amazing talk.
PD: The allegory of the cave is not about abstraction.
Prolog seems super cool. It seems to work like my brain.
nice. I hope one day I can understand everything she is saying
omg prolog is awesome as is this girl :)
In the first example, wouldn’t it be more efficient to put a loop around each currency denomination, breaking out when the denomination is greater than the change owed, rather than having one really big loop that goes through a whole bunch of conditionals each time?