Hacker News new | past | comments | ask | show | jobs | submit login

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.




> 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.


> 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


> 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.


> I think this insight is articulated well in PG's essay on the blub paradox.

From the essay: ".. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers".

Its funny that twenty years ago python could be at least "a bit frightening" versus its current lowest common denominator status :-). His argument is probably still valid in the same circumstances (a group of people aiming to solving a tough problem ab-initio and in isolation). But the intervening two decades have delivered a lot of learnings about the evolution and adoption of technology stacks in a connected world context. I am by far not qualified to summarize all the wonderful and bizarre things that have happened. I will just mention something that I believe is characteristic of that angle: Think about "json" and its emergence as the now ubiquitous data exchange format. It is arguably a regression in relation to e.g., xml or rdf yet its simplicity has enabled entirely new layers of complexity and the "API" era.

Having said that, its distinctly possible, certain even, that specific language characteristics will be selected for and shine in the near future. One elephant in the room is the end-of-the-road for easy CPU optimizations and the tough problem of speeding up computation across multi-core, GPU etc etc. Another elephant goes back to the json effect and the gross inefficiencies of semantic-lite approaches.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: