3 ms·
when choosing a foreign language to learn most normal people would not examine which one has the most elegant grammar, the most performant representation of inf
by college_physics 4y ago
when choosing a foreign language to learn most normal people would not examine which one has the most elegant grammar, the most performant representation of information or any such abstract design elements.
people ask instead: whom will I be able to communicate with. what kind of cultural repository (wealth) do I get access to. how will I benefit to justify spending the limited opportunities I have to reprogram my brain.
the programmer-to-programmer aspect of computer languages is not appreciated enough, especially not in the modern, highly networked and open source way of developing software. yes, the primary purpose is to marshal ones and zeros in silicon chips and it does matter if the language helps you do that in a sane way but this is just one of the many factors people consider.
I think, unfortunately for Julia and other aspiring challengers, right now the primary social network dynamics among developers is "winner takes all". e.g., its not a deep secret that the meteoric rize of python is because it enabled countless people to aspire to be part of the perceived AI/ML/FAANG gold rush. Over time programmer eyeballs motivate investment in ecosystem evolution and a benign spiral is set in motion.
I don't have a crystal ball as to when/if/how the current pyfever might cool down. You can't predict those things, they are an emergent property of our very complex networks. Maybe some killer feature or julia or rust or go or dart or kotlin will trigger some regime change, but unless it does, any discussions of alternate greatness have a distinct detached feeling to them.
- ssivark 4y ago> people ask instead: whom will I be able to communicate with. what kind of cultural repository (wealth) do I get access to. how will I benefit to justify spending the limited opportunities I have to reprogram my brain. Choosing the lowest common denominator language to be able to communicate with the “most number of people” is a specific bias (nothing wrong with it). People pick languages with many different motivations — something might sound/read elegant, or there’s a specific group of people they want to engage with (Eg: anime enthusiasts, kernel developers, statisticians, etc.) > I think, unfortunately for Julia and other aspiring challengers, right now the primary social network dynamics among developers is "winner takes all". Only for certain use cases. Between Python and Julia, there’s exactly one language I want to program in, and will strongly prefer every time I can get away with it. I don’t want to diss on Python — its ecosystem/workflow is a substantial improvement over the previous era, but it has so many warts (for certain fundamental needs, Eg generic programming) that you can never fix the problem “additively” by extending the ecosystem instead of radically redesigning the language ground up.
- college_physics 4y ago> People pick languages with many different motivations thats definitely true, but my observation is that collective behaviors in the adoption of a communication channel have a network dynamic that can dominate rational factors. In previous eras people would learn German or French to get access to scientific/technical literature. At some point English simply became the de-facto language for sharing such knowledge irrespective of whether it might have been the most adapted for this. This does not mean that other languages go extinct, it just creates an allocation that does not seem to correspond to "objective" features. > you can never fix the problem “additively” by extending the ecosystem instead of radically redesigning the language ground up. thats an interesting view but there are important counterexamples :-). you can see, e.g., the rapid developments in the last few years in the C++ space. essentially what can happen in response to pressure (from other ecosystems) is the development of dialects and multi-paradigm languages (abandoning full backward compatibility and/or simplicity). similarly one would think that if python continues benefiting from lavish attention at some point there will be a python 4 etc. you might argue that this not really "fixing the problem" but in the context of delivering useful products here and now this becomes a bit academic
- ssivark 4y ago> have a network dynamic that can dominate rational factors. Yes, but only if they are all equally expressive, or if you only care about the lowest common denominator. In a situation with an expressiveness gradient, the distinction will always survive. I think this insight is articulated well in PG's essay on the blub paradox. Eg: English is a pathetic solution if you want precise/expressive communication for the purpose of engineering -- so no amount of network effect will enable English to trump equations even if it were some new idea (language) like calculus competing with a thousand year old language. > similarly one would think that if python continues benefiting from lavish attention at some point there will be a python 4 etc. you might argue that this not really "fixing the problem" but in the context of delivering useful products here and now this becomes a bit academic Probably the most fundamental tenet (self-professed) of Python is its "simplicity". Whatever that might mean, it seems highly incompatible with growing the language in the manner of C++, and even more so if the changes were backwards-incompatible (as the 2->3 transition demonstrated). The dynamics of language evolution might still bias towards that outcome as the needs of large corporate codebases dominate the beginner's need for simplicity, but at that point Python would have lost most of its soul. But, regardless of all that, (as a concrete example of the kind of limitation I'm talking about) it seems impossible to support generic programming in Python without giving up on OOP / single dispatch. <Lipstick, pig, etc.> > in the context of delivering useful products here and now this becomes a bit academic I disagree, vehemently :-) When there is an impedance mismatch between the problem domain and the abstractions fundamentally embedded into a language/system, you are setting yourself up for a world of pain -- needing an exponential amount of engineering effort to overcome the barrier, and the solution will still forever be doomed to mediocre quality (at best). Calling Python (or pretty much anything) "general purpose" in an absolute sense is a bit of a misnomer -- it just means one is blind to the limitations/biases embedded in the technology, or is implicitly focusing on a limited set of problems.