You could be correct, or you might have an exaggerated preconceived notion on how hard it is to provide language level patches because of how the industry was in the 90's and early 2000's.
Due to chance I've worked in a company where a colleague had patched the language we were using to save some memory. Back then I (and many people in the Ruby community) considered him a rockstar for doing so. That praise definitely was deserved, since he's done all sorts of cool stuff in his career, but in retrospect that while bold, this feat wasn't all that inconceivable. The Ruby interpreter isn't some magical blackbox, it's got all the features we've learned about in university neatly organized in C files. Somewhere in there is a garbage collector, it manages memory. You can spend a week or so and understand its basic workings. Making it behave slightly different for a specific use case isn't such a moon shot, I believe any smart and experienced engineer could do a proof of concept in a week or two.
I'd like to flip it around. If you're coding on a platform that is so complicated that you couldn't patch it if you needed to, then you're on the wrong platform. That platform is a liability to your company, a liability that you might have to pay off by getting a support contract.
That said, I'm pretty sure the Haskell runtime is very complex, so it might still be the wrong language. I'm just saying, I remember the early 2000's, and if you ran into a problem with your .Net or Java runtime, or god forbid Windows itself, you better be working at a big fat company with a nice support contract, or you'd basically be screwed.
> That said, I'm pretty sure the Haskell runtime is very complex, so it might still be the wrong language.
While the Haskell RTS as a whole is a big (and marvelous) piece of engineering, it is not actually necessary to understand all of it to contribute some smaller patches.
The RTS is written in fairly readable and clean C code and it is possible to make local changes to e.g. the memory allocator without having to touch code in lots of different places.
Due to chance I've worked in a company where a colleague had patched the language we were using to save some memory. Back then I (and many people in the Ruby community) considered him a rockstar for doing so. That praise definitely was deserved, since he's done all sorts of cool stuff in his career, but in retrospect that while bold, this feat wasn't all that inconceivable. The Ruby interpreter isn't some magical blackbox, it's got all the features we've learned about in university neatly organized in C files. Somewhere in there is a garbage collector, it manages memory. You can spend a week or so and understand its basic workings. Making it behave slightly different for a specific use case isn't such a moon shot, I believe any smart and experienced engineer could do a proof of concept in a week or two.
I'd like to flip it around. If you're coding on a platform that is so complicated that you couldn't patch it if you needed to, then you're on the wrong platform. That platform is a liability to your company, a liability that you might have to pay off by getting a support contract.
That said, I'm pretty sure the Haskell runtime is very complex, so it might still be the wrong language. I'm just saying, I remember the early 2000's, and if you ran into a problem with your .Net or Java runtime, or god forbid Windows itself, you better be working at a big fat company with a nice support contract, or you'd basically be screwed.