I do wish they'd throw the source code up on GitHub, as it would be an interesting historical artifact.
But these days, a big open source/community ecosystem is a really really strong reasons to invest in an existing language (or at least open-source your in-house language, a la Hack or Go). It's hard for in-house general-purpose languages to compete.
I got an offer from NYT in 2009, but rejected it because of the custom language thing. My interview was conducted entirely using this custom language, and the interviewers were uninterested in discussing any other technology. Even architectural questions, which I attempted to answer in terms of industry standards, were steered towards Context.
Writing their system in a custom programming language isn't _that_ unusual, I think. But why on earth during an interview wouldn't they let candidates program (entirely or mostly) in a language they'd heard of before that morning? Couldn't they assume that if someone has achieved a working knowledge of one or more similar languages, they can learn another in some reasonable time (days, weeks, months)?
The interviewer mentioned having another guy in who announced flat out he was not going to do it even though it was explained that you didn't need to know the language to solve the problem.
I of course had some python familiarity, but I still failed because I couldn't remember the name for binary search and that threw me for a loop when the obvious answer I should have gone for in the exercise was 'here we should use binary search'.
So what? Are you a specialist, or can you specialize as needed?
But you can't focus an interview on a proprietary language that the interviewee is bound to not know.
(a) management was not competent enough to realize this is universally a poor investment and refute the project.
(b) tech leads either chose this to solidify job security and leverage for bonuses, or else the choice reflects incompetent tech leads you don’t want to be working with or inheriting code from (especially not in a custom language).
Some notable other examples:
- Danish startup Area 9, which wrote an utterly embarrasingly bad custom language called Flow, which was acquired by McGraw-Hill Education as part of some software that manages student progress in digital materials.
- Goldman Sachs famously with slang
- Standard Chartered with their own custom Haskell compiler and language extensions
- Dropbox (sort of) with Pyston (custom jitted Python implementation) that thankfully is defunct now.
These are bad bad bad signs about a workplace...
What gives you that impression? It would be equally (perhaps more) red flag if Google permitted this in-house, much like Google’s in-house monorepo tooling that grew out of a series of historical Perforce accidents is a huge red flag of dysfunction.
But Google and Facebook have permitted this in-house (Go,Dart,Hack,Reason etc). They have since open-sourced them, but these projects are still run from within. I don't see this as a red flag, these languages all have good reasons to exist.
> Google’s in-house monorepo tooling that grew out of a series of historical Perforce accidents is a huge red flag of dysfunction
Google probably has the largest repo in the world, no off-the-shelf product is going to work. I fail to understand why building their own tools to accommodate their own special needs is a red flag of dsyfunction?
If you look upon an internal business problem and propose that the right starting point for that business problem is to design essentially a single-use language from the ground up, that is a red flag.
If you decide to create a new language as a goal unto itself or as a product, like Go, Swift, Kotlin, etc., then I’d say it’s a silly waste of time but not at all the same sort of red flag as responding to a specific business need by first building a whole language.
As for Google’s monorepo, I’m not getting drawn into more bike shedding about it. There absolutely exist polyrepo off-the-shelf solutions that would performantly handle their use case without the weird limitations of their custom tooling. Happy to agree to disagree with you about it.
1. Facebook (lot of ex-Googlers, so fair if you want to criticize it as a culture thing)
2. Microsoft - they've driven mono repo on Git & have migrated Windows polyrepo flow to a mono repo one. They also gathered metrics & on the whole & users overall (30% dissatisfaction rate for completely altering the workflow over a weekend doesn't seem terrible).
3. Apple kind of. Everyone has their repo but each project submits into 1 giant repo for build purposes. Even still dependency problems crop up (team submits project A but another team forgets or is unable to submit project B that A relies on) that wouldn't in a single monolithic codebase
I work on polyrepo projects and I found the tooling to be quite lacking. Moreover it's been a giant PITA to communicate how to maintain this system to other people. A mono repo would be much easier.
For larger programming languages, it depends. Mainly it's a very long-term commitment. It requires having a strong commitment to funding a team to develop, maintain, and support it. Is that a good idea? I don't know in general. In specific cases it may be an absolutely brilliant idea, though I suspect in most actual cases it's a terrible idea mainly due either to inadequacy of the business case for the proprietary language, or inadequate funding. In order to build and keep proprietary a programming language for decades the value proposition in it has to be enormous -- that makes the business case unlikely, but not impossible.
As for Goldman, hoo boy I have a bridge to sell you. Goldman tech is notoriously dysfunctional. Being the best among investment banks is hardly anything to be proud of whatsoever.
On another note, what about Facebook and Reason ML, and Mozilla and Rust? Or C#, etc etc. There have been dozens of successful languages that originated from companies.
How on Earth did they get permission to invent a whole new language for a user name feature?
You can get a rough idea if you watch this...
Exactly. Also, creating a programming language for something as simple as a newspaper is pretty much a nightmare. Worrying about scalability when most of their content is static.
But I don't know what their hardware constraints weredit person => perl
That was a common pattern back then.
18 repos for Go
9 repos for Python
7 repos for Ruby
I'll read more about their decision on using Go. Thanks for the pointer.