I loved it when I was younger, but I had trouble recommending it more recently because its tone is adjacent to personally attacking people who like Java.
I remember in 2008 he predicted that text editors/IDEs will have to compete against the browser. When Jupyter notebook hit the scene I thought how prescient he was. There's a move toward bringing back the editor/IDE-like environment but I suppose with VS Code being based on electron it's just another form of the browser.
2
write a lengthy, self-important diatribe/novella about why he joined
3
Write several lengthy, self-important diatribes, often namedropping previous places he worked and/or how he accidentally influenced some C level officer just by dint of his unique persona =) That rascally Steve!
4
Repeat step 3 anywhere between 10-50 times
5
Quit job, write lengthy self-important diatribe about why he left (optionally leaping straight into step 1 again, sometimes with a break inbetween)
Should be an interesting 6 months for Sourcegraph, at least! Looking forward to seeing how this progresses.
I can't help but read Steve Yegge's announcement in the context of Novig's Law ("compiler research leads to a doubling of compute power every 18 years")[0].
If his presence and enthusiasm can get the compiler community aiming its collective brain power at real developer productivity problems (the why behind SourceGraph's exponential growth) rather than focused on compiler optimization problems, this is going to be a really great time to be writing software!
Small nit: if you actually read your citation, it's not Norvig's law, but Proebsting's law[1]. It's a pessimistic spoof of Moore's law, but IMO just reflects how much closer to optimal we started from than the first transistors were. Or maybe how much of a head start we've had doing this on paper for centuries.
Like, I would frankly be surprised if we ever got more than one doubling out of Proebsting's law.
You're right - Norvig is a much easier name for me to remember than Proebstring, which probably has something to do with why I misfiled the law mentally.
Reading your cite, Norvig's law is different. He credits Todd Proebsting with that observation. (Peter Norvig's law is that something that is at 50% adoption will never double again.)
* Precise code navigation (vs. more fuzzy-level nav), powered by SCIP (spiritual successor to Grok, the system Steve built at Google)
* More powerful search language beyond regex (supports comby.dev) + user-friendly (smart search)
* Works across multiple GitHub instances + other code hosts (GitLab, Bitbucket, Perforce, enterprise Git repositories)
* Self-hosted deployment and enterprise scale
cs.github.com is a significant improvement over github.com/search—kudos to the team there!—but is about feature parity with something like OpenGrok, Hound, or Google Code Search before Steve built and integrated Grok (primarily cross-codebase regex search).
> cs.github.com is a significant improvement over github.com/search
It's a significant improvement, but still frustrating to use (especially after being spoiled by Google's codesearch). Sourcegraph has been far more pleasant to use in my experience (e.g., faster and more relevant navigation).
I'm trying to figure out if Sourcegraph requires git and it's not clear to me. I saw a page about non-git code hosts but it looks like it still builds a git repository to mirror the actual repository. Is that correct?
I really like the idea of sourcegraph but the price seems bonkers. $100/month/user is more than I spend on ides, more than GitHub, the same as GitLab ultimate (that I don’t use because it’s so expensive), more than o365, more than windows, etc etc etc.
I want to have source intelligence but I can’t see the biggest chunk of my dev stack to be sourcegraph.
Kythe was slightly after my time on Grok. It was a side-effort by the Grok team, and it's frankly a miracle they got it out at all. Google only really supports a few big open-source projects - Chrome, YT, k8s. Kythe fell waaaay below the line.
I'll be taking another look at Kythe, and reaching out to the current Grok team, as we expand scip. But ultimately it didn't matter what protocol/format we standardize on. We just need to standardize. So it's scip!
And it is still garbage. Can it differentiate between the declaration, definition, and calls of a function Foo, versus just substrings "Foo" found anywhere in the file, such as comments? Nope.
"This was the first leadership interview loop in the past 12 months (20+ companies) in which anyone had asked me to write code."
Interesting data point for the question: at what point in your career will you stop being asked to write code on a whiteboard to prove you aren't lying on your resume.
I’ve never been through an interview cycle where candidates didn’t lie about this, so I assume pretty high. It always boggled my mind that people would claim programming skills but not be able to write hello world.
If its not the pressure cooker, this is trick question and i am going to blast you for missing the return and void in parenthesis types question then we can partially blame the candidate.
Many of us have faltered like this once or twice unless its an outright lie kind of situation.
Readit News
Youngbloods: if you have not spent time with Steve Yegge's old writings, please go check them out. Much good received wisdom there.
1 Join a company
2 write a lengthy, self-important diatribe/novella about why he joined
3 Write several lengthy, self-important diatribes, often namedropping previous places he worked and/or how he accidentally influenced some C level officer just by dint of his unique persona =) That rascally Steve!
4 Repeat step 3 anywhere between 10-50 times
5 Quit job, write lengthy self-important diatribe about why he left (optionally leaping straight into step 1 again, sometimes with a break inbetween)
Should be an interesting 6 months for Sourcegraph, at least! Looking forward to seeing how this progresses.
If his presence and enthusiasm can get the compiler community aiming its collective brain power at real developer productivity problems (the why behind SourceGraph's exponential growth) rather than focused on compiler optimization problems, this is going to be a really great time to be writing software!
[0] https://norvig.com/norvigs-law.html
Like, I would frankly be surprised if we ever got more than one doubling out of Proebsting's law.
[1]: https://www.gwern.net/docs/cs/algorithm/2001-scott.pdf
* Precise code navigation (vs. more fuzzy-level nav), powered by SCIP (spiritual successor to Grok, the system Steve built at Google)
* More powerful search language beyond regex (supports comby.dev) + user-friendly (smart search)
* Works across multiple GitHub instances + other code hosts (GitLab, Bitbucket, Perforce, enterprise Git repositories)
* Self-hosted deployment and enterprise scale
cs.github.com is a significant improvement over github.com/search—kudos to the team there!—but is about feature parity with something like OpenGrok, Hound, or Google Code Search before Steve built and integrated Grok (primarily cross-codebase regex search).
Rust Dependencies (crates.io) Python Dependencies (PyPI) Go Dependencies NPM Dependencies src.fedoraproject.org JVM Dependencies GitLab.com GitHub Public
and as of yesterday Savannah/GNU - https://github.com/sourcegraph/community/issues/38
More to come.
I want to have source intelligence but I can’t see the biggest chunk of my dev stack to be sourcegraph.
1) How can you write this whole article without saying "Kythe"?
2) How exactly can github search be as bad as it is? With all of Microsoft behind it, you'd think it would be a lot better than it is.
I'll be taking another look at Kythe, and reaching out to the current Grok team, as we expand scip. But ultimately it didn't matter what protocol/format we standardize on. We just need to standardize. So it's scip!
Well, it does discuss Grok (the closed source predecessor) extensively.
Finding a technology preview for a radically improved cross-language code search capability within GitHub was an unexpectedly nice surprise.
Interesting data point for the question: at what point in your career will you stop being asked to write code on a whiteboard to prove you aren't lying on your resume.
Many of us have faltered like this once or twice unless its an outright lie kind of situation.