"Why Programming Languages Matter" by Andrew Black
Vložit
- čas přidán 9. 10. 2023
- I’ve spent most of my professional life working on programming languages: studying them, designing them, defining their semantics, comparing features, and even implementing them (mostly poorly). Why would an otherwise-sane person do such a thing? Because programming languages are the ultimate meta-tool: they give you the ability to create from pure thought. And yet: a programming language is not just a means for programmers to communicate with computers-it is also a means for programmers to communicate with programmers. That is: a good programming language is a social, as well as a technical, enabler.
This talk will take a bumpy ride through the challenges and opportunities associated with the six languages that I’ve played a part in developing over the past forty-five years-most of which you won’t have heard of. Why do new languages face an uphill struggle for acceptance? What are the challenges facing the next generation of languages and language designers? Why should you care about any of this? Because those who do not know the past are doomed to repeat it.
Andrew Black
Emeritus Professor, Portland State University
Andrew Black is an Emeritus Professor of Computer Science at Portland State University. His first programming language was Algol 60, an accident for which he will always be grateful. As a graduate student, he at first refused a request to teach Fortran to undergraduates, on the grounds that it was unfair to subject students to such a language; he relented when his supervisor (Tony Hoare) pointed out that if the students were going to learn Fortran from someone, it would be better if they learned it from a teacher who understood its many deficiencies. Later, but after his involvement with the Emerald programming language, he learned, taught and contributed to Smalltalk, an encounter that permanently re-arranged his brain cells. As well as teaching at four universities, Professor Black has worked in the laboratories of four major companies (two of which still exist). He has published over 100 research papers, and been involved in the design, development and implementation of six programming languages. For the past ten years he has been the BDFL of the Grace Educational Programming Language, and the major committer to the minigrace implementation.
----
Recorded on Sept 21, 2023 in the PWLConf track at Strange Loop 2023 in St. Louis, MO.
thestrangeloop.com
pwlconf - Věda a technologie
“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.
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.
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).
This is good! Watch it. The presenter reminds me a little of Joe Armstrong (Erlang)
I've read Levy, yet I know nothing of Eden - looks like I've a new rabbit hole to fall into!
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.
Referencing the founder of the ideal modern higher education in the first 6 minutes - you captured my attention ☺
Sublime
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.
Strangeloop can end but we'll still need something like strangeloop
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.