4 ms·

> other than statements about the availability of some package But that is probably the most important thing. I don't have time to re-write 40+ years of code i

> other than statements about the availability of some package But that is probably the most important thing. I don't have time to re-write 40+ years of code in a new language just because it's trendy or safer or whatever. I have new science to do! In some ways science suffers because of this, but it is also nice to have a relatively common ecosystem and institutional knowledge that doesn't change every 3 years.

wudangmonk 3y ago
If we take Python an example, how many man-centuries have been spent trying to speed it up enough so that it becomes usable for something it was never meant to be used for?. If 'new science' was writing a small script to automate something instead of writing it in bash then yes I think this language is probably the best language for this task.
- sam0x17 3y ago
  Right but how many of those man-centuries could have been better spent just writing X in a suitable language where you get that for free, and how many subsequent man centuries will be wasted before everyone switches? Imagine where the AI community would be today if the second one of these languages had become stable and generally available, everything had been ported and we'd now be several years into iterating on things in a more suitable environment, and that environment would in turn be that much more advanced by this point?
  - sseagull 3y ago
    There are two problems with this thinking. 1.) The rewrite never seems to have all the features of the original (for many reasons), so you end up keeping the original around because science can be very niche. Now you have two or more packages to deal with. 2.) There is always a better language. Science (or at least parts of science) have switched before - from Fortran to C to C++ to Python. Some of the gains have materialized (some safety, performance, borrowing stuff from outside science). But it has come at a cost (language fragmentation, and also packaging is an absolute shit show right now, partly because #1). But I'm sure the next batch of languages will finally solve all our problems once and for all, and we will never have to switch again. (In general, I am talking about non-AI type science. I am a computational chemist, and our code really does date back > 40 years at times. That is not always a bad thing).
    - sam0x17 3y ago
      > That is not always a bad thing Sure and that's reasonable, but in the cases where performance/throughput/training time/RAM usage is the main limiting factor of a field, suddenly this stuff matters a lot. There's plenty of useful code written in COBOL and Basic from back in the day, but you don't see people using those things to train LLMs Imagine if instead of letting Basic effectively die, we had improved it with a myriad of extensions to the point where you can run LLMs and GPU code and things in a performant-ish way on it. Now replace the word Basic with Python
    - ralphc 3y ago
      How do you, or "you" as the industry, decide that new code and new techniques are worth moving away from existing code?
sam0x17 3y ago
Right, but we're comparing languages, not their ecosystems. It's not a language's fault if the community hasn't yet realized it is better for some purpose and overcome the market effects of tons of existing packages already being in the popular language by migrating them to the less popular language. This is simply using inefficiency as a justification for subsequent and ongoing inefficiency. The whole point of an argument like this is to compel people to put effort into porting things out of a sub-optimal ecosystem. In the short term it is of course convenient to just use the most popular thing always (in which case we'd all still be using PHP and Flash), but eventually things do switch on a large scale, and it benefits all of us to push this along when we can. The more we double-down on an inherently sub-optimal ecosystem, the more we are trapped by it. Imagine if all the effort making Python usable over the last decade had instead been spent on giving a compiled language better dev UX and GPU support... I'm not even a fan of Julia, but I probably would be if it had received the same attention Python has for the last ten years. Conversely, I'm _still_ not a fan of Python, even after all this time and effort has been expended, because the foundation being built upon is just simply a bad one for high performance and high security domains. Anything they manage to get working is akin to a hack, and is working in spite of the language in which it is built.
- eindiran 3y ago
  Comparing languages requires comparing their ecosystem in 99% of cases, since most people don't have the luxury of having enough time to reimplement whatever they need from scratch.
  - webnrrd2k 3y ago
    Right! It's one thing to compare languages in the abstract, for e.g., to compare and contrast iteration or exceptions or whatever. It's a different thing to compare languages for doing something specific -- in this case, scientific computing. If someone want to get something done in a realistic ( or affordable) time frame, then things like like libraries, community, and documentation become especially important.

wudangmonk 3y ago

If we take Python an example, how many man-centuries have been spent trying to speed it up enough so that it becomes usable for something it was never meant to be used for?. If 'new science' was writing a small script to automate something instead of writing it in bash then yes I think this language is probably the best language for this task.

sam0x17 3y ago
Right but how many of those man-centuries could have been better spent just writing X in a suitable language where you get that for free, and how many subsequent man centuries will be wasted before everyone switches? Imagine where the AI community would be today if the second one of these languages had become stable and generally available, everything had been ported and we'd now be several years into iterating on things in a more suitable environment, and that environment would in turn be that much more advanced by this point?
- sseagull 3y ago
  There are two problems with this thinking. 1.) The rewrite never seems to have all the features of the original (for many reasons), so you end up keeping the original around because science can be very niche. Now you have two or more packages to deal with. 2.) There is always a better language. Science (or at least parts of science) have switched before - from Fortran to C to C++ to Python. Some of the gains have materialized (some safety, performance, borrowing stuff from outside science). But it has come at a cost (language fragmentation, and also packaging is an absolute shit show right now, partly because #1). But I'm sure the next batch of languages will finally solve all our problems once and for all, and we will never have to switch again. (In general, I am talking about non-AI type science. I am a computational chemist, and our code really does date back > 40 years at times. That is not always a bad thing).
  - sam0x17 3y ago
    > That is not always a bad thing Sure and that's reasonable, but in the cases where performance/throughput/training time/RAM usage is the main limiting factor of a field, suddenly this stuff matters a lot. There's plenty of useful code written in COBOL and Basic from back in the day, but you don't see people using those things to train LLMs Imagine if instead of letting Basic effectively die, we had improved it with a myriad of extensions to the point where you can run LLMs and GPU code and things in a performant-ish way on it. Now replace the word Basic with Python
  - ralphc 3y ago
    How do you, or "you" as the industry, decide that new code and new techniques are worth moving away from existing code?

sam0x17 3y ago

Right, but we're comparing languages, not their ecosystems. It's not a language's fault if the community hasn't yet realized it is better for some purpose and overcome the market effects of tons of existing packages already being in the popular language by migrating them to the less popular language. This is simply using inefficiency as a justification for subsequent and ongoing inefficiency. The whole point of an argument like this is to compel people to put effort into porting things out of a sub-optimal ecosystem. In the short term it is of course convenient to just use the most popular thing always (in which case we'd all still be using PHP and Flash), but eventually things do switch on a large scale, and it benefits all of us to push this along when we can. The more we double-down on an inherently sub-optimal ecosystem, the more we are trapped by it. Imagine if all the effort making Python usable over the last decade had instead been spent on giving a compiled language better dev UX and GPU support... I'm not even a fan of Julia, but I probably would be if it had received the same attention Python has for the last ten years. Conversely, I'm _still_ not a fan of Python, even after all this time and effort has been expended, because the foundation being built upon is just simply a bad one for high performance and high security domains. Anything they manage to get working is akin to a hack, and is working in spite of the language in which it is built.

eindiran 3y ago
Comparing languages requires comparing their ecosystem in 99% of cases, since most people don't have the luxury of having enough time to reimplement whatever they need from scratch.
- webnrrd2k 3y ago
  Right! It's one thing to compare languages in the abstract, for e.g., to compare and contrast iteration or exceptions or whatever. It's a different thing to compare languages for doing something specific -- in this case, scientific computing. If someone want to get something done in a realistic ( or affordable) time frame, then things like like libraries, community, and documentation become especially important.