Hacker News Reader

Comment by tomrod | Hacker News Reader

I have extensive work in Matlab, C, Fortran, R, Python, Julia, SAS (IML), and am learning Go and Rust. I have played with Java and Kotlin on non-serious projects.

I typically use Python for data-related tasks.

Julia is just okay. It lost its steam due to long beta, slow time to first plot after 1.0 release, and generally not being a strategically adopted language by ML innovation groups. A great example of what is versus what was hoped is John Myles White's work[0], where the headline is "worked on large community Python projects" but is one of the originators of Julia's fundamental data packages.

I've had lots of intelligent people who use code as a tool instead of as a craft -- for data folks, their craft is working with data and not the tooling around it. For folks like this, Python is simply a better option in today's environment.

[0] https://www.johnmyleswhite.com/about/

View on HN

> For folks like this, Python is simply a better option in today's environment.

By what metric? Me, being involved with the infrastructure of research projects, I see how much time and effort is wasted just by working around the sheer stupidity of Python and its tooling daily. Because researchers generally don't see the infrastructure work as important, they also tend not to associate the effort it takes to get the infrastructure decently functional with their own work. So, they tend to think that it doesn't matter what language environment they are using (and thus prefer the familiar one).

Inevitably, this spills into researcher's work anyways. One of the typical problems (related to Python tooling) I see is this: the project worked for a while with a set of dependencies with which it was initially created, and one day everything explodes because some dependency screw something up. Non-infra people usually have hard time figuring out what broke and how to fix it, so they choose the path of least resistance: either not build / test project automatically anymore (only on individual developer's machines) or try to "freeze" the dependencies, preventing the update from breaking the old (broken) stuff from being exposed, or "fixing" by mindlessly copying some StackOverflow "solution" that does some asinine thing, but allows for the project to keep "working".

In the end of the day, Python-based projects tend to have very short shelf life. Often by the time they near completion they are already so behind the "latest and greatest" that others, who might have wanted to adopt them, don't want to do that because they'd have to make special downgrades in their infrastructure to even try it. Larger Python projects are almost guaranteed not to work with other projects because of overlapping and conflicting dependencies. Making Python-based projects available to non-programmers is another painful experience that usually ends in a failure.

So, you might achieve higher development velocity on a particular stretch in your development journey, but you definitely didn't account for the whole thing, definitely not with an eye for sustainability / longevity.

Given you're referring to me and my career, can you explain what you mean about "worked on large community Python projects"? I don't see that text on the page you're citing. Is it an interpretation of "I’ve been part of teams working on a variety of things, including extensions to the Python language and A/B testing"?

Hey John! Yes, you're accurate here in how I interpreted your work on extensions in the Python language. Let me know if that is in error, would love to hear an alternative opinion to Julia's growth and status. My subjective take has been that the initial excitement of Julia has waned a bit (a shame, it's a good language) and that it's not seeing strong adoption.

EDIT: That said, I just looked up the TIOBE index and it appears to be growing. My subjective take is likely in error here!

I still use Julia a lot and still think it is the best bet for a dynamic language with acceptable speed. I don't work on many OSS projects anymore, so I'm not an active contributor, but I'm not contributing to other languages in my spare time either. The projects you see in my "about" page are my paid efforts.

I think Julia's adoption is still not at all comparable to Python or R, but neither of those languages were comparably popular at this point in their own lifetimes. I think people underestimate how slow change is here.

Julia absolutely could fail to compete in the long run, but it is still growing and it is improving.

> . I don't work on many OSS projects anymore, so I'm not an active contributor, but I'm not contributing to other languages in my spare time either. The projects you see in my "about" page are my paid efforts.

I appreciate the clarification and correction. Apologies for muddying the water.

Are you disagreeing with something I said?

Indeed.

The world is a very heterogeneous place, and we're all immersed in our own bubbles -- each with its own assumptions and needs. "Data related" is a fairly vague description.

- It appears that there's substantial community effort invested in smoothing the pathway for scientific modeling and related ML. So that's one area where I expect anyone picking up Julia will see quick+substantial wins.

- Recent Julia versions (1.9, 1.10 on the way) have made tremendous progress in TTFX: https://julialang.org/blog/2023/04/julia-1.9-highlights/

- I happen to work on problems (with more of a computation/simulation flavor, rather than "data related") where Python is extremely painful and Julia happens to be the best fit by far (and rapidly getting even smoother!).

> I've had lots of intelligent people who use code as a tool instead of as a craft

Agreed -- so there's no point being fanatical about it. Folks can keep an eye out and periodically re-evaluate whether the ecosystem has reached maturity for their needs. For those who want to "use libraries", it will take a bit longer than those who want to "write libraries".

Julia aims to solve the two-language problem. If you live in Python and never have to touch another language like C or Fortran, then the value proposition of Julia is going to feel much more tenuous. But there are a set of people (library developers) who experience the ecosystem in the diametrically opposite way: https://twitter.com/dillonniederhut/status/16791406806799728...

> and generally not being a strategically adopted language by ML innovation groups.

I see the tremendous engineering effort being sunk to massage different (mutually incompatible) subsets of Python into some shape amenable for ML -- supporting new algorithms on top, and more efficient program execution at the bottom (translating from software to hardware).

I've heard the claim that it's sometimes better to delay a solution and let the users feel the pain before they open their minds to the solution. That is what I'm reminded of when I think of ML and Julia. If ML users don't see the value of Julia yet, that's okay -- they might once they dig themselves in deeper.

If they manage to solve all ML problems with Python (with C and what not), that's fine too! I think the world is a bigger place where there are also other interesting things going on, and Julia is helping a lot of people do things they couldn't accomplish otherwise :-)

There's no fundamental reasons for languages to "age", unless they happen to be tied to some unsuitable assumptions in how they model the world -- aspects that cannot be rearchitected without fundamentally changing the language. Barring that problem, languages only get more mature.

The problem with Python is not that it is three decades old, but that its revealed priorities (model of the world and software) is out of sync with many of today's needs. Even if we forget advanced things like ML, there's still a bunch of really basic stuff that make Python painful: https://twitter.com/dmimno/status/1679474354579488771

I think the design of Julia is much more robust in those aspects, but we also need to see how multiple dispatch plays out for very large codebases+teams. Meanwhile, I expect Julia will keep improving rapidly in the use cases it supports.

Excellent then that you agree that people who use Python as their coding language aren't necessarily Dunning-Kruger exhibits

Pro tip: you can identify who is posting by their username. If you are responding to me you left out the word 'only'. Even the guy you cited is calling you out. Time to slink away?

Parent comment here was not in response to you, but to ssivark's comment.

My point earlier was that people who solely use Python aren't DK exhibits in action simply because they know one language. Further, they may do so as a consequence of tech stack used in their roles or in their organizations. Given Python's adoption in the data domain, many people in the space use code simply as a tool to get things delivered.

And should not be relied on to suggest data formats that can be useful in other languages, as others in this thread have pointed out.

Python is useful for people who have no formal training, but they are leveraging off the work of others. I hope you can understand how experts do not attach much weight to people still trying to figure out how computers actually work.

And this point:

> experts do not attach much weight to people still trying to figure out how computers actually work

is a much weaker form of this point:

> It is impossible to have an intelligent discussion with someone who only knows Python, FSVO know. Dunning-Kruger in action.

The first point is true for anyone focused on a single language, outside of perhaps Assembly. The second is simply wrong.

Reply on news.ycombinator.com