32 ms·
Some of my favorite organizations have been the ones where someone senior picked a very tiny number of "official" languages early on, and established clear rule
by ekidd 5y ago
Some of my favorite organizations have been the ones where someone senior picked a very tiny number of "official" languages early on, and established clear rules about when to use which. Some examples:
- "Our web apps get written in Typescript."
- "Our data science gets written in Python."
- "Our inner loops get written as Rust CLI tools that contain no business logic." (Or whatever. It depends on the problem domain.)
This works because TypeScript, Python and Rust are all very good at certain tasks, but they're each also fine general-purpose languages with lots of third party libraries. If you do somehow wind up writing a webserver in Python, you'll be fine. Of course, something like Haskell is a deeper commitment with more tradeoffs, and it's the wrong answer for most organizations. (But if I were mathematically modeling the pricing of complex derivative contracts, Haskell would make the list.)
But this is why good senior people with taste are so useful, and why competent technical management is worth its weight in gold. Sometimes you want a toolbox with 2 or 3 well-chosen, versatile tools. And sometimes you get organizations that try to pound in nails with a screwdriver.
- tharkun__ 5y agoIt sort of makes sense. If things can still change. Have you never been at a company where the above list was: Our web apps get written in Perl (later added: with jQuery for FE interactivity) Our data science gets written in Oracle stored procedures Our core business logic is written in Oracle stored procedures! Fat clients are written in Smalltalk These were arguably even sort of well chosen at the time. (I won't say which company this was as that would identify me and I changed some details but this is a real life example)
- HelloNurse 5y agoIn such an environment, there is usually next generation after next generation of these software types, with upgraded (or at least updated) basic technological choices. Some of these choices are recent and possibly bleeding edge, some are old and possibly only good at that time, some prove misguided immediately or in hindsight. For example I've seen: - COM and ASP.Net to Java and JSF (general web apps) - Forté 4GL (look it up, it was very interesting) to J2EE (general enterprise software) - MIDP Java to React Native, following mobile phone evolution (mobile app front ends of general enterprise software) - HTML frame messes to Java applets to JavaScript interactivity (high profile public web site) - ColdFusion, or something of the sort, to Sharepoint (another high profile public web site) - SharePoint to a BPEL workflow engine (important workflow-oriented application)
- pjmlp 5y agoPeople keep dismissing COM, unaware that all major Windows APIs since Vista are COM based, even WinRT. Not using COM for native programming on Windows is being stuck with Windows XP.
- HelloNurse 5y agoIn my case there were true believers using their own COM components to complicate the architecture of web apps and web services, without the slightest interest for Windows APIs beyond "we are stuck with a fun server OS".
- davedx 5y agoI was somewhat involved in this process at an org I worked at, the thing is, some languages really are the best tool for the job, and trying to build something in the wrong language can really hurt software quality or reliability. That said, I agree you should still try to standardise to a reasonable degree.