31–40 of 52 posts
I know it's just an article, but...
If anyone thinks they should replace working Fortran code that does numerical analysis with Ruby, they should be fired.
The name "Scientist" is about as good as "Engineer" or "Programmer." In other words, extremely confusing when used as a product name in a technical domain!
the name is a bit annoying. seems very dude-cool-name-syndrome.
There's also exhibit C:
From Github repository "Scientist" : README.md
"How do I science?"My biggest disappointment with "Scientist" is that it basically provides service which Erlang code has for free - hot code reloading. For decades now. Along with other cool features like great support for parallel execution, hierarchical monitoring and so on.
Article mentions some early user raves about this tool in context of "it allows me do refactoring!"
Of course it would help, but there are languages that either have all this cool stuff for decades (Erlang), or can allow you to do heavy refatoring without asking for help from "interesting" tools like this "Scientist" (Haskell).
> She envisions aging banks using it to upgrade decades-old Fortran code to Ruby or any other modern language. I know it's just an article, but... If anyone thinks they should replace working Fortran code that does numerical analysis with Ruby, they should be fired.
It's a shame GitHub puts effort into stuff like this as opposed to actually listening to their users (e.g. "Dear GitHub"). We can infer a shift from GitHub to alternate services soon from this, unless they change.
>> We can infer a shift from GitHub to alternate services soon from this, unless they change.
Nope. People are lazy. Will a lot of people write comments and all, how they are going to totally move away from github? Oh yeah, no doubt. But will they actually do it? Nah, just a few, unless github becomes as bad as source forge but I don't think it's going to happen, even then it would take some time.
Yes, yes, I am aware that migrating is just a matter of adding a new origin. That's the easy bit. But getting used to a new interface and everything, that takes much more effort and time. Writing a comment is easier (especially when tons of people are doing that around you) than changing your habits.
Even ignoring everything above, I don't really agree with the "puts effort into stuff like this as opposed to actually listening to their users" attitude. GitHub is not a one man's project. The whole company shouldn't drop everything just to do something right now because it was trending on HN a week or two ago. A company like this (making substantial product changes rather urgently based on some hype) maybe sounds cool but, in reality, you would probably not be excited to use their products. Urgent changes in features and quality often does not go together.
Nobody mentioned Erlang so far. My biggest disappointment with "Scientist" is that it basically provides service which Erlang code has for free - hot code reloading. For decades now. Along with other cool features like great support for parallel execution, hierarchical monitoring and so on. Article mentions some early user raves about this tool in context of "it allows me do refactoring!" Of course it would help, but…
Nobody mentioned Erlang so far. My biggest disappointment with "Scientist" is that it basically provides service which Erlang code has for free - hot code reloading. For decades now. Along with other cool features like great support for parallel execution, hierarchical monitoring and so on. Article mentions some early user raves about this tool in context of "it allows me do refactoring!" Of course it would help, but…
Huh, does that apply less if they've basically never heard of you when they imitate you? Not to imply that Erlang is unheard of, I'm just saying it's not as popular and orthodox as Python/Ruby/C/java/etc.
> She envisions aging banks using it to upgrade decades-old Fortran code to Ruby or any other modern language. I know it's just an article, but... If anyone thinks they should replace working Fortran code that does numerical analysis with Ruby, they should be fired.
I used to work at a TBTF financial institution. During orientation, they told us that their mainframes process roughly 1/3 of US credit card transactions. The low-level code is 40-year old Fortran that still performs swimmingly.
> She envisions aging banks using it to upgrade decades-old Fortran code to Ruby or any other modern language. I know it's just an article, but... If anyone thinks they should replace working Fortran code that does numerical analysis with Ruby, they should be fired.
The first being that the code works fine, the deployment works fine, everything is working just fine. Do. Not. Touch. It.
These are some of the most financially important systems in America to date. It's not a question about if they have to work, it's a question about just how bad things would get if they didn't work for even a day.
The next problem that comes up is what happens when someone finds a bug 60, 40, or even 10 years in the future? What happens when some of this old hardware breaks and it becomes not only impossible to find replacement parts but also impossible to fabricate new ones in house.
Eventually, like all languages, Fortran will die out as time goes on. So few people know it now that it is inevitable.
Eventually something has to give and we can do two things until then.
1. Wait for time to pass and pretend nothing will ever happen to these machines.
2. Slowly start rewriting all of the stack, and transferring everything to more modern systems designed to be just as long term as their predecessors so that in the event of a replacement being needed it exists.
I don't know about anyone else, but I like to have backups/fallbacks when planning for the future.
I'm not saying that Ruby or any new language should be entrusted with this kind of responsibility. But there needs to be a decision and it needs to be made over the next couple of decades.