Lisp's main feature is homoiconicity, that being that all code is also data, and therefore lisp has incredibly powerful macros that look just as nice as regular code. I don't know of anything in Python that can achieve anything close to this. The rest of that sentiment was good but I think that's not a good comparison.
@@huistelefoon5375 )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) ^^ half of your lisp code
Maybe the weird Clang behaviour is because of undefined behaviour? If the function loops infinitely, it causes integer overflow, which is UB. Since the function always loops infinitely, calling it always invokes UB. In case of UB, the compiler can do whatever it wants, and it decided it wants to print garbage.
Weird clang behavior is because of they completely lost sense while chasing mythical "optimization". This just shows that compiler produces incorrect program. There are many other cases with it (and probably GCC) which even Linus commented.
Well, yeah, syntax is mostly inconsequential. However, I think with Lisp you're also seeing pretty much the AST which is very handy when writing macros. They can can do whatever manipulations to data/code and spit out code and with Lisp's syntax it's easier to see the structure you're manipulating / trying to achieve. Also Lisp's object model is nicer than Python's (multiple dispatch etc). Also, debugging/modifying a running program is sometimes really nice :) My main objection against Lisp is that it isn't statically typed so the compiler doesn't help me as much as I would like to :)
@@ribosomerocker Yup, I meant Common Lisp. I've been following a language called Carp which is quite interesting statically typed compiled language with Rust-inspired memory management.. but it's still quite early in the develpoment.
Well, static typing would require a static language. Lisp is dynamic. However, with just a few (DECLARE (TYPE ...)) forms, the compiler will not only warn you, but actually refuse to compile when it'll see type conflicts of variables. Common Lisp doesn't lack strict type enforcement, it's just optional.
When you have the program running, static analysis is not as important. You're running your code and getting instant feedback anyway. But yeah, sometimes types are nice anyway.
@@leo848 I'd argue it's a good thing, but it has its downsides, the obvious one being that it's not super straight-forward of what to do of course. But the upsides of it is that it forces you to really know what you're doing, which inevitably leads to better and cleaner code if you take coding seriously. There are so many python libraries and projects out there which's source code is pure nonsense because it's so poorly written that it's not even funny as a joke.
it's very useful for solving certain kinds of problems. For me I found that once you start trying to do optimizations to improve performance, you can find yourself bending over backward. Caching is really hard, for example.
I want to make a C compiler that makes you solve a cryptic riddle before it compiles anything. That way I could advertise C as being a language that makes you think outside the box.
An interesting thought about the 'rec' keyword in OCaml and why you need to add it to the beginning of recursive function definitions: I know that in some functional languages, especially Haskell, the compiled binary of the program includes a runtime which is basically just a lambda calculus interpreter. In the lambda calculus, you can't actually bind functions to names, so that means that before you evaluate an expression, every name needs to be replaced with its corresponding definition before evaluation can begin. There arises a problem when you try to do this with a recursive definition, however, since every time you replace the name of the recursive function with its body, you end up with another copy of it which then needs to be replaced again, etc. There is a way to get around it using the Y combinator, but the recursive function needs to take another argument which would stand in for the recursive call in its body. In short, the rec keyword may be syntactic sugar for that process. Just a thought though.
youtuber xah lee would disagree: to him syntax is the most important thing. I've heard that progress in calculus pretty much stalled because of the awkward newtonian notation f' f" etc. until the german started using the df/dx notation, not sure it's true, but syntax does make certain patterns or semantics more visible/exploitable.
I found this funny > Complains about people who care about syntax, because it's superficial and not important at all in a language. > Obviously frustrated with the syntactic choices in OCaml for comments, lists and tuples. ;P Who doesn't care at least a little about syntax? It is the interface between the semantics and our reading eyes. It should be as transparent as possible; if you can't avoid thinking about it, it's maybe bad in some way (after you have learned it, of course). A couple things about tail call optimizations (TCO) that were not mentioned in the video: Tail calls can be optimized also across functions, not only in self recursive ones. In f(x)=g(x) the call to g is in tail position, so it can be optimized in the same way (the stack frame for f is not needed when g returns). Another thing is that TCO can be a problem for analyzing a stack trace, something to take into account. It eliminates part of the stack context, so when you are trying to understand a bug (after the fact), you might not know how you effectively got there. BTW, I think mrbotka being a bot is no excuse for it being impolite. Shame on it >:(
I usually ignore majority of the comments, but your take regarding my position on the syntax was just beyond imagination stupid so I had to answer. > Complains about people who care **ONLY** about syntax I'm not saying that there are no problems with syntaxes. My frustration is the people who keep discussing only syntax despite having way more important problems (a.k.a. bikeshedding).
@@TsodingDaily Look, I had no bad intentions with my comment. If it reads like I'm trying to make fun or something, I apologize. I think your point about people bike-shedding syntax is sufficiently clear, don't worry (if not from this, at least from other videos for sure). I was just putting together two things that you said, because the *contrast* made it funny (which is probably a matter of perspective).
Some libraries in OCaml utilize the OOP functionality to manage the state of UI widgets. I've used Lamda-term for TUI projects and it is far easier to use their widget classes than defining your own draw functions for each widget especially for interacting with them later. Both work fine though so it's just personal preference. Probably just skill issues on my part tbh
Hey nice video, just a note on the stack-pushing behavior of a function call, the first couples of arguments are passed into registers first (regular for int, xmm for float etc.) and if you have extra it'll be pushed onto the stack. In your case I don't think the int x will show up on stack, it'll be passed using the %rcx register :) (the return is given in a register also so no stack space needed) So in the end this recursion will just show up on the stack as a bunch of ret addresses, with optimization as you said I guess it'll just be one single ret on the stack. Actually a lot more efficient isn't it?
Funny thing, fairly recently linux added the option to disable #! or make it a module . So in addition to a system that probably won't boot, your ocamlc programs won't run.
since every list you tested the length functions with was incrementing from 1, the best solution would have been to just reuse the last-element function. Less bloat!
Golang is fast and newbie friendly! though it doesn't have generics, unnullable pointers and lots of useful modern features. But I think sometimes it's easier to read (and code) 50 lines of if/elses than 10 lines of flatmaps juggling monad transformers and converting between different types
@@john.dough. sorry for the 8th month too late reply, but "generics" in go is an half-assed implementation of Rust's traits in order to get an half-assed generic interface for functions.
No, Lisp is not basically python with different syntax. By that logic, every other c -like language is basically Lisp. Lisp has expressions, python has statements. Expressions > statemets, because of better REPL ergonomics. Also Lisp is homoiconic and this allows you to have the best macro system. Also, not all lisps are the same, Clojure is a totally different beast than Python.
One imperative, dynamically-typed garbage-collected language with bolted-on functional programming and runtime type information vs another imperative, dynamically-typed garbage-collected language with bolted-on functional programming and runtime type information... A lot of popular languages today are quasi-Lisps - and if you ignore the static vs dynamic typing difference, which only affects how strict your compiler is, then almost all of them are. Code in Common Lisp, Scheme, Python, Java, Ruby, C#, Javascript etc. is pretty similar structure-wise. You have references to heap-allocated objects and you toss them around, imperatively, without worrying about cleaning them up. You want something different from all of those Lisps and quasi-Lisps? There's Haskell, C, APL, Forth, COBOL, Erlang.
@@vytah Clojure is a functional lisp, it does not have "bolted-on functional programming", it's functional by design. Immutable data structures via persistent collections, support for higher order functions, functions as values... I don't really care for your definition of quasy-lisps. The main difference with lisps and your quasi-lisps is that lisps actually have s-expressions, while your quasi-lisps don't and this is the big difference. This is what is the reason of great repl experience. You can never have as great repl experience using your quasi-lisps.
@@vytah What you say is partially true but in terms of syntax and metaprogramming they are very different. Python parses into a quite complicated AST because it has to differentiate between many kinds of expressions and statements. The power of lisp is that you learn how lists are notated and then using that notation you write code directly in the internal representation of the AST, wich is much simpler than pythons because it basically consists of symbols, literals and expressions and nothing else. This makes metaprogramming simply superior in lisp, although in other aspects you are right it isn't tremendously different.
My best friend works for Jane street and I work @ another one of the market makers. Lemme assure you that you are smart enough to work work at these companies. I think you just don’t want to cause it doesn’t appeal to your creativity 😏
37:30 Yeah, at this point it's clear to me I do not like OCAML. It started to annoy me with the already flipped relation with option, where the type was 'a option and the value Some x, and continued with the traditional parameter definition with Haskell style argument passing, but now this shit with tuples and their types. Dont get me wrong, while it's slightly annoying, I tend not to be a person that dislikes a language when it's just different. But there's different but of equal sense, like the way you pass arguments in HASKELL, and there's nonsensical different. And, at least from what I see, Ocaml chose the nonsensical route. Why would you break the Symmetry between so many elements of the language apparently by purpose? At least at this point I can't see a legitimate reason to do that shit. EDIT: Oh, and I could not agree less with you on your comment about Rust. Rust HAS A REASON to be different. Maybe I'm not fair to Ocaml, I'm open for proper explanations, but I do not see it right now. EDIT 2: Watching on I see I was wrong about the parameter/argument symmetry break. But continuing to watch Ive yet to see a good reason to end statements with TWO semicolons. Also, how could I forget about that, the head :: rest match, when matching just one element uses [x] and empty [].
You can match a one element list with x::[]. And I think the two semi colons are because of it supporting Imperative Programming, where you separate the statements by a single semicolon. Yes, there is a single semi colon in OCaml, and has a different meaning than the double semi colon. You don’t actually need the double semi colons in you source. They’re there to just make the interpreter happy, afaik. And the standards discourage the use of them.
She bangs are used by all languages that can produce scripts, interpreted or compiled. Python does it, Kotlin does it, D does it. The she bang is just telling the shell what to run it with.
Here's the algorithm for solving problems with tail recursion: step 1: solve the problem using for loop step 2: transform the for loop into recursive function.
Can someone explain to me why all of these are basically O(N) solutions of O(1) problems. I get it that optimization is not the main thing here, but if you can do something in constant time why iterate over whole thing? And if performance really doesn't matter at all, why are you trying to make code more performant using tail recursion by sacrificing readability with that function inside a function? Why we can't just do something like this to get last element of the list: match List.length xs with | 0 -> None | n -> Some (List.nth xs (n-1)) knowing lists length and indexing in constant time are very basic things, why someone would even try to solve problems without them?
I just don't get it. I have been programming in C/C++ for close to 20 years, before that in Pascal, Delphi, Java... but I never understood why anyone voluntarily goes through the migrain-inducing ordeal of functional programming. It just seems so far away from anything real-world...To me, it just seems like a totally wrong and unintuitive attempt to solve problems you otherwise wouldn't have.
You did a great job explaining this language. I have never seen it before. Unfortunately, it is the biggest piece of crap I have ever seen. Why would anyone use this when we have the programming masterpiece that is C++ and the high-level, convenient language that is python??
tsoding: "Let's see if I remember any OCaml from 8 years ago"
*proceeds explaining me all the syntax of OCaml*
Nice! I've wanted to learn OCaml for a long time now, this is the perfect opportunity to follow along (however slowly) and get some problems solved :D
Lisp's main feature is homoiconicity, that being that all code is also data, and therefore lisp has incredibly powerful macros that look just as nice as regular code. I don't know of anything in Python that can achieve anything close to this. The rest of that sentiment was good but I think that's not a good comparison.
the problem is that "regular code" in Lisp looks like garbage anyway, hard to screw that up even more than it is
@@dwightk.schrute8696what makes you say that?
@@huistelefoon5375 ))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
^^ half of your lisp code
(what
(makes
(you
(say
(that)))))
@@huistelefoon5375
@@dwightk.schrute8696 I don't think Lisp code looks like garbage.
Maybe the weird Clang behaviour is because of undefined behaviour? If the function loops infinitely, it causes integer overflow, which is UB. Since the function always loops infinitely, calling it always invokes UB. In case of UB, the compiler can do whatever it wants, and it decided it wants to print garbage.
Weird clang behavior is because of they completely lost sense while chasing mythical "optimization". This just shows that compiler produces incorrect program. There are many other cases with it (and probably GCC) which even Linus commented.
not a bad argument
Well, yeah, syntax is mostly inconsequential. However, I think with Lisp you're also seeing pretty much the AST which is very handy when writing macros. They can can do whatever manipulations to data/code and spit out code and with Lisp's syntax it's easier to see the structure you're manipulating / trying to achieve. Also Lisp's object model is nicer than Python's (multiple dispatch etc). Also, debugging/modifying a running program is sometimes really nice :) My main objection against Lisp is that it isn't statically typed so the compiler doesn't help me as much as I would like to :)
Some lisps are statically typed
@@ribosomerocker Yup, I meant Common Lisp. I've been following a language called Carp which is quite interesting statically typed compiled language with Rust-inspired memory management.. but it's still quite early in the develpoment.
Well, static typing would require a static language. Lisp is dynamic. However, with just a few (DECLARE (TYPE ...)) forms, the compiler will not only warn you, but actually refuse to compile when it'll see type conflicts of variables. Common Lisp doesn't lack strict type enforcement, it's just optional.
When you have the program running, static analysis is not as important. You're running your code and getting instant feedback anyway. But yeah, sometimes types are nice anyway.
You are an exceptionally good teacher, you actually got me to understand tail call optimization 🤩
This man should do APL
oh, he will love it
After using APL:
This man and its viewers looses their sanity.
@@rallokkcaz well, you can use FFI to call C-functions.. (at least BQN can). Shouldn't be too hard to open sockets :)
ew apl
This video also captures a good part of explanations and recipes from HtDP, which even more agrees with Tsoding's rant on syntax/semantics
Loved Haskell, functional programming truly requires you to think outside of the box
Would you think of that as a good thing? I think a language should be as straightforward as possible and not require you to "think outside the box".
@@leo848 I guess it depends if thinking outside the box results in more elegant code, or over-engineering...
@@leo848 I'd argue it's a good thing, but it has its downsides, the obvious one being that it's not super straight-forward of what to do of course. But the upsides of it is that it forces you to really know what you're doing, which inevitably leads to better and cleaner code if you take coding seriously. There are so many python libraries and projects out there which's source code is pure nonsense because it's so poorly written that it's not even funny as a joke.
it's very useful for solving certain kinds of problems. For me I found that once you start trying to do optimizations to improve performance, you can find yourself bending over backward. Caching is really hard, for example.
I want to make a C compiler that makes you solve a cryptic riddle before it compiles anything. That way I could advertise C as being a language that makes you think outside the box.
1:24:40 clang is so good it calculated the value of infinity!
Really good one! Thanks a lot and keep doing more stuff like this one please.
An interesting thought about the 'rec' keyword in OCaml and why you need to add it to the beginning of recursive function definitions:
I know that in some functional languages, especially Haskell, the compiled binary of the program includes a runtime which is basically just a lambda calculus interpreter. In the lambda calculus, you can't actually bind functions to names, so that means that before you evaluate an expression, every name needs to be replaced with its corresponding definition before evaluation can begin. There arises a problem when you try to do this with a recursive definition, however, since every time you replace the name of the recursive function with its body, you end up with another copy of it which then needs to be replaced again, etc.
There is a way to get around it using the Y combinator, but the recursive function needs to take another argument which would stand in for the recursive call in its body.
In short, the rec keyword may be syntactic sugar for that process. Just a thought though.
The best explanation of recursion on the internet.
the thing with tuples without parentheses is also applicable to python in some cases, so yeah, basically the same language
youtuber xah lee would disagree: to him syntax is the most important thing. I've heard that progress in calculus pretty much stalled because of the awkward newtonian notation f' f" etc. until the german started using the df/dx notation, not sure it's true, but syntax does make certain patterns or semantics more visible/exploitable.
Need to make a video on how you use the terminal this way 🤤 which multiplexer?.. The hole setup
I found this funny
> Complains about people who care about syntax, because it's superficial and not important at all in a language.
> Obviously frustrated with the syntactic choices in OCaml for comments, lists and tuples. ;P
Who doesn't care at least a little about syntax? It is the interface between the semantics and our reading eyes. It should be as transparent as possible; if you can't avoid thinking about it, it's maybe bad in some way (after you have learned it, of course).
A couple things about tail call optimizations (TCO) that were not mentioned in the video:
Tail calls can be optimized also across functions, not only in self recursive ones. In
f(x)=g(x)
the call to g is in tail position, so it can be optimized in the same way (the stack frame for f is not needed when g returns).
Another thing is that TCO can be a problem for analyzing a stack trace, something to take into account. It eliminates part of the stack context, so when you are trying to understand a bug (after the fact), you might not know how you effectively got there.
BTW, I think mrbotka being a bot is no excuse for it being impolite. Shame on it >:(
I usually ignore majority of the comments, but your take regarding my position on the syntax was just beyond imagination stupid so I had to answer.
> Complains about people who care **ONLY** about syntax
I'm not saying that there are no problems with syntaxes. My frustration is the people who keep discussing only syntax despite having way more important problems (a.k.a. bikeshedding).
@@TsodingDaily
Look, I had no bad intentions with my comment. If it reads like I'm trying to make fun or something, I apologize.
I think your point about people bike-shedding syntax is sufficiently clear, don't worry (if not from this, at least from other videos for sure).
I was just putting together two things that you said, because the *contrast* made it funny (which is probably a matter of perspective).
@@frechjo Oh, I see! It's hard for me to read the intentions through the text! I'm sorry for my reaction as well. No offense taken either.
38:20 tsoding is probably on thousands levels of irony
Some libraries in OCaml utilize the OOP functionality to manage the state of UI widgets. I've used Lamda-term for TUI projects and it is far easier to use their widget classes than defining your own draw functions for each widget especially for interacting with them later. Both work fine though so it's just personal preference. Probably just skill issues on my part tbh
Hey nice video, just a note on the stack-pushing behavior of a function call, the first couples of arguments are passed into registers first (regular for int, xmm for float etc.) and if you have extra it'll be pushed onto the stack. In your case I don't think the int x will show up on stack, it'll be passed using the %rcx register :) (the return is given in a register also so no stack space needed)
So in the end this recursion will just show up on the stack as a bunch of ret addresses, with optimization as you said I guess it'll just be one single ret on the stack. Actually a lot more efficient isn't it?
By what OCaml is better than Rust? generics, matching, optional...
I see only a more weird syntax of OCaml.
Funny thing, fairly recently linux added the option to disable #! or make it a module . So in addition to a system that probably won't boot, your ocamlc programs won't run.
Baseless claim that Common Lisp has the same semantics as Python.
since every list you tested the length functions with was incrementing from 1, the best solution would have been to just reuse the last-element function. Less bloat!
Understood the tail call on first reading .😀😃
Golang is fast and newbie friendly! though it doesn't have generics, unnullable pointers and lots of useful modern features. But I think sometimes it's easier to read (and code) 50 lines of if/elses than 10 lines of flatmaps juggling monad transformers and converting between different types
also, converting between different types? I dont think you really wanna do that in languages like haskell
I dont think so, Golang maybe is fast, but not newbie friendly, i bet
It got generics! (finally)
@@john.dough. sorry for the 8th month too late reply, but "generics" in go is an half-assed implementation of Rust's traits in order to get an half-assed generic interface for functions.
@@vladlu6362 two half asses make a whole ass 😂
No, Lisp is not basically python with different syntax. By that logic, every other c -like language is basically Lisp. Lisp has expressions, python has statements. Expressions > statemets, because of better REPL ergonomics. Also Lisp is homoiconic and this allows you to have the best macro system. Also, not all lisps are the same, Clojure is a totally different beast than Python.
One imperative, dynamically-typed garbage-collected language with bolted-on functional programming and runtime type information vs another imperative, dynamically-typed garbage-collected language with bolted-on functional programming and runtime type information... A lot of popular languages today are quasi-Lisps - and if you ignore the static vs dynamic typing difference, which only affects how strict your compiler is, then almost all of them are. Code in Common Lisp, Scheme, Python, Java, Ruby, C#, Javascript etc. is pretty similar structure-wise. You have references to heap-allocated objects and you toss them around, imperatively, without worrying about cleaning them up.
You want something different from all of those Lisps and quasi-Lisps? There's Haskell, C, APL, Forth, COBOL, Erlang.
@@vytah Clojure is a functional lisp, it does not have "bolted-on functional programming", it's functional by design. Immutable data structures via persistent collections, support for higher order functions, functions as values... I don't really care for your definition of quasy-lisps. The main difference with lisps and your quasi-lisps is that lisps actually have s-expressions, while your quasi-lisps don't and this is the big difference. This is what is the reason of great repl experience. You can never have as great repl experience using your quasi-lisps.
Its the opposite. Python list comprehension is just a bad sort of Lisp
@@vytah What you say is partially true but in terms of syntax and metaprogramming they are very different.
Python parses into a quite complicated AST because it has to differentiate between many kinds of expressions and statements. The power of lisp is that you learn how lists are notated and then using that notation you write code directly in the internal representation of the AST, wich is much simpler than pythons because it basically consists of symbols, literals and expressions and nothing else. This makes metaprogramming simply superior in lisp, although in other aspects you are right it isn't tremendously different.
Nice clarification on tuples. I was wondering about the semicolon.
holy shit thank u for rlwrap
My best friend works for Jane street and I work @ another one of the market makers. Lemme assure you that you are smart enough to work work at these companies.
I think you just don’t want to cause it doesn’t appeal to your creativity 😏
came looking for this comment, if this guy is "too dumb" to work somewhere we are all fucked haha
btw, amazing channel!
@@stas4112 thank you!
Pretty sure he was joking. Just a weird flex
Why I was thinking he was talking about Apache Camel :D
OOP came from a hype. There is a guy on youtube that made several videos titled like "OOP is garbage" and similar LOL
What do you use tmux for? How can it be useful for programming?
37:30 Yeah, at this point it's clear to me I do not like OCAML.
It started to annoy me with the already flipped relation with option, where the type was 'a option and the value Some x, and continued with the traditional parameter definition with Haskell style argument passing, but now this shit with tuples and their types.
Dont get me wrong, while it's slightly annoying, I tend not to be a person that dislikes a language when it's just different.
But there's different but of equal sense, like the way you pass arguments in HASKELL, and there's nonsensical different. And, at least from what I see, Ocaml chose the nonsensical route.
Why would you break the Symmetry between so many elements of the language apparently by purpose? At least at this point I can't see a legitimate reason to do that shit.
EDIT: Oh, and I could not agree less with you on your comment about Rust. Rust HAS A REASON to be different. Maybe I'm not fair to Ocaml, I'm open for proper explanations, but I do not see it right now.
EDIT 2: Watching on I see I was wrong about the parameter/argument symmetry break. But continuing to watch Ive yet to see a good reason to end statements with TWO semicolons. Also, how could I forget about that, the head :: rest match, when matching just one element uses [x] and empty [].
You can match a one element list with x::[]. And I think the two semi colons are because of it supporting Imperative Programming, where you separate the statements by a single semicolon. Yes, there is a single semi colon in OCaml, and has a different meaning than the double semi colon. You don’t actually need the double semi colons in you source. They’re there to just make the interpreter happy, afaik. And the standards discourage the use of them.
Ugh, the pattern matching you mentioned works exactly like it does in Haskell, which you supposedly like.
Has anybody else noticed "Porn folder" at the bottom of his edtior xd
8:30 - The bike shed will be HOT PINK
Tsoding : A beginner friendly and fast language doesn't exist. Meanwhile Go :
Not being very very very very slow doesn't make you fast.
Go is not fast.
What's this colorscheme? It's beautiful!
gruber-darker
@@pushqrdx thank you!
I never know if Alexey messes up the pronunciation of "raise" on purpose or not, and at this point, I'm too afraid to ask XD
A good soul who would suggest an OCaml solution to problem 99?
"Common Lisp is straight up Python with s-expressions".
hot take
hmm afaik, .run file in linux also had shebang with byte-code content.
cmiiw
APL/DYALOG review
Unshar does that shebang trick, but I think with base64
Non linear curve of difficulty :)
Why are you explicitly specifying types? Why not left that stuff to the compiler?
ocaml is a beast.
Any thoguths on Coq?
She bangs are used by all languages that can produce scripts, interpreted or compiled. Python does it, Kotlin does it, D does it. The she bang is just telling the shell what to run it with.
I can't find the Tsoding discord channel for some reason. Anyone got an invite link?
Here's the algorithm for solving problems with tail recursion:
step 1: solve the problem using for loop
step 2: transform the for loop into recursive function.
@Mohammed Shahid Tail recursion is when the recursive call is the last instruction of the recursive function.
Bytecode exists in js
another "creative" solution to the length problem is to map all elements of the list to 1 and then sum all the 1s hahah
Wait a second. So how old is he???
i believe he's 69
Either 23 or 54
@@pushqrdx Nice
32
7:41 I REMEMBA NINETEEN...
Hey Buddy, please include screen key , will be helpful as you type commands
Thank you so much you save my exams. 🙂🙏🙏
51:20 i am LOLing 😂😂😂
Ocamlator
Name of editor?
-vscode- Emacs
Clion
vim or neovim
It's emacs
I have 99 problems but OCaml aint one
Everyone is pinkt
99 problems but Haskel aint one
acm t-shirt!
Now Tsording stopped using fucking, crap etc.
mrbotka not obviously a bot lmao
Can someone explain to me why all of these are basically O(N) solutions of O(1) problems. I get it that optimization is not the main thing here, but if you can do something in constant time why iterate over whole thing? And if performance really doesn't matter at all, why are you trying to make code more performant using tail recursion by sacrificing readability with that function inside a function?
Why we can't just do something like this to get last element of the list:
match List.length xs with
| 0 -> None
| n -> Some (List.nth xs (n-1))
knowing lists length and indexing in constant time are very basic things, why someone would even try to solve problems without them?
But List.nth is also O(n) github.com/ocaml/ocaml/blob/7997b65fdc87909e83f497da866763174699936e/stdlib/list.ml#L37-L43
@@TsodingDaily oh, so these lists are linked lists. Therefore you can take head and tail so easily. Now that's makes a lot of sense
стопэ, ты может скалу ещё не уважаешь?
Second
I just don't get it. I have been programming in C/C++ for close to 20 years, before that in Pascal, Delphi, Java... but I never understood why anyone voluntarily goes through the migrain-inducing ordeal of functional programming. It just seems so far away from anything real-world...To me, it just seems like a totally wrong and unintuitive attempt to solve problems you otherwise wouldn't have.
You did a great job explaining this language. I have never seen it before. Unfortunately, it is the biggest piece of crap I have ever seen. Why would anyone use this when we have the programming masterpiece that is C++ and the high-level, convenient language that is python??
Calling C++ (the most horrifyingly garbage language ever deviced) a programming masterpiece is wild.
@@marcossidoruk8033 you apparently just don't understand modern c++ and are confusing it with C plus classes.
Super interesting once again!