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. 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. 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. 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. • 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.
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. • When you start your community will be
tiny.
• You need a community multiplier.
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. 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,
web.py, cherrypy, etc. Very Googeable.
• Maybe have some misspelled prefix or
suffix that implies your language
• ex.“Hypreactive” “Escarpmeant”
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. • The iPython Notebook nbviewer is an early
example of such a tool.
• ex. http://nbviewer.ipython.org/gist/
fonnesbeck/2352771
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. 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. 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
