Your SlideShare is downloading. ×
0
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Impossible Programs
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Impossible Programs

158

Published on

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/Sr11RI. …

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/Sr11RI.

Tom Stuart uses code to tell a nail-biting, maths-free story about the source of a computer's power, the inevitable drawbacks of that power, and the impossible programs which lie at the heart of uncomputability. Filmed at qconlondon.com.

Tom Stuart is a computer scientist and programmer. He works as a consultant, mentor and trainer, helping companies to improve the quality and clarity of their approach to creating software products, usually on the web. He has lectured on optimising compilers at the University of Cambridge, co-organises the Ruby Manor conference, and is a member of the London Ruby User Group.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
158
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. IMPOSSIBLE PROGRAMS @tomstuart / QCon London / 2014-03-05
  • 2. InfoQ.com: News & Community Site • 750,000 unique visitors/month • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • News 15-20 / week • Articles 3-4 / week • Presentations (videos) 12-15 / week • Interviews 2-3 / week • Books 1 / month Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations /programming-limitations
  • 3. Presented at QCon London www.qconlondon.com Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide
  • 4. CAN’T DO PROGRAMS EVERYTHING
  • 5. how can a PROGRAM be IMPOSSIBLE?
  • 6. WE DEMAND UNIVERSAL SYSTEMS
  • 7. Compare two programming languages, say Python and Ruby.
  • 8. We can translate any Python program into Ruby. We can translate any Ruby program into Python. We can implement a Python interpreter in Ruby. We can implement a Ruby interpreter in Python. We can implement a Python interpreter in JavaScript. We can implement a JavaScript interpreter in Python. We can implement a Turing machine simulator in Ruby. We can implement Ruby as a Turing machine.
  • 9. JavaScript Ruby Python Lambda calculus Turing machines SKI calculus Tag systems Partial recursive functions Game of Life Rule 110 C++ Haskell Lisp Register machines Magic: The Gathering C Java XSLT
  • 10. Universal systems can run software. We don’t just want machines, we want general-purpose machines.
  • 11. PROGRAMS ARE DATA
  • 12. >> puts 'hello world' hello world => nil >> program = "puts 'hello world'" => "puts 'hello world'" >> bytes_in_binary = program.bytes. map { |byte| byte.to_s(2).rjust(8, '0') } => ["01110000", "01110101", "01110100", "01110011", "00100000", "00100111", "01101000", "01100101", "01101100", "01101100", "01101111", "00100000", "01110111", "01101111", "01110010", "01101100", "01100100", "00100111"] >> number = bytes_in_binary.join.to_i(2) => 9796543849500706521102980495717740021834791
  • 13. >> number = 9796543849500706521102980495717740021834791 => 9796543849500706521102980495717740021834791 >> bytes_in_binary = number.to_s(2).scan(/.+?(?=.{8}*z)/) => [ "1110000", "01110101", "01110100", "01110011", "00100000", "00100111", "01101000", "01100101", "01101100", "01101100", "01101111", "00100000", "01110111", "01101111", "01110010", "01101100", "01100100", "00100111"] >> program = bytes_in_binary.map { |string| string.to_i(2).chr }.join => "puts 'hello world'" >> eval program hello world => nil
  • 14. UNIVERSAL SYSTEMS +PROGRAMS ARE DATA =INFINITE LOOPS
  • 15. Every universal system can simulate every other universal system, including itself. More specifically: every universal programming language can implement its own interpreter.
  • 16. def evaluate(program, input) # parse program # evaluate program on input while capturing output # return output end
  • 17. >> evaluate('print $stdin.read.reverse', 'hello world') => "dlrow olleh"
  • 18. def evaluate(program, input) # parse program # evaluate program on input while capturing output # return output end def evaluate_on_itself(program) evaluate(program, program) end
  • 19. >> evaluate_on_itself('print $stdin.read.reverse') => "esrever.daer.nidts$ tnirp"
  • 20. def evaluate(program, input) # parse program # evaluate program on input while capturing output # return output end def evaluate_on_itself(program) evaluate(program, program) end program = $stdin.read if evaluate_on_itself(program) == 'no' print 'yes' else print 'no' end does_it_say_no.rb
  • 21. $ echo 'print $stdin.read.reverse' | ruby does_it_say_no.rb no $ echo 'print "no" if $stdin.read.include?("no")' | ruby does_it_say_no.rb yes $ ruby does_it_say_no.rb < does_it_say_no.rb ???
  • 22. does_it_say_no.rb yes no never finish other output? does_it_say_no.rb ✘ ✔✘ ✘
  • 23. Ruby is universal so we can write #evaluate in it so we can construct a special program that loops forever
  • 24. so here's one PROGRAM IMPOSSIBLE
  • 25. Sometimes infinite loops are bad. We could remove features from a language until there’s no way to cause an infinite loop.
  • 26. remove while loops etc, only allow iteration over finite data structures to prevent (λx.x x)(λx.x x) e.g. only allow a method to call other methods whose names come later in the alphabet • No unlimited iteration • No lambdas • No recursive method calls • No blocking I/O • ...
  • 27. The result is called a total programming language. It must be impossible to write an interpreter for a total language in itself.
  • 28. if we could write #evaluate in a total language so it must be impossible to write #evaluate in one then we could use it to construct a special program that loops forever but a total language doesn’t let you write programs that loop forever
  • 29. (That’s weird, because a total language’s interpreter always finishes eventually, so it feels like the kind of program we should be able to write.)
  • 30. We could write an interpreter for a total language in a universal language, or in some other more powerful total language.
  • 31. ABOUT REALITY? WHAT okay but
  • 32. #evaluate is an impossible program for any total language, which means that total languages can’t be universal. Universal systems have impossible programs too.
  • 33. input = $stdin.read puts input.upcase This program always finishes.* * assuming STDIN is finite & nonblocking
  • 34. input = $stdin.read while true # do nothing end puts input.upcase This program always loops forever.
  • 35. Can we write a program that can decide this in general? (This question is called the halting problem.)
  • 36. input = $stdin.read output = '' n = input.length until n.zero? output = output + '*' n = n - 1 end puts output
  • 37. require 'prime' def primes_less_than(n) Prime.each(n - 1).entries end def sum_of_two_primes?(n) primes = primes_less_than(n) primes.any? { |a| primes.any? { |b| a + b == n } } end n = 4 while sum_of_two_primes?(n) n = n + 2 end print n
  • 38. def halts?(program, input) # parse program # analyze program # return true if program halts on input, false if not end
  • 39. >> halts?('print $stdin.read', 'hello world') => true >> halts?('while true do end', 'hello world') => false
  • 40. def halts?(program, input) # parse program # analyze program # return true if program halts on input, false if not end def halts_on_itself?(program) halts?(program, program) end program = $stdin.read if halts_on_itself?(program) while true # do nothing end end do_the_opposite.rb
  • 41. $ ruby do_the_opposite.rb < do_the_opposite.rb
  • 42. do_the_opposite.rb eventually finish loop forever do_the_opposite.rb ✘ ✘
  • 43. Every real program must either loop forever or not, but whichever happens, #halts? will be wrong about it. do_the_opposite.rb forces #halts? to give the wrong answer.
  • 44. if we could write #halts? so it must be impossible to write #halts? then we could use it to construct a special program that forces #halts? to give the wrong answer but a correct implementation of #halts? would always give the right answer
  • 45. WHO CARES? okay but
  • 46. We never actually want to ask a computer whether a program will loop forever. But we often want to ask computers other questions about programs.
  • 47. def prints_hello_world?(program, input) # parse program # analyze program # return true if program prints "hello world", false if not end
  • 48. >> prints_hello_world?('print $stdin.read.reverse', 'dlrow olleh') => true >> prints_hello_world?('print $stdin.read.upcase', 'dlrow olleh') => false
  • 49. def prints_hello_world?(program, input) # parse program # analyze program # return true if program prints "hello world", false if not end def halts?(program, input) hello_world_program = %Q{ program = #{program.inspect} input = $stdin.read evaluate(program, input) print 'hello world' } prints_hello_world?(hello_world_program, input) end
  • 50. if we could write #prints_hello_world? so it must be impossible to write #prints_hello_world? then we could use it to construct a correct implementation of #halts? but it’s impossible to correctly implement #halts?
  • 51. Not only can we not ask “does this program halt?”, we also can’t ask “does this program do what I want it to do?”.
  • 52. This is Rice’s theorem: Any interesting property of program behavior is undecidable.
  • 53. WHY HAPPEN? DOES THIS
  • 54. We can’t look into the future and predict what a program will do. The only way to find out for sure is to run it. But when we run a program, we don’t know how long we have to wait for it to finish. (Some programs never will.)
  • 55. Any system with enough power to be self-referential can’t correctly answer every question about itself. We need to step outside the self-referential system and use a different, more powerful system to answer questions about it. But there is no more powerful system to upgrade to.
  • 56. HOW COPE? CAN WE
  • 57. • Ask undecidable questions, but give up if an answer can’t be found in a reasonable time. • Ask several small questions whose answers provide evidence for the answer to a larger question. • Ask decidable questions by being conservative. • Approximate a program by converting it into something simpler, then ask questions about the approximation.
  • 58. StuartUnderstandingComputation From Simple Machines to Impossible Programs Tom Stuart Understanding Computation eilly.com tter: @oreillymedia ebook.com/oreilly m Stuart, a computer entist and programmer, he founder of Codon, a gital product consultancy London. He works as a nsultant, mentor, and iner, helping companies improve the quality and rity of their approach to eating software products.
  • 59. From Simple Machines to Impossible Programs Tom Stuart Understanding Computation THE END QCON(50% off ebook, 40% off print) http://computationbook.com/ @tomstuart / tom@codon.com
  • 60. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations/programming -limitations

×