5 ms·
Ask HN: What are your thoughts on "unofficial" programming languages in companies?
All companies have their standards as to what languages they will support and not support. The company I work for in particular, a 10,000+ corporation, is strictly a Microsoft shop. I understand the decision for having "official" languages from a management point-of-view; supportability is the bottom line.
But after reading "Developing Erlang at Yahoo!" and how the new Delicious is written in Erlang, I started to think about how "unofficial" languages can be approved up the ranks for a production system, such as the case with Delicious at Yahoo! I wish the slides explained more about the decision making in the early stages. What are your thoughts about developing in languages that are not supported? If you were proposing to use unsupported language x to build a system, what would your argument be to go this route?
(My aim is to make this conversation more about management and less about programming language wars)
- davidw 18y ago> But after reading "Developing Erlang at Yahoo!" and how the new Delicious is written in Erlang Didn't you read the bit about it not being written in Erlang ? http://news.ycombinator.com/item?id=323116 http://news.ycombinator.com/item?id=323116 One route would be simply to go work somewhere where you can learn new languages, rather than try and get around obstacles at BigCorp.
- twampss 18y agoThanks David - I didn't see this thread, but the presentation was clear that there was still a lot of C++ in addition to the Erlang services. Still curious as to the thinking behind Erlang getting the nod... And yes, that would be one route - arguably the best route. But if one were to make a career out of his job in a big corp, I would say it is worth it to introduce new languages into the company to open up more options in future development. It goes without saying though...languages with more/better documentation and healthy community would be a plus in considering.
- iigs 18y agoFighting that front and center will make you that hoarding programmer that doesn't cooperate or share, writes horribly obfuscated code and tries to ensure job security by not just doing things the "right" way. You'll be perceived that way whether or not you're the Mother Teresa of code, so don't do that. An arguably better approach to this problem is to find places where the MS stack is lacking (source control, automated builds, deployment are some things that come to mind from my circa-2003 knowledge of the MS stack) and write scripts that improve your company's development processes. If you do this successfully you might see things change from "we only use $tech products" to "our customer facing, support-requiring products are all written in $tech". From here you have a valid footing upon which to demonstrate the quality, productivity and supportability (be sure you can support these commensurate with the company's need!) of other solutions. Now that you have a footing upon which to build, you can architect solutions that push the strategic part of the products away from the customer facing veneer and toward an asynchronous, nearline component where potential failures won't be seen by the customers directly. You may not be able to get that far, depending on what your products do, but maybe you can take the first step or two, and at least scripting in nicer languages can certainly make the rest of your job a lot easier and more pleasant.