6 ms·

> What can you say in this language that would be impossibly inconvenient to say in others? Maybe it's just me and my possibly-unreasonable infatuation with th

> What can you say in this language that would be impossibly inconvenient to say in others? Maybe it's just me and my possibly-unreasonable infatuation with the Sapir-Whorf hypothesis (SWH) but I've come to think it also applies to many things in life, PLs especially so. "Weird languages" aren't valuable because you can deploy it in production, rather because it will help you recontextualize a problem (in SWH-parlance, it helps you see the world differently). You can also say, SWH is an academic formulation of the beloved programmer motto "When all you have is a hammer, everything looks like a nail". If all you know is an imperative syntax, all problems look solvable by breaking them down into a series of steps/procedures. In my almost ten years in the industry, there's exactly one time I was able to apply an "unusual" paradigm to solve a problem. GvR might curse me because I sort of made a Lisp-like DSL in Python but I stand by my design decision. The end-result was a small (~200LoC linted with black) DSL parser with some DB access and a lot of rules which actually tried to solve the problem. When I found something wrong I just had to reformulate a rule, not actually wrangle with loops, conditionals, and control flow in order to rewrite logic. Honest negatives: I had to turn over the project to someone whose background is in EEE, not CS, and I had to explain Higher-Order Functions to them. Not ideal! Actually, in fairness, I bet most in that team would have a hard time figuring it out because, hey, I made a Lisp in Python! But I still stand by my decision; it was the best for the problem given the resources and time I had.

emodendroket 5y ago
On the other side of the ledger, the Sapir-Whorf hypothesis is widely considered discredited by linguists.
- skytreader 5y ago
  Has it? I'm genuinely curious to know. "Widely considered discredited" sounds like it's met the same fate as ether or alchemy. I commented on SWH a few months ago in HN too when another user, claiming background in linguistics, replied that it factors in your world view but not as huge a factor as other cultural considerations. That sounded reasonable. So as of the last time I looked up SWH (a few months ago), my knowledge of its consensus is that: - the weak form ("relativism") is true to a certain extent, and definitely not to the extent Whorf originally proposed. - the strong form ("determinism") is largely debated and, personally, I think it's indefensible as a thesis.
  - emodendroket 5y ago
    When I took linguistics classes in school it was summarily brushed off, but here's how Wikipedia summarizes: > The strong version, or linguistic determinism, says that language determines thought and that linguistic categories limit and determine cognitive categories. This version is generally agreed to be false by modern linguists. > The weak version says that linguistic categories and usage only influence thought and decisions. Research on weaker forms has produced positive empirical evidence for a relationship.
    - coldtea 5y ago
      Well, DUH! Did anybody put forward the first version which sounds like a strawman? "language determines thought and that linguistic categories limit and determine cognitive categories. This version is generally agreed to be false by modern linguists" The use of words like "determine" appears to make it look bogus. Whereas "influences" basically means the same thing (in practical terms, strongly influences is just as good as determines).
      - TeMPOraL 5y ago
        Well, based on my own introspection, the strong version looks obviously true to me - so I'm glad someone took time to disprove it. When I read the description, I understand "determines" as in, your thoughts internally work in terms of language processing, so their complexity is limited to the complexity of the language(s) you know. It sounds plausible, but also testable by checking if humans who never learned a language with complex grammar are capable of processing complex concepts.
        formerly_proven 5y ago
        For a long time in human history people did not accept the existence of negative numbers; a Greek mathematician couldn't solve x+1=0 for example (this one also has "zero" in it, which also did not exist for some mathematicians). This seems like a decent example for linguistic categories limiting the thinkable categories. Other Greek examples: Zeno's paradoxes, irrational numbers, ...
- alisonkisk 5y ago
  Only an extremely strong version of the hypothesis is discredited, and that's because humans can create new languages to help their thoughts. But that's not an argument for a single static language being sufficient.
- coldtea 5y ago
  On the other hand, it's not like linguists are doing exactly a hard science, and their discrediting something means much, especially when it touches totally unrelated domains like psychology and neuroscience.
  - emodendroket 5y ago
    If we want to take this into a more concrete and measurable realm, every programming language is going to get converted into the same machine code before it is run, so it is quite untrue that there is any idea that "cannot be expressed" in one programming language but can be expressed in another. It may be more or less convenient to do but nothing like the strong Sapir-Whorf hypothesis for human languages.
    - coldtea 5y ago
      Well, in programming yes. Though even in programming, there are e.g. non turing complete languages (e.g. simple regex languages), languages without certain high level facilities (making it much harder to organize your code in terms of certain concepts - analogous to organizing your thinking of the world around certain concepts -, which is a SWH-like effect), languages that can't express e.g. infinite loops and are certain to terminate (used e.g. for business logic, templating, etc), and so on. Even if it all goes down to assembly, a language like Cobol might it much harder to write e.g. a 3D game. And that can be enough for games not be written in that language - it doesn't have to be impossible, just hard, which is enough to discourage most, aside from a few weirdos writing games in Cobol and compilers in bash.
  - _emacsomancer_ 5y ago
    Sometimes, when it's a field well outside of your area of expertise, not making pronouncements can save embarrassment later on.
    - coldtea 5y ago
      My sentiments exactly (only on the other side). You seem to respect everything labeled academic, but not all "areas of expertise" and not all "fields" are equally valid -- and surely not just because they are taught in universities, written about in "peer reviewed" journals, and so on. Linguistics is closer to soft sciences than the opposite.
sanderjd 5y ago
Declarativeness targeting a specific problem is definitely good, but it is implementable in any language.
- a4isms 5y ago
  You have touched on what is both the best and the worst thing about programming languages in 2021. On the one hand, most modern languages are powerful enough that you can build whatever you want on them. DSLs, constraint solving, pure FP, CPS, logic programming, whatever you like. On the other hand, languages are subject to network effects. If you build an FP system on top of Python and I build one on top of Ruby, the resulting “FP frameworks” will be almost entirely incompatible. That makes it hard for people coming to either of our projects to “pick it up." It’s great fun to implement your own library or framework that in turn implements something interesting, but everyone doing that leads to applications that are built on top of in-house home-grown greenspunned code bases. In most production situations, it’s better to find the language and framework that already cater to the idiom you like, and come with a community of like-minded programmers who are familiar with how things work. Network effects matter at scale, even if they’re irrelevant for a passion project. The notion that any language can be coerced into supporting any programming idiom is true in theory, “But the difference between theory and practice is narrower in theory, than it is in practice.” So I suggest there is still a lot of value in selecting the language/framework/library that was built to do the thing we want, right off the bat, and comes trailing a community and ecosystem around it.
  - alisonkisk 5y ago
    what if you want to do more than one thing? Thus is a common requirement.
  - novok 5y ago
    Lisp Macros making DSLs have similar issues, your DSL doesn't work with the other guy's DSL trying to solve a similar issue.
    - a4isms 5y ago
lifeisstillgood 5y ago
Please tel us more - a DSL in python is ... fun ... and having a real world use is cherry on top
- skytreader 5y ago
  Flattered by your interest but now I'm afraid the words "DSL" and "Lisp-like" might've given the impression of far more complexity than the project actually was. Keep in mind the core engine is ~200LoC. Maybe twice that at most. But really, there were far more rules than engine logic in the end. The project was started for legal compliance so I don't want to go into specifics in case I make a slip one way or another. It did not run in the production cluster per se but was important nonetheless. (Actually, gods forbid it run in production!) Very vaguely, it simplified structured data. A rule is recursively defined, base cases being simple rules that just returned primitive data. The original data could be an object with deep properties but most rules just simplified it to one with less fields. I call it "Lisp-like" because after writing a handful of recursive rules, I had flashbacks of when I studied (actually) Scheme in uni. The tree-structure and meta-rules certainly gave that impression. I did not parse parens though, rather the rule syntax is JSON dictionaries. I hope this aided in readability---it should be self-explanatory what each rule did---and so my team did not find it too esoteric. I don't remember the exact volume of data we processed but it was in the tens of GB, if not low hundreds. We parallelized it and had maybe 20 runners working concurrently. You can claim mapreduce (ha!) at this approach but honestly I think we could've parallelized it as easily if I did not go with this DSL-approach. :)
dkarl 5y ago
Immutable record types as the default, most-used way of modeling data is a great idea that some languages cater to and other languages force you to do in weird, hacky ways. Countless systems have been designed around mutable data simply because they were written in languages where mutable data was the default. I personally worked on several Java systems where mutability was used but was trivial to refactor out, because every place an instance was modified, it was simple to construct a new instance instead. On a couple of them I had ownership of the codebase and was able to complete this refactoring with a reasonable amount of effort. I also created a small codebase in Java with an immutable data model, only to pass it off to someone who immediately added setters for every field because they were "missing." And then of course he started to find uses for them. I don't have a desire to work in Java again, but I think Java recognizing immutable record classes as a concept worthwhile of first class language support is a significant step forward for the industry.
jl6 5y ago
> Actually, in fairness, I bet most in that team would have a hard time figuring it out because, hey, I made a Lisp in Python! But I still stand by my decision; it was the best for the problem given the resources and time I had. Are you completely sure you didn’t just create a massive headache for the team that followed you? Now they have to understand something that looks like magic, or pay more money to hire a wizard. I’ve seen a lot of “clever and elegant” solutions that become instant legacy when the original genius leaves, and a lot of “boring and repetitive” solutions that stand the rest of time.
- skytreader 5y ago
  I feel like the bit you quoted already captures what I think came of it after I turned it over. It is even from a paragraph labeled "Honest negatives". Complete certainty of how it turned out is a bit too much to ask. For every story like mine, there's an equivalent story of a legacy system in boring Java/C that no one wants to touch, works like magic, etc. FWIW, I wrote a pretty extensive documentation of the project before I left, including recommendations for improvement[1]. Again, it's foolish to claim complete certainty but the nature of the project was such that they are unlikely to need to rewrite anything on top of the engine. Any modifications and additions moving forward would be in the declared rules, not in any of the logic. And for that, they have hundreds of examples from me to copy from. And if they do need to touch the "parser", at ~200LoC the complexity is certainly far below, say, a Spring J2EE code base. It's all in one file too, that shouldn't be too bad. [1] If I may use HN as a small soapbox, actually, months later, I figured out a further small addition to that project that would've made working with it far easier. If any of my previous team recognizes this and this project is still in use, feel free to reach out to me for one last brilliant idea. :)
  - xpe 5y ago
    Sounds like a useful project. > It's all in one file too, that shouldn't be too bad. Fewer files is not necessarily better. The guiding principle in my mind is reduction of entropy. If splitting one file into multiple files makes sense in the brains of the beholders it is a good thing.

emodendroket 5y ago

On the other side of the ledger, the Sapir-Whorf hypothesis is widely considered discredited by linguists.

skytreader 5y ago
Has it? I'm genuinely curious to know. "Widely considered discredited" sounds like it's met the same fate as ether or alchemy. I commented on SWH a few months ago in HN too when another user, claiming background in linguistics, replied that it factors in your world view but not as huge a factor as other cultural considerations. That sounded reasonable. So as of the last time I looked up SWH (a few months ago), my knowledge of its consensus is that: - the weak form ("relativism") is true to a certain extent, and definitely not to the extent Whorf originally proposed. - the strong form ("determinism") is largely debated and, personally, I think it's indefensible as a thesis.
- emodendroket 5y ago
  When I took linguistics classes in school it was summarily brushed off, but here's how Wikipedia summarizes: > The strong version, or linguistic determinism, says that language determines thought and that linguistic categories limit and determine cognitive categories. This version is generally agreed to be false by modern linguists. > The weak version says that linguistic categories and usage only influence thought and decisions. Research on weaker forms has produced positive empirical evidence for a relationship.
  - coldtea 5y ago
    Well, DUH! Did anybody put forward the first version which sounds like a strawman? "language determines thought and that linguistic categories limit and determine cognitive categories. This version is generally agreed to be false by modern linguists" The use of words like "determine" appears to make it look bogus. Whereas "influences" basically means the same thing (in practical terms, strongly influences is just as good as determines).
    - TeMPOraL 5y ago
      Well, based on my own introspection, the strong version looks obviously true to me - so I'm glad someone took time to disprove it. When I read the description, I understand "determines" as in, your thoughts internally work in terms of language processing, so their complexity is limited to the complexity of the language(s) you know. It sounds plausible, but also testable by checking if humans who never learned a language with complex grammar are capable of processing complex concepts.
      - formerly_proven 5y ago
        For a long time in human history people did not accept the existence of negative numbers; a Greek mathematician couldn't solve x+1=0 for example (this one also has "zero" in it, which also did not exist for some mathematicians). This seems like a decent example for linguistic categories limiting the thinkable categories. Other Greek examples: Zeno's paradoxes, irrational numbers, ...
alisonkisk 5y ago
Only an extremely strong version of the hypothesis is discredited, and that's because humans can create new languages to help their thoughts. But that's not an argument for a single static language being sufficient.
coldtea 5y ago
On the other hand, it's not like linguists are doing exactly a hard science, and their discrediting something means much, especially when it touches totally unrelated domains like psychology and neuroscience.
- emodendroket 5y ago
  If we want to take this into a more concrete and measurable realm, every programming language is going to get converted into the same machine code before it is run, so it is quite untrue that there is any idea that "cannot be expressed" in one programming language but can be expressed in another. It may be more or less convenient to do but nothing like the strong Sapir-Whorf hypothesis for human languages.
  - coldtea 5y ago
    Well, in programming yes. Though even in programming, there are e.g. non turing complete languages (e.g. simple regex languages), languages without certain high level facilities (making it much harder to organize your code in terms of certain concepts - analogous to organizing your thinking of the world around certain concepts -, which is a SWH-like effect), languages that can't express e.g. infinite loops and are certain to terminate (used e.g. for business logic, templating, etc), and so on. Even if it all goes down to assembly, a language like Cobol might it much harder to write e.g. a 3D game. And that can be enough for games not be written in that language - it doesn't have to be impossible, just hard, which is enough to discourage most, aside from a few weirdos writing games in Cobol and compilers in bash.
- _emacsomancer_ 5y ago
  Sometimes, when it's a field well outside of your area of expertise, not making pronouncements can save embarrassment later on.
  - coldtea 5y ago
    My sentiments exactly (only on the other side). You seem to respect everything labeled academic, but not all "areas of expertise" and not all "fields" are equally valid -- and surely not just because they are taught in universities, written about in "peer reviewed" journals, and so on. Linguistics is closer to soft sciences than the opposite.

sanderjd 5y ago

Declarativeness targeting a specific problem is definitely good, but it is implementable in any language.

a4isms 5y ago
You have touched on what is both the best and the worst thing about programming languages in 2021. On the one hand, most modern languages are powerful enough that you can build whatever you want on them. DSLs, constraint solving, pure FP, CPS, logic programming, whatever you like. On the other hand, languages are subject to network effects. If you build an FP system on top of Python and I build one on top of Ruby, the resulting “FP frameworks” will be almost entirely incompatible. That makes it hard for people coming to either of our projects to “pick it up." It’s great fun to implement your own library or framework that in turn implements something interesting, but everyone doing that leads to applications that are built on top of in-house home-grown greenspunned code bases. In most production situations, it’s better to find the language and framework that already cater to the idiom you like, and come with a community of like-minded programmers who are familiar with how things work. Network effects matter at scale, even if they’re irrelevant for a passion project. The notion that any language can be coerced into supporting any programming idiom is true in theory, “But the difference between theory and practice is narrower in theory, than it is in practice.” So I suggest there is still a lot of value in selecting the language/framework/library that was built to do the thing we want, right off the bat, and comes trailing a community and ecosystem around it.
- alisonkisk 5y ago
  what if you want to do more than one thing? Thus is a common requirement.
- novok 5y ago
  Lisp Macros making DSLs have similar issues, your DSL doesn't work with the other guy's DSL trying to solve a similar issue.
  - a4isms 5y ago

lifeisstillgood 5y ago

Please tel us more - a DSL in python is ... fun ... and having a real world use is cherry on top

skytreader 5y ago
Flattered by your interest but now I'm afraid the words "DSL" and "Lisp-like" might've given the impression of far more complexity than the project actually was. Keep in mind the core engine is ~200LoC. Maybe twice that at most. But really, there were far more rules than engine logic in the end. The project was started for legal compliance so I don't want to go into specifics in case I make a slip one way or another. It did not run in the production cluster per se but was important nonetheless. (Actually, gods forbid it run in production!) Very vaguely, it simplified structured data. A rule is recursively defined, base cases being simple rules that just returned primitive data. The original data could be an object with deep properties but most rules just simplified it to one with less fields. I call it "Lisp-like" because after writing a handful of recursive rules, I had flashbacks of when I studied (actually) Scheme in uni. The tree-structure and meta-rules certainly gave that impression. I did not parse parens though, rather the rule syntax is JSON dictionaries. I hope this aided in readability---it should be self-explanatory what each rule did---and so my team did not find it too esoteric. I don't remember the exact volume of data we processed but it was in the tens of GB, if not low hundreds. We parallelized it and had maybe 20 runners working concurrently. You can claim mapreduce (ha!) at this approach but honestly I think we could've parallelized it as easily if I did not go with this DSL-approach. :)

dkarl 5y ago

Immutable record types as the default, most-used way of modeling data is a great idea that some languages cater to and other languages force you to do in weird, hacky ways. Countless systems have been designed around mutable data simply because they were written in languages where mutable data was the default. I personally worked on several Java systems where mutability was used but was trivial to refactor out, because every place an instance was modified, it was simple to construct a new instance instead. On a couple of them I had ownership of the codebase and was able to complete this refactoring with a reasonable amount of effort. I also created a small codebase in Java with an immutable data model, only to pass it off to someone who immediately added setters for every field because they were "missing." And then of course he started to find uses for them. I don't have a desire to work in Java again, but I think Java recognizing immutable record classes as a concept worthwhile of first class language support is a significant step forward for the industry.

jl6 5y ago

> Actually, in fairness, I bet most in that team would have a hard time figuring it out because, hey, I made a Lisp in Python! But I still stand by my decision; it was the best for the problem given the resources and time I had. Are you completely sure you didn’t just create a massive headache for the team that followed you? Now they have to understand something that looks like magic, or pay more money to hire a wizard. I’ve seen a lot of “clever and elegant” solutions that become instant legacy when the original genius leaves, and a lot of “boring and repetitive” solutions that stand the rest of time.

skytreader 5y ago
I feel like the bit you quoted already captures what I think came of it after I turned it over. It is even from a paragraph labeled "Honest negatives". Complete certainty of how it turned out is a bit too much to ask. For every story like mine, there's an equivalent story of a legacy system in boring Java/C that no one wants to touch, works like magic, etc. FWIW, I wrote a pretty extensive documentation of the project before I left, including recommendations for improvement[1]. Again, it's foolish to claim complete certainty but the nature of the project was such that they are unlikely to need to rewrite anything on top of the engine. Any modifications and additions moving forward would be in the declared rules, not in any of the logic. And for that, they have hundreds of examples from me to copy from. And if they do need to touch the "parser", at ~200LoC the complexity is certainly far below, say, a Spring J2EE code base. It's all in one file too, that shouldn't be too bad. [1] If I may use HN as a small soapbox, actually, months later, I figured out a further small addition to that project that would've made working with it far easier. If any of my previous team recognizes this and this project is still in use, feel free to reach out to me for one last brilliant idea. :)
- xpe 5y ago
  Sounds like a useful project. > It's all in one file too, that shouldn't be too bad. Fewer files is not necessarily better. The guiding principle in my mind is reduction of entropy. If splitting one file into multiple files makes sense in the brains of the beholders it is a good thing.