Earlier quoted context omitted.
Real world code rarely uses recursion, and if it does it's the kind that doesn't allow tail call optimization.
I've been using FP strategies for around thirty years, so pardon me if I don't find confidence in your perspective.
PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
71–80 of 291 posts
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#72Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems rapidly became both large (arguably too large) and robust. Rust has been eating C++ lunch. Same rapid rise of ecosystem story. Instead of forcing Python to be a language it isn't it might be more efficient and ultimately the "right choice" to invest the time in…
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#73Earlier quoted context omitted.
What do you think the major drawbacks are? Speed would be the top of my list, but most projects to not need anything more than what python can currently pump out.
You can't dismiss the fact that hiring python is hard. You think you're getting a good programmer, because they know all the leetcode tricks, but that person turns out to be a dud.
I deny that hiring Python is hard beyond “hiring is hard”.
> You think you're getting a good programmer, because they know all the leetcode tricks,
Unless I want someone for a role that is very much like reproducing leetcode tricks, I don't think I would think someone is good for it because they are good at those. In fact, leetcode is mercilessly mocked as being almost completely irrelevant as a positive signal for hiring, though it may be useful as a filtering tool to reduce an overwhelming volume of applicants to a manageable one where high rates of both false negatives and false positives, but some slight advantage over just randomly discarding applicants, is tolerable.
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#74With how quickly these frameworks change it's overwhelming to keep pace! Anyone have advice for solid frameworks that can reasonably leverage GPU's without too much heavy lifting?
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#75Earlier quoted context omitted.
I would say that those are not bad languages. People are just elitist and think if your language isn’t strictly typed, functional and gives first year CS students a headache it’s a bad language and “creates spaghetti code.” The only thing wrong with dynamic typing is it’s slower and is harder to debug, but people are able to be way more productive in these languages you call bad.
> The only thing wrong with dynamic typing is it’s slower and is harder to debug, but people are able to be way more productive in these languages you call bad. Not even close to "only thing". Dynamic language is a net loss of productivity once you reach a certain level of scale. Refactoring a codebase with millions of lines of code in a dynamic language is an absolute nightmare. Opinions vary at what level of scale…
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#76Earlier quoted context omitted.
> The only thing wrong with dynamic typing is it’s slower and is harder to debug, but people are able to be way more productive in these languages you call bad. Not even close to "only thing". Dynamic language is a net loss of productivity once you reach a certain level of scale. Refactoring a codebase with millions of lines of code in a dynamic language is an absolute nightmare. Opinions vary at what level of scale…
It's not just Python, Julia is dynamically typed too.
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#77The more I use Python the more I hate it. It’s genuinely a bad language, with a stellar ecosystem. Ironically, the most valuable parts of the ecosystem are often written in C (NumPy). It’d be interesting to see how much of the Python ecosystem is actually necessary to move PyTorch to a better language. I’m afraid we’re stuck with Python for the next 20 years. That makes me very, very sad.
For me I think the packaging ecosystem is bad, we need one package management tool like poetry built in. We need a built in typing system like typescript. Lastly we need to remove the GIL.
I’m pretty sure all of these are currently being addressed by the community.
I switch languages a lot and things like functools, itertools, dunder methods, list comprehensions, dict comprehensions are things I sorely miss especially in typescript. In particular list and dict comprehensions when used with care are a great deal easier to work with and reason about when transforming data.
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#78What stage of Julia denial is this?
I like what Julia is doing but I just dislike the syntax. It seems to resemble ruby, whose syntax I also think is ugly, which to me resembles a modern form of basic.
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#79Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems rapidly became both large (arguably too large) and robust. Rust has been eating C++ lunch. Same rapid rise of ecosystem story. Instead of forcing Python to be a language it isn't it might be more efficient and ultimately the "right choice" to invest the time in…
Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)
#80The more I use Python the more I hate it. It’s genuinely a bad language, with a stellar ecosystem. Ironically, the most valuable parts of the ecosystem are often written in C (NumPy). It’d be interesting to see how much of the Python ecosystem is actually necessary to move PyTorch to a better language. I’m afraid we’re stuck with Python for the next 20 years. That makes me very, very sad.