4 ms·

> A code by programmer A that does X is not significantly different than code that does the same X by programmer B. Even if that programmer is myself 6 months o

> A code by programmer A that does X is not significantly different than code that does the same X by programmer B. Even if that programmer is myself 6 months or 10 years apart. Honestly, this reads more like you're burnt out and would prefer not to have to keep apace of new developments to continue contributing. I can deeply appreciate that condition, but it seems to me to be an unhealthy place to be on many levels. For one, natural language is constantly evolving. Shouldn't the languages we use to describe the solutions to problems be similarly capable if they want to keep up with a rapidly changing world? For two, we can look at what extreme conservatism in this department does to you. Python 2 has supposed to have started being deprecated, but we're getting hints that big companies are more inclined to just take over support of Python 2 rather than move forward to Python 3. This problem is the result of the culture of "a 10 year old line of code being equally useful without other version controls in place." Similarly, we see a lot of languages punt on actually making it easy to prototype and deploy modern data structures and algorithms. That's why a bunch of mainstream languages still have very slow sorting algorithms in the stdlib (e.g., O(n²) quicksort instead of O(n) american flag sort; still using amortized resizing hash tables as opposed to HAMTs, etc); it's just crazy hard to actually write that code reliably. > You will not need a magnifying glass to read a mish-mash of ASCII math symbols to figure out whether someone built a death ray, or just a milk shaker. No one actually has this problem. Not Perl 6, not Perl 5, and not Haskell or Ocaml. Maybe APL had that problem, but it's long gone. Holding these rhetorical points out seriously seems to me to be more evasive than realistic.

dmitriid 7y ago
> Honestly, this reads more like you're burnt out and would prefer not to have to keep apace of new developments to continue contributing. New developments don't necessarily mean "let's create new and weird syntaxes for TMTOWTDI" > For one, natural language is constantly evolving. Shouldn't the languages we use to describe the solutions to problems be similarly capable if they want to keep up with a rapidly changing world? There are many problems with this analogy. But before you read my points, or even instead of reading my points, I'd recommend you watch "Growing a Language" by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 1. A programming language is not a natural language. It is a constructed language 2. A natural language is not really constrained by anything. It can willy-nilly invent new words and concepts. It can import words and sentences wholesale from other languages, adapt, translate or transliterate them. It can deprecate and get rid of unused words concepts or give entirely new meaning to words. It can and is ambiguous. 3. A programming language is constrained and restricted. English has 500,000 headwords in a dictionary. All of those are "built in". Perl has maybe 100 total built-ins (including operators and keywords), plus a couple of hundred functions in the standard library? 4. A programming language does not aim to encompass all of human knowledge (a natural language does). 5. A programming language hopes to avoid ambiguity (C++ is rightfully criticised and ridiculed for the amount of ambiguous places in its standard). It aims to assign one and only one meaning to every word. A natural language will have thousands of words which have multiple meanings (famously, in English "set" has 464 definitions). 6. A programming language over the course of its evolution does not flip concepts or change meaning of words (except in very rare cases such as changing operator precedence). There are hundreds if not thousands words in every natural language that changed meaning (gay, nice, clue, spinster, senile etc.). 7. A programming language is usually concerned with backwards compatibility (even the rapidly evolving Javascript has to take care not to break sites from 15-20 years ago). Natural languages are never concerned with that. There are tragic stories of huge swaths of history and culture not available to modern generations in South East Asia after they swapped the commonly used Chinese hieroglyphics for national alphabets. Meanwhile programming languages like Clojure boast being able to run old code, and Linux is famously boasting that "it's usually just enough to recompile old programs". etc. etc. etc. > For two, we can look at what extreme conservatism in this department does to you. Python 2 That's not conservatism. That's pragmatism. "Don't fix what ain't broke" is a maxim that is as true today as it was yesterday, and as it will be tomorrow. There can be decades of institutionalised logic coded in Python 2. And it works. We should switch to Python 3 because someone said so? There are 40-year old COBOL codebases that are still doing their job. Should they have been switched to C in the 80s, only to be switched to Java in the 90s, only to be switched to Python in the 00s, only to be switched to Javascript in the 2010s? > Similarly, we see a lot of languages punt on actually making it easy to prototype and deploy modern data structures and algorithms. What you call modern were most likely discovered in 1940s-1960s. All languages have been slow to adopt those. It still has no bearing on my initial statement of " A code by programmer A that does X is not significantly different than code that does the same X by programmer B". A boring language will adopt those modern structures in a boring way and my statement will remain as valid as it is now. > That's why a bunch of mainstream languages still have very slow sorting algorithms in the stdlib So, don't rely on stdlib in these cases. > No one actually has this problem. Not Perl 6, not Perl 5, and not Haskell or Ocaml Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc. On that note, Rails' popularity (and its clones' popularity) comes from the fact that it enforced the "there's only one true way to do it" mentality in a language known for its TMTOWTDI approach. And still, if you take code that does the same by two different people, you'll have to reverse engineered each one as they will use and abuse the "let's do it differently" mentality.
- KirinDave 7y ago
  > 1. A programming language is not a natural language. It is a constructed language Conlangs can be universal. Certainly Toki Pona and Esperanto punch above their weight when given an opportunity to do so. > A programming language is constrained and restricted. English has 500,000 headwords in a dictionary. All of those are "built in". Perl has maybe 100 total built-ins (including operators and keywords), plus a couple of hundred functions in the standard library? Programming languages that lack these constraints not only exist, they're quite famous. You may have heard of Lisp. Similarly, the vocabulary that is the union of every C library in existence is surely more than half a million distinct tokens! Both natural languages and constructed programming languages can constrain themselves to subsets of the total vocabulary, and then extend or contract that context. > . A programming language over the course of its evolution does not flip concepts or change meaning of words (except in very rare cases such as changing operator precedence). There are hundreds if not thousands words in every natural language that changed meaning (gay, nice, clue, spinster, senile etc.). Programming has tons of these as well. Many concepts are overloaded right now! The semantics under the symbols are constantly evolving. Heck, even things you might not believe have changed at lot have altered in subtle but important ways, like "new" and "delete" and "malloc" and "fopen." One of the most dramatically changed is "map." > What you call modern were most likely discovered in 1940s-1960s. No. 1990 onwards. People still spout absurdities like, "the fastest you can sort an array is O(n log n) time." But another important example is Bagwell's Hash Array Mapped Tries, which dramatically improve the performance of well-ordered key-value stores dramatically on modern hardware. Outside of some interesting index techniques, I can't think of many worthy algorithms from the 60's lingering in obscurity. Can you? > That's not conservatism. That's pragmatism. "Don't fix what ain't broke" is a maxim that is as true today as it was yesterday, and as it will be tomorrow. There can be decades of institutionalised logic coded in Python 2. And it works. We should switch to Python 3 because someone said so? If you don't change your methodologies at all over the course of a decade as the entire world of computer science revolutionizes itself and we even start rethink how we're organizing operating systems? > There are 40-year old COBOL codebases that are still doing their job. Should they have been switched to C in the 80s, only to be switched to Java in the 90s, only to be switched to Python in the 00s, only to be switched to Javascript in the 2010s? Are there? I know a few banks deeply regretting their decision to keep their system of record on outdated cold-war-era technology as they struggle with hard complexity caps they can't address. But sure, I'm sure somewhere somehow this is true. It's just not actually an argument. > Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc. This is a just-so story. There is no magical solution that makes all code permeable. It's misguided to assume code can exist without good documentation. > On that note, Rails' popularity (and its clones' popularity) comes from the fact that it enforced the "there's only one true way to do it" mentality in a language known for its TMTOWTDI approach. Hi, I actually know a lot about this and there is no such notion in Rails. In fact, you have it exactly wrong. Rails is deeply committed to a "good default behavior" that is always subject to modification. And people do in fact modify it extensively to suit their needs. The idea that Rails's defaults are constraining as opposed to a rational starting point fundamentally misses the point.
spiralx 7y ago
> Honestly, this reads more like you're burnt out and would prefer not to have to keep apace of new developments to continue contributing. Do you think that the patronising and confrontational tone of this comment and others here are effective at getting your points across, because I'm not finding any positive reasons to be interested in Perl 6 and its community in what you've said... or maybe in how you've said it.
- KirinDave 7y ago
  Firstly: do you think this is particularly patronizing? I don't think that discussing burn-out and how people come across in that state is so. Secondly: the GP is, by any reasonable standard, pretty dang patronizing in and of itself. Stuff like: >> You will not need a magnifying glass to read a mish-mash of ASCII math symbols to figure out whether someone built a death ray, or just a milk shaker. Is that elevating the discourse? I think the reason folks are willing to overlook this is because they think it's socially acceptable to hurl insults when they dislike the flavor of the syntax rather than actually offering concrete complaints. Folks in the various responses have mocked perk, its users, and diagnosed the author with various illnesses. > or maybe in how you've said it. I don't have much of a stake in Perl 6. I think it's interesting. What I am invested in is reminding folks that good notations require investment of time to read. That's the case for every other applied science, but because of the pervasive scorn directed by the world at computer science, folks view any effort put into programming as wasted. I'm not trying to give you a reason to use Perl 6, so there is no surprise you didn't find it. I'm trying to reflect back these learned behaviors and show how arbitrary and thoughtless they are.

dmitriid 7y ago

> Honestly, this reads more like you're burnt out and would prefer not to have to keep apace of new developments to continue contributing. New developments don't necessarily mean "let's create new and weird syntaxes for TMTOWTDI" > For one, natural language is constantly evolving. Shouldn't the languages we use to describe the solutions to problems be similarly capable if they want to keep up with a rapidly changing world? There are many problems with this analogy. But before you read my points, or even instead of reading my points, I'd recommend you watch "Growing a Language" by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 1. A programming language is not a natural language. It is a constructed language 2. A natural language is not really constrained by anything. It can willy-nilly invent new words and concepts. It can import words and sentences wholesale from other languages, adapt, translate or transliterate them. It can deprecate and get rid of unused words concepts or give entirely new meaning to words. It can and is ambiguous. 3. A programming language is constrained and restricted. English has 500,000 headwords in a dictionary. All of those are "built in". Perl has maybe 100 total built-ins (including operators and keywords), plus a couple of hundred functions in the standard library? 4. A programming language does not aim to encompass all of human knowledge (a natural language does). 5. A programming language hopes to avoid ambiguity (C++ is rightfully criticised and ridiculed for the amount of ambiguous places in its standard). It aims to assign one and only one meaning to every word. A natural language will have thousands of words which have multiple meanings (famously, in English "set" has 464 definitions). 6. A programming language over the course of its evolution does not flip concepts or change meaning of words (except in very rare cases such as changing operator precedence). There are hundreds if not thousands words in every natural language that changed meaning (gay, nice, clue, spinster, senile etc.). 7. A programming language is usually concerned with backwards compatibility (even the rapidly evolving Javascript has to take care not to break sites from 15-20 years ago). Natural languages are never concerned with that. There are tragic stories of huge swaths of history and culture not available to modern generations in South East Asia after they swapped the commonly used Chinese hieroglyphics for national alphabets. Meanwhile programming languages like Clojure boast being able to run old code, and Linux is famously boasting that "it's usually just enough to recompile old programs". etc. etc. etc. > For two, we can look at what extreme conservatism in this department does to you. Python 2 That's not conservatism. That's pragmatism. "Don't fix what ain't broke" is a maxim that is as true today as it was yesterday, and as it will be tomorrow. There can be decades of institutionalised logic coded in Python 2. And it works. We should switch to Python 3 because someone said so? There are 40-year old COBOL codebases that are still doing their job. Should they have been switched to C in the 80s, only to be switched to Java in the 90s, only to be switched to Python in the 00s, only to be switched to Javascript in the 2010s? > Similarly, we see a lot of languages punt on actually making it easy to prototype and deploy modern data structures and algorithms. What you call modern were most likely discovered in 1940s-1960s. All languages have been slow to adopt those. It still has no bearing on my initial statement of " A code by programmer A that does X is not significantly different than code that does the same X by programmer B". A boring language will adopt those modern structures in a boring way and my statement will remain as valid as it is now. > That's why a bunch of mainstream languages still have very slow sorting algorithms in the stdlib So, don't rely on stdlib in these cases. > No one actually has this problem. Not Perl 6, not Perl 5, and not Haskell or Ocaml Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc. On that note, Rails' popularity (and its clones' popularity) comes from the fact that it enforced the "there's only one true way to do it" mentality in a language known for its TMTOWTDI approach. And still, if you take code that does the same by two different people, you'll have to reverse engineered each one as they will use and abuse the "let's do it differently" mentality.

KirinDave 7y ago
> 1. A programming language is not a natural language. It is a constructed language Conlangs can be universal. Certainly Toki Pona and Esperanto punch above their weight when given an opportunity to do so. > A programming language is constrained and restricted. English has 500,000 headwords in a dictionary. All of those are "built in". Perl has maybe 100 total built-ins (including operators and keywords), plus a couple of hundred functions in the standard library? Programming languages that lack these constraints not only exist, they're quite famous. You may have heard of Lisp. Similarly, the vocabulary that is the union of every C library in existence is surely more than half a million distinct tokens! Both natural languages and constructed programming languages can constrain themselves to subsets of the total vocabulary, and then extend or contract that context. > . A programming language over the course of its evolution does not flip concepts or change meaning of words (except in very rare cases such as changing operator precedence). There are hundreds if not thousands words in every natural language that changed meaning (gay, nice, clue, spinster, senile etc.). Programming has tons of these as well. Many concepts are overloaded right now! The semantics under the symbols are constantly evolving. Heck, even things you might not believe have changed at lot have altered in subtle but important ways, like "new" and "delete" and "malloc" and "fopen." One of the most dramatically changed is "map." > What you call modern were most likely discovered in 1940s-1960s. No. 1990 onwards. People still spout absurdities like, "the fastest you can sort an array is O(n log n) time." But another important example is Bagwell's Hash Array Mapped Tries, which dramatically improve the performance of well-ordered key-value stores dramatically on modern hardware. Outside of some interesting index techniques, I can't think of many worthy algorithms from the 60's lingering in obscurity. Can you? > That's not conservatism. That's pragmatism. "Don't fix what ain't broke" is a maxim that is as true today as it was yesterday, and as it will be tomorrow. There can be decades of institutionalised logic coded in Python 2. And it works. We should switch to Python 3 because someone said so? If you don't change your methodologies at all over the course of a decade as the entire world of computer science revolutionizes itself and we even start rethink how we're organizing operating systems? > There are 40-year old COBOL codebases that are still doing their job. Should they have been switched to C in the 80s, only to be switched to Java in the 90s, only to be switched to Python in the 00s, only to be switched to Javascript in the 2010s? Are there? I know a few banks deeply regretting their decision to keep their system of record on outdated cold-war-era technology as they struggle with hard complexity caps they can't address. But sure, I'm sure somewhere somehow this is true. It's just not actually an argument. > Everyone has those problems in any language that adopted TMTOWTDI. It manifests in difficulty reading other people's code, onboarding of new hires in organisations etc. etc. This is a just-so story. There is no magical solution that makes all code permeable. It's misguided to assume code can exist without good documentation. > On that note, Rails' popularity (and its clones' popularity) comes from the fact that it enforced the "there's only one true way to do it" mentality in a language known for its TMTOWTDI approach. Hi, I actually know a lot about this and there is no such notion in Rails. In fact, you have it exactly wrong. Rails is deeply committed to a "good default behavior" that is always subject to modification. And people do in fact modify it extensively to suit their needs. The idea that Rails's defaults are constraining as opposed to a rational starting point fundamentally misses the point.

spiralx 7y ago

> Honestly, this reads more like you're burnt out and would prefer not to have to keep apace of new developments to continue contributing. Do you think that the patronising and confrontational tone of this comment and others here are effective at getting your points across, because I'm not finding any positive reasons to be interested in Perl 6 and its community in what you've said... or maybe in how you've said it.

KirinDave 7y ago
Firstly: do you think this is particularly patronizing? I don't think that discussing burn-out and how people come across in that state is so. Secondly: the GP is, by any reasonable standard, pretty dang patronizing in and of itself. Stuff like: >> You will not need a magnifying glass to read a mish-mash of ASCII math symbols to figure out whether someone built a death ray, or just a milk shaker. Is that elevating the discourse? I think the reason folks are willing to overlook this is because they think it's socially acceptable to hurl insults when they dislike the flavor of the syntax rather than actually offering concrete complaints. Folks in the various responses have mocked perk, its users, and diagnosed the author with various illnesses. > or maybe in how you've said it. I don't have much of a stake in Perl 6. I think it's interesting. What I am invested in is reminding folks that good notations require investment of time to read. That's the case for every other applied science, but because of the pervasive scorn directed by the world at computer science, folks view any effort put into programming as wasted. I'm not trying to give you a reason to use Perl 6, so there is no surprise you didn't find it. I'm trying to reflect back these learned behaviors and show how arbitrary and thoughtless they are.