Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Search-Driven Programming


Published on

  • Be the first to comment

  • Be the first to like this

Search-Driven Programming

  1. 1. Search-driven programming and how to design your language for it
  2. 2. Search-driven programming • Get an error? Copy and paste the error into Google. In milliseconds you often have the answer to what you did wrong • SDP is very fast and flow-friendly • Everyone these days knows programming is a pretty social and even collective activity • Surrender to the hive-mind! !
  3. 3. But actually are many hive-minds • One hive per language / tool. • (To the extent that there is crossover across languages and tools that’s mostly called the standard CS curriculum.)
  4. 4. Community intelligence: two measures • The old way: μ (average knowledge) • Whoever was nearest to you to talk about your problem • The SDP way: Σ (aggregate knowledge) • Google search sums the intelligence of a community
  5. 5. A very big deal • In my opinion this is the biggest thing in human knowledge of the past 1000 years • But language designers haven’t noticed yet
  6. 6. • A community has some programmers’ mistakes documented in Google-searchable space, often with solutions • No matter what you dumb thing you did with Ruby on Rails, there is someone on a blog or StackOverflow who already did it and posted a decent answer about how to fix it.
  7. 7. So, a big community is one way to win
  8. 8. Implications for language designers
  9. 9. Implications for language designers • Solved problems in Googledspace are part of what your language has to offer • Arguably the most heavily used ‘feature’ • More important than having a good Emacs mode or whatnot • Sadly this helps the incumbent languages
  10. 10. • When you start your community will be tiny. • You need a community multiplier.
  11. 11. • Attract prolix programmers. Exhibitionist hackers. • Your model here is mid 2000s Ruby community. So many presentations, so much blogging! • (Non-SDP benefit: the best lib wins much faster in a prolix community.) • How? Set a culture that attracts them. Write! Blog sloppily so that everyone feels like dashing off a quick, underedited post is 'what we do here’.
  12. 12. What’s your dog whistle? • Get your naming unique - both the language's name and its libs • Maybe dream up a lib naming convention that makes this very likely • Python is your model. Numpy, SciPy,, cherrypy, etc. Very Googeable. • Maybe have some misspelled prefix or suffix that implies your language • ex.“Hypreactive” “Escarpmeant”
  13. 13. Design community boosting into the language • Or at least its tools • ex. when in ‘dev mode’, any error message / stack trace includes a URL that creates a blog post with that stack trace + context. Paste in the code you changed to provide the solution. • Or write something that can turn any git commit in your language into a blog post • Post-commit hook?
  14. 14. • The iPython Notebook nbviewer is an early example of such a tool. • ex. fonnesbeck/2352771
  15. 15. • It might work to establish a culture where the error message due to some bug that you are getting should go into git commit messages or pull request description. GitHub hides long messages but they are in the HTML :) • Here you are fighting the standards and culture of git and GitHub Less ambitious: cultural conventions
  16. 16. The 1000X community multiplier dream • The goal: EVERY time someone fixes their bug, leave a trail in Googleable space that others can follow • Whatever new language makes this happen first is the new dominant language
  17. 17. Questions worth asking • Why is there so much less sysadmin-ish stuff blogged and StackOverflow-ed, compared to programming-ish stuff? • (I think it’s cultural) • Could you make community tools first class citizens in your language? • If your editor is within a browser, you probably could and should do this