Good work. List comprehensions are great. One opportunity for enhancement is getting the list comprehension to generate more complex data. In all of your examples, a single value was generated. In the largest-palindrome problem, you found the largest one but not the factors. (You weren't required to, but it would be interesting.) (for [n1 (range 100 1000), n2 (range 100 1000) :let [product (* n1 n2)] :when (palindrome? product) { :factors [n1 n2] :product product })
Very nicely done. Clojure + Light Table = Screencasting Nirvana. You've got a great speaking voice, and a really organized approach that makes this screencast really shine. Please continue these, covering other areas of Clojure!
Thanks for the complement. I do have more screencasts planned - I just need to find the time to finish the preparation and then record them. Stay tuned!
You have some excellent clojure tutorials! In fact I wish you had more, i've learned and retained more useful information about clojure from your channel than any other resource. I'd be looking forward to any more you have in the future :D
Great video. I'm coming to Clojure from Java. (I'm sorry).... I'm always amazed at how much easier it often is to do things in Clojure or a Lisp. Having used List and Set comprehensions in Python to describe Set Theory, I was sure that there would be something comparable in Clojure. Thank you for the lecture. And it also helped me understand Clojure better. Looking through your other stuff on Clojure, I will be reviewing them, also.
Thanks for the feedback, and I agree with you that it would have been good to have at least one example with a more complicated evaluated expression. Your extension of my example is a nice way to show that in action.
It's a very nice feature of map that you can pass it more than one collection. But you'll notice that your code-snippet doesn't produce the same output as the list comprehension I used in the screencast. That's because list comprehension evaluates the expression against every combination of the input lists (which is why I used nested maps to duplicate that behaviour).
Thank you for trying to explain the use of short names. I still think that they reduce readability and increase cognitive load, but I agree with you that they draw less attention. Why do you say that nothing about this algorithm is specific to three-digit numbers? The requirements request the palindromic product of two three-digit numbers, and (range 100 1000) generates all the three-digit numbers. Isn't it useful to indicate this in the code by choosing a more descriptive name than 'n1'?
Thanks! I do have some more advanced topic ideas in my backlog, but as you guessed I'm struggling to find time to prepare and record them. Hopefully I'll manage to find some time soon.
One thing I've noticed with a lot of people's Clojure code, including yours, is the tendency to prefer one-letter argument and var names. For me, a large part of good coding is good naming. I regularly spend minutes thinking about just one function or argument name; and in my opinion, that's time well spent. Perhaps you can help me to understand - in an age with high-resolution screens and code-completion, why would 'n' be a preferable name to 'number', or 'n1' to 'three-digit-number-1'?
Fantastic video. Any chance you might put together a video on clojure/core.match -- Clojure's pattern matching library ? I'm coming to Clojure from Haskell and that would close the loop for me (and perhaps others), as list comprehensions, property-based (i.e., generative) testing and pattern-matching are important features of Haskell.
Hi Jason, I'm glad you enjoyed the video. I don't have any experience with core.match, but it's something that I'd like to look into. Perhaps it could be a screencast subject for the future - thanks for the suggestion!
Short variable names induce cognitive load when you ever have to remind yourself of what they mean ("s" for strings and "n" for numbers is conventional and handy, though). However, longer variable names can also induce cognitive load the same way a sentence does when you encounter a long consecutive chain of adjectives or whimsical phrases, each word mentally distancing you from the context in which it all applies.
The default theme in LT has coloured brackets for Clojure code, but I'm actually using my own custom theme (which you can find a link to in the description). Can you explain what you mean by "the slurp/barf functionality"?
The problem description is specific to three-digit numbers, but the algorithm isn't. The same code can handle four digit numbers or anything else (you just change the values in the range). The sensible thing to do with this code is put it in a function, with the start and end numbers as parameters. (Of course, that's not the purpose of your video.) I certainly agree that a lot of code out there is made harder to understand because of obsessively short names.
Sure. Commonly-used constructs have short names so they stay out of the way and avoid clutter. Constructs that are not common, or not easily understood, or are very specific, deserve a longer name to draw attention to themselves. Numbers are so common that they get the name 'n'. Likewise strings 's'. Nothing about this algorithm is specific to *three digit* numbers, so n1 and n2 are sufficient. I agree that good naming is very important (and quite difficult!), but sometimes short is best.
I've been seeking something equivalent to the "parallel stepping" that one can do in common-lisp's LOOP macro. I'd imagine in some cases one can achieve similar results using Clojure's for/:let but is there an easier and more general approach? Example: (loop for x from 0 to 9 for y from 9 downto 0 collect (cons x y)) => ((0 . 9) (1 . 8) (2 . 7) (3 . 6) (4 . 5) (5 . 4) (6 . 3) (7 . 2) (8 . 1) (9 . 0)) In this case clearly a clojure for/:when would be inefficient as it would also generate all of the unneeded intermediate values. Also, please excuse the CL centric use of CONS in the above example.
I know this is from 4 years ago, but In functional programming, this is referred to as a zip. stackoverflow.com/questions/2588227/is-there-an-equivalent-for-the-zip-function-in-clojure-core-or-contrib So if you do (map vector a b) where a and b are vectors, you get a list in the form ((vector a1 b1) ... (vector an bn)) where ai, bi
man you have incredible programming and didactic skills! Thanks for the amazing work, finally i could understand that. And dont let to care of you kid to work, im also a father, trust me i know what im talking about hahaahah. Congrats!
I think there might be a couple of problems with your line of reasoning: firstly, range always "works on arbitrary ranges of numbers", so does that mean that we'd never give any ranged var a specific name to indicate its purpose? Secondly, pulling domain language out of the code and into comments or docstrings goes in the opposite direction of self-documenting code. It stops the code speaking for itself. And what happens if someone updates the code, but forgets to update the descriptive comment?
Thanks for putting this video knowledge together. Appreciate the clarity in your thoughts. In making this video more 'readable' I have a few suggestions. - Make the text larger on the screen as even after making it full screen is still a bit hard to see easily. - Put the text you're typing into the middle of the screen, rather than at the bottom unless of course you have some context you're trying to keep up there - Black fonts on white screen is much easier to read than white text on black great content!
I think "three-digit-number-1" introduces too much label specificity to an implementation that works on arbitrary ranges of numbers. We're already a stone's throw from generalizing `palindromes` into a function that takes the range bounds as arguments. So the fact that we only care about three digit numbers is a detail we can remind our self about at the call site. `;; Finds palindrome products for three digit numbers.` And even if it wasn't generalized, I'd just put it in the doctstring.
Sorry about the formatting of the code in my other comment. See the following gist ffor nicely commented and tested code. gist . github . com / anonymous / 6723019
Good work. List comprehensions are great.
One opportunity for enhancement is getting the list comprehension to generate more complex data. In all of your examples, a single value was generated.
In the largest-palindrome problem, you found the largest one but not the factors. (You weren't required to, but it would be interesting.)
(for [n1 (range 100 1000), n2 (range 100 1000)
:let [product (* n1 n2)]
:when (palindrome? product)
{ :factors [n1 n2] :product product })
Very nicely done. Clojure + Light Table = Screencasting Nirvana. You've got a great speaking voice, and a really organized approach that makes this screencast really shine. Please continue these, covering other areas of Clojure!
Excellent videos, thank you. They really sum up some Clojure concepts in a very friendly, practical way.
Thanks for the complement. I do have more screencasts planned - I just need to find the time to finish the preparation and then record them. Stay tuned!
You have some excellent clojure tutorials! In fact I wish you had more, i've learned and retained more useful information about clojure from your channel than any other resource. I'd be looking forward to any more you have in the future :D
I heard your voice and seeing you are using LT and already push the like button.
Thanks so much for sharing your insights with us.
Great video. I'm coming to Clojure from Java. (I'm sorry).... I'm always amazed at how much easier it often is to do things in Clojure or a Lisp. Having used List and Set comprehensions in Python to describe Set Theory, I was sure that there would be something comparable in Clojure. Thank you for the lecture. And it also helped me understand Clojure better. Looking through your other stuff on Clojure, I will be reviewing them, also.
Thanks, and I hope you find some of my other videos useful too!
Thanks for the feedback, and I agree with you that it would have been good to have at least one example with a more complicated evaluated expression. Your extension of my example is a nice way to show that in action.
It's a very nice feature of map that you can pass it more than one collection.
But you'll notice that your code-snippet doesn't produce the same output as the list comprehension I used in the screencast. That's because list comprehension evaluates the expression against every combination of the input lists (which is why I used nested maps to duplicate that behaviour).
Thank you for trying to explain the use of short names. I still think that they reduce readability and increase cognitive load, but I agree with you that they draw less attention.
Why do you say that nothing about this algorithm is specific to three-digit numbers? The requirements request the palindromic product of two three-digit numbers, and (range 100 1000) generates all the three-digit numbers. Isn't it useful to indicate this in the code by choosing a more descriptive name than 'n1'?
Great presentation, love your videos.
You have a talent for this - I hope you find time to walk through some more advanced topics before too long...
Thanks! I do have some more advanced topic ideas in my backlog, but as you guessed I'm struggling to find time to prepare and record them. Hopefully I'll manage to find some time soon.
Great video! How did you get LT to do the colors on the brackets and the slurp/barf functionality?
One thing I've noticed with a lot of people's Clojure code, including yours, is the tendency to prefer one-letter argument and var names.
For me, a large part of good coding is good naming. I regularly spend minutes thinking about just one function or argument name; and in my opinion, that's time well spent.
Perhaps you can help me to understand - in an age with high-resolution screens and code-completion, why would 'n' be a preferable name to 'number', or 'n1' to 'three-digit-number-1'?
Fantastic video. Any chance you might put together a video on clojure/core.match -- Clojure's pattern matching library ?
I'm coming to Clojure from Haskell and that would close the loop for me (and perhaps others), as list comprehensions, property-based (i.e., generative) testing and pattern-matching are important features of Haskell.
Hi Jason, I'm glad you enjoyed the video. I don't have any experience with core.match, but it's something that I'd like to look into. Perhaps it could be a screencast subject for the future - thanks for the suggestion!
Short variable names induce cognitive load when you ever have to remind yourself of what they mean ("s" for strings and "n" for numbers is conventional and handy, though). However, longer variable names can also induce cognitive load the same way a sentence does when you encounter a long consecutive chain of adjectives or whimsical phrases, each word mentally distancing you from the context in which it all applies.
Now, I understand. Thanks
The default theme in LT has coloured brackets for Clojure code, but I'm actually using my own custom theme (which you can find a link to in the description).
Can you explain what you mean by "the slurp/barf functionality"?
Comprehending this was on my TODO list.
Great job; was helpful.
Thanks! Great explanation.
The problem description is specific to three-digit numbers, but the algorithm isn't. The same code can handle four digit numbers or anything else (you just change the values in the range).
The sensible thing to do with this code is put it in a function, with the start and end numbers as parameters. (Of course, that's not the purpose of your video.)
I certainly agree that a lot of code out there is made harder to understand because of obsessively short names.
Sure. Commonly-used constructs have short names so they stay out of the way and avoid clutter. Constructs that are not common, or not easily understood, or are very specific, deserve a longer name to draw attention to themselves.
Numbers are so common that they get the name 'n'. Likewise strings 's'.
Nothing about this algorithm is specific to *three digit* numbers, so n1 and n2 are sufficient.
I agree that good naming is very important (and quite difficult!), but sometimes short is best.
I've been seeking something equivalent to the "parallel stepping" that one can do in common-lisp's LOOP macro. I'd imagine in some cases one can achieve similar results using Clojure's for/:let but is there an easier and more general approach? Example:
(loop
for x from 0 to 9
for y from 9 downto 0
collect (cons x y)) =>
((0 . 9) (1 . 8) (2 . 7) (3 . 6) (4 . 5) (5 . 4) (6 . 3) (7 . 2) (8 . 1) (9 . 0))
In this case clearly a clojure for/:when would be inefficient as it would also generate all of the unneeded intermediate values. Also, please excuse the CL centric use of CONS in the above example.
I know this is from 4 years ago, but In functional programming, this is referred to as a zip.
stackoverflow.com/questions/2588227/is-there-an-equivalent-for-the-zip-function-in-clojure-core-or-contrib
So if you do (map vector a b) where a and b are vectors, you get a list in the form ((vector a1 b1) ... (vector an bn)) where ai, bi
man you have incredible programming and didactic skills! Thanks for the amazing work, finally i could understand that. And dont let to care of you kid to work, im also a father, trust me i know what im talking about hahaahah. Congrats!
+Renan Reis Thanks for your nice comment, and I'm glad you found the video useful.
I think there might be a couple of problems with your line of reasoning: firstly, range always "works on arbitrary ranges of numbers", so does that mean that we'd never give any ranged var a specific name to indicate its purpose? Secondly, pulling domain language out of the code and into comments or docstrings goes in the opposite direction of self-documenting code. It stops the code speaking for itself. And what happens if someone updates the code, but forgets to update the descriptive comment?
... 7+ years later, here I am again :'D
Thank you, share more pls.
Thanks for putting this video knowledge together. Appreciate the clarity in your thoughts. In making this video more 'readable' I have a few suggestions.
- Make the text larger on the screen as even after making it full screen is still a bit hard to see easily.
- Put the text you're typing into the middle of the screen, rather than at the bottom unless of course you have some context you're trying to keep up there
- Black fonts on white screen is much easier to read than white text on black
great content!
Great suggestions, thank you!
I think "three-digit-number-1" introduces too much label specificity to an implementation that works on arbitrary ranges of numbers. We're already a stone's throw from generalizing `palindromes` into a function that takes the range bounds as arguments. So the fact that we only care about three digit numbers is a detail we can remind our self about at the call site. `;; Finds palindrome products for three digit numbers.` And even if it wasn't generalized, I'd just put it in the doctstring.
Sorry about the formatting of the code in my other comment. See the following gist ffor nicely commented and tested code.
gist . github . com / anonymous / 6723019