Re: [Haskell-cafe] off-topic question: how well do you think linguistic relativity applies to PLs and programming?

programming ... languages, and in particular the way that programmers use them, afford a capacity for essentially limitless amounts of abstraction, unlike human language and human communication.
Au contraire! Humans use just such powerful abstractions in language, arts and sciences — what we call humanity is built on no less. They're called *memes*.
The only difference is that humans communicate on a foundation of shared experience that is a little more fuzzy and infinitely richer than the result of a data-base lookup.
Simon Yarde
On 22 Jan 2014, at 23:35, Keshav Kini
Lucas Paul
writes: This is my take, as a CS undergraduate.
I'm not sure if we can say that a programmer's language of choice determines the way they think about programming (the strong version of linguistic relativity for programming, as I see it). But I think it's fairly obvious that the language we choose to use to solve a problem affects how we think about the solution. That's basically the entire raison d'être for domain-specific languages (DSLs)!
DSLs are popular (and becoming more so) precisely because the right choice of DSL can make expressing the solution to a particular kind of problem almost trivial. A poor choice can almost doom an endeavor. Imagine trying to query a database in assembly language. No SQL. It would at the very least require some mental gymnastics that a SELECT statement simply obviates.
I think this can be partially explained by noting that programming languages, and in particular the way that programmers use them, afford a capacity for essentially limitless amounts of abstraction, unlike human language and human communication. For example, I might easily have a magic library that does exactly what I want, with bindings for my programming language of choice, in which case I don't need to think about what to do, I just call the appropriate function. In human communication, while someone might have perfectly formulated exactly the idea I want to communicate, it is rarely sufficient for the purpose of communication to say "insert pages 204 through 356 of _Foobar_ by John Doe here" in the middle of a conversation :)
-Keshav
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Simon Yarde
programming ... languages, and in particular the way that programmers use them, afford a capacity for essentially limitless amounts of abstraction, unlike human language and human communication.
Au contraire! Humans use just such powerful abstractions in language, arts and sciences — what we call humanity is built on no less. They're called *memes*.
The only difference is that humans communicate on a foundation of shared experience that is a little more fuzzy and infinitely richer than the result of a data-base lookup.
Humanities people sometimes talk about "namedropping," like on a philosophy podcast[1] where one of the ground rules is No namedropping! Don't make arguments that hinge on something other than what we've agreed to read. Don't say, "You'd understand me if you'd only read *Capitalism is Fine, Now Shut Up*, by The Man." So just introducing a name (or even an ISBN number) isn't enough to establish an abstraction in the humanities -- you need to work for it, and new abstractions will probably remain fringey and unloved for a few years until they're accepted as part of normal discourse. There are similar issues in programming, like when introducing brand new abstract typeclasses, combinators, concepts, and so on. Even introducing a dependency on a 3rd party library can sometimes resemble a kind of "namedropping." But it's easier to get away with it in software! -- Mikael Brockman (@mbrock) [1]: The Partially Examined Life, http://www.partiallyexaminedlife.com/, have this rule, with a new bogus example at the start of each episode; the quoted one is from the episode on *The Gay Science*.

Mikael Brockman
So just introducing a name (or even an ISBN number) isn't enough to establish an abstraction in the humanities -- you need to work for it, and new abstractions will probably remain fringey and unloved for a few years until they're accepted as part of normal discourse.
There are similar issues in programming, like when introducing brand new abstract typeclasses, combinators, concepts, and so on. Even introducing a dependency on a 3rd party library can sometimes resemble a kind of "namedropping." But it's easier to get away with it in software!
Right, that's what I was talking about. Actually, not only is it easier to get away with it in software, it's the preferred option -- DRY is good and NIH is bad, etc. -Keshav
participants (3)
-
Keshav Kini
-
Mikael Brockman
-
Simon Yarde