“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” 😅 Brilliant
9:30 an apology to the physics professor who so often had to see me nodding off for 10 minutes in the first lecture of the day. I could focus much better the whole day afterwards, but it was rude.
When referring to Ruby at the end, which Ruby library are you thinking about ? Ruby itself has multiple inheritance (despite the author refusing to call it that way), but I found out that it works like a subset of call-next-method in CLOS (which is not like Traits).
Gave up when he brought in the rightly discredited Sapir-Whorf theory. Linguistics is fascinating. So is computer programming. I have done both and am here to tell you that they are very different fields; they are not fully non-overlapping magisteria, but they don’t overlap much. Of course software can be and is used in the study of language, but that is a different matter.
@@kahnfatman he mentioned Curry right after, which is like haskell + Prolog. Problem with curry is, most of the spec isn't implemented on the major systems. I would recommend Mercury if any of you want to put your brain through a strainer. It resembles prolog very much and has rigorous typing mechanisms that force you to iron out your logical specification.
Humboldt's idea that language and it's structures limit and determines human knowledge or thought is called linguistic determinism. Since the 20th century, linguistic determinism has largely been discredited by studies and abandoned within linguistics, cognitive science, and related fields. Source: en.wikipedia.org/wiki/Linguistic_determinism
nice of you to add a source but the speaker did already discredit it as such as soon as they introduced the concept. The talk is about shapes/patterns of thought, not prisons of thought
I'm not convinced that ones language totally shapes what one can think. If that were the case nobody would ever have ideas that they have to find new language to talk about it with. See mathematics. The problem is that nobody can tell what you are thinking or if what you think makes any sense or if you are thinking at all until there is a common language by which they can understand you. Which makes it appear that it was the language that was behind it all. Which is a bit of a chicken and egg problem as they have to get the idea before they will understand that new language....
I think you're taking it a bit more strictly, than it is intended, since it says "shapes", but not "defines" or "restricts". And even so, out of all programmers that I know there are just a few that are looking for improvements of their tooling - even those who are constantly angry with their language are still more likely to stick with it than to learn something new. Just another example - I'm a C++ dev, and I was talking with my friend, who is a Pythonist. We were discussing the usage of lambdas, and I mentioned that I often pass lambdas to standard algorithms, like filter or transform. He asked me - why not just write a for loop for that? And I know the formal correct answer - it is safer, since you avoid off-by-one errors, and it is easily chained with other operations, and C++ almost certainly will do some optimizations under the hood. But it's not why I do it, in my day-to-day. It's just the way I think, and my work experience in C# and it's LINQ system (which is quite good), and some studying of Haskell that allowed me to ditch the loops, where they aren't necessary. Keep in mind: me and my friend have been studying programming together since high school, and we were both taught loops as a basic building block. And he is an excellent programmer, too, who doesn’t need this in Python. But the more languages, approaches and tools you learn, the more different ideas and approaches you get to the same problems, from the smallest scale of the for-loop to the largest scale of the system design. P.S. …and the more flaws you start seeing in the things that you use everyday, which slowly pushes you to the journey of “Finding or building the perfect language”, which I don’t expect to ever end, be that a good or a bad thing. I warned you :)
But when you become fluent in new language, you find yourself understanding concepts that are hard to translate. Similarly what matters to you depends on what's easy to say in a language, if you're used to not having it said explicitly you'll be comfy without it but will tend to include it inelegantly in a foreign tongue until you have adjusted.
Programming languages try to help you build abstractions from just a few built-in primitive abstractions; however, it seems like those abstractions are often mediocre, so you're thinking of the whole problem in terms of the base elements. Hence, if you program in C exclusively, you'll be thinking of pointers and addresses the whole way through; very different from higher-level languages that have map, filter, and_then, async/await, promises, etc., which let you forget about tje underlying assembly. BASIC and Fortran programmers often had trouble with the concept of recursive functions in languages such as Pascal; it was as if they couldn't grasp abstractions besides arrays, loops, variable assignments, and gotos. I think that's evidence that programming languages shape and can constrain the way you think about a problem. I don't think the same necessarily applies to natural languages (e.g. English, Spanish), because I think they're fundamentally different to programming languages.
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” 😅 Brilliant
Time stamp?
@@JeremyHelm 23:56 by Tony Hoare.
Programming languages aren’t even 100 years old; I believe there’s SO much room for improvement and new ideas. Really appreciate the talk!
5 star talk if I've seen one!
Might be worth watching a few more times before it all crystallizes into a beautiful artifact of timeless knowledge.
9:30 an apology to the physics professor who so often had to see me nodding off for 10 minutes in the first lecture of the day. I could focus much better the whole day afterwards, but it was rude.
This is good! Watch it. The presenter reminds me a little of Joe Armstrong (Erlang)
Referencing the founder of the ideal modern higher education in the first 6 minutes - you captured my attention ☺
I've read Levy, yet I know nothing of Eden - looks like I've a new rabbit hole to fall into!
Strangeloop can end but we'll still need something like strangeloop
When referring to Ruby at the end, which Ruby library are you thinking about ? Ruby itself has multiple inheritance (despite the author refusing to call it that way), but I found out that it works like a subset of call-next-method in CLOS (which is not like Traits).
Gave up when he brought in the rightly discredited Sapir-Whorf theory. Linguistics is fascinating. So is computer programming. I have done both and am here to tell you that they are very different fields; they are not fully non-overlapping magisteria, but they don’t overlap much. Of course software can be and is used in the study of language, but that is a different matter.
Sublime
Why not Prolog? :-(
If not, what is the alternative? Datalog??
@@kahnfatman
he mentioned Curry right after, which is like haskell + Prolog. Problem with curry is, most of the spec isn't implemented on the major systems.
I would recommend Mercury if any of you want to put your brain through a strainer. It resembles prolog very much and has rigorous typing mechanisms that force you to iron out your logical specification.
@@razetimeMercury is cool but imo sacrifices too much flexibility offered by prolog.
Humboldt's idea that language and it's structures limit and determines human knowledge or thought is called linguistic determinism. Since the 20th century, linguistic determinism has largely been discredited by studies and abandoned within linguistics, cognitive science, and related fields.
Source: en.wikipedia.org/wiki/Linguistic_determinism
He was talking about the weak form I think
nice of you to add a source but the speaker did already discredit it as such as soon as they introduced the concept. The talk is about shapes/patterns of thought, not prisons of thought
I'm not convinced that ones language totally shapes what one can think. If that were the case nobody would ever have ideas that they have to find new language to talk about it with. See mathematics. The problem is that nobody can tell what you are thinking or if what you think makes any sense or if you are thinking at all until there is a common language by which they can understand you. Which makes it appear that it was the language that was behind it all. Which is a bit of a chicken and egg problem as they have to get the idea before they will understand that new language....
I think you're taking it a bit more strictly, than it is intended, since it says "shapes", but not "defines" or "restricts". And even so, out of all programmers that I know there are just a few that are looking for improvements of their tooling - even those who are constantly angry with their language are still more likely to stick with it than to learn something new.
Just another example - I'm a C++ dev, and I was talking with my friend, who is a Pythonist. We were discussing the usage of lambdas, and I mentioned that I often pass lambdas to standard algorithms, like filter or transform. He asked me - why not just write a for loop for that? And I know the formal correct answer - it is safer, since you avoid off-by-one errors, and it is easily chained with other operations, and C++ almost certainly will do some optimizations under the hood. But it's not why I do it, in my day-to-day. It's just the way I think, and my work experience in C# and it's LINQ system (which is quite good), and some studying of Haskell that allowed me to ditch the loops, where they aren't necessary. Keep in mind: me and my friend have been studying programming together since high school, and we were both taught loops as a basic building block. And he is an excellent programmer, too, who doesn’t need this in Python. But the more languages, approaches and tools you learn, the more different ideas and approaches you get to the same problems, from the smallest scale of the for-loop to the largest scale of the system design.
P.S. …and the more flaws you start seeing in the things that you use everyday, which slowly pushes you to the journey of “Finding or building the perfect language”, which I don’t expect to ever end, be that a good or a bad thing. I warned you :)
"See mathematics"... and then comes lambda calculus
But when you become fluent in new language, you find yourself understanding concepts that are hard to translate. Similarly what matters to you depends on what's easy to say in a language, if you're used to not having it said explicitly you'll be comfy without it but will tend to include it inelegantly in a foreign tongue until you have adjusted.
Programming languages try to help you build abstractions from just a few built-in primitive abstractions; however, it seems like those abstractions are often mediocre, so you're thinking of the whole problem in terms of the base elements. Hence, if you program in C exclusively, you'll be thinking of pointers and addresses the whole way through; very different from higher-level languages that have map, filter, and_then, async/await, promises, etc., which let you forget about tje underlying assembly. BASIC and Fortran programmers often had trouble with the concept of recursive functions in languages such as Pascal; it was as if they couldn't grasp abstractions besides arrays, loops, variable assignments, and gotos. I think that's evidence that programming languages shape and can constrain the way you think about a problem. I don't think the same necessarily applies to natural languages (e.g. English, Spanish), because I think they're fundamentally different to programming languages.