Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I would like to add some basic convenience features to Dafny, such as the ability to define set union in Dafny (see this question). But the internals of Dafny don't seem to be well documented and I don't know where to begin.
How can I add such a feature?
This is an excellent question. I'm not sure why it was downvoted. Thanks for asking. I wish I had known better where to look for information on its internals when I started getting into Dafny.
Rustan has many tutorials/papers/examples on how to use Dafny. (In fact, I would say we suffer slightly from an embarrassment of riches here, because there are so many resources spread over nearly a decade that it can be hard to know where to start. But that's a story for another day.) Also, Dafny is a living project: things change, and so some documents are out of date. You should just prepare yourself for this, and always be willing to open a new file and try things out in modern Dafny.
All that said, there are comparatively few resources about the internals of Dafny. The best way to proceed is to make sure you have a thorough understanding of the theory behind Dafny, and then just read the code. (It's quite good!) Here are some concrete pointers.
The Dafny Reference Manual is essentially an annotated description of the input grammar to Dafny. It was last edited in earnest about two years ago now, so some things are out of date, but it is still invaluable as a mostly exhaustive list of Dafny features. (Please file github issues if you find specific things missing, and we'll try to fix them.) I recommend reading it cover-to-cover.
Check out Rustan's summer school course that give a theoretical presentation of Dafny and Boogie. Also check out this earlier summer school course on Spec#, which, gets many of the same ideas across, but at a more leisurely pace.
Learn to program in Boogie.
Start with the (10 years old, but still 90% accurate) manual This is Boogie 2. Understanding Boogie deeply will help you see, by comparison, what Dafny brings to the table.
Ask Dafny to translate some examples to Boogie for you (using the command-line option /print:foo.bpl), and read the resulting Boogie code.
Read the Boogie test suite to see more examples. Start with the textbook directory. Ignore directories with interesting names.
Also check out this paper on Boogie's more-sophisticated-than-you-might-expect type system. (It goes beyond Hindley-Milner polymorphism!)
Learn at least a little bit about Z3.
Focus especially on how it uses triggers to handle quantifiers. A good introduction to the Dafny-level view of triggers is the paper Trigger Selection Strategies to Stabalize Automatic Program Verifiers.
Ask Boogie to translate some (small) examples to Z3 for you (using the command-line option /proverLog:foo.smt2), and read the resulting Z3 code. This is very hard, but worth it once or twice for your own edification. It can also be occasionally helpful during debugging.
Dig into the Dafny test suite.
Read tests. There are a lot of tests in the test suite, and in many cases is the only place to see a real, live, working example of some feature. If there are features that are not represented in the test suite, please file a Github issue, and we'll try to take care of it.
Learn to run the tests, so that you can test whether your improvements to Dafny break existing programs. (The basic idea is to install the lit testing tool and point it at the Test directory.)
Read the code.
By and large, it's refreshingly good code. The high-level structure is underdocumented, but the low-level structure is usually documented and/or clear. Your job is thus to reconstruct the high-level structure. Start by understanding the different phases of Dafny -- parsing, "resolution"/type checking, translation to Boogie for verification, compilation to C# for execution.
Here's main() for the command-line tool. Trace through and find the phases and read the ones you're interested in.
Ask questions. Unfortunately, there's no great place for concrete, detailed questions about Dafny's internals. Stack Overflow isn't appropriate; neither is Github. Perhaps the best stop-gap is to file "request for documentation" issues on Github, and we'll see what we can do.
I'm hoping Rustan may chime in if there are things I missed.
Good luck, and in words of Rustan: Program Safely!
This page (scroll down to "Dafny") also links to some more papers on Dafny that you might find interesting.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I am currently a Junior going for my Computer Science degree. I am really curious about how things actually work. While I realize that I will never understand everything there is to know about everything, I would love to dive into the basics of a lot of things. There are a lot of such things that I have encountered for my day to day life: machine learning, AI, servers, compilers, etc. However, something that truly amazes me is image process software and the amazing things we have achieved with it to this date.
It seems, however, that no matter where I look, I am not getting a lot insight into how it works, but rather a list of libraries to use (cough OpenCV) instead. While it is great that libraries like this exists, using it defeats the purpose of wanting to learn how things work.
Is there any good resource that someone could recommend regarding image processing or is the best choice I have is to look through existing libraries?
As user T A recommend, buy a good undergraduate-level book about image processing and work your way through it.
Gonzalez and Woods is a commonly used textbook, and you should find it readable.
https://www.pearson.com/us/higher-education/program/Gonzalez-Digital-Image-Processing-4th-Edition/PGM241219.html
How you approach learning the field depends on what learning style you’ve found most effective in the past.
Pick a relatively simple image processing problem, such as counting the number of circles in an image. FIRST, try to solve it yourself. Give that a day or two. Then, if you’re stuck, look for answers in your textbook.
Find a free OpenCV course. At first, try to solve some problems by treating the algorithms (the OpenCV functions) as black boxes: read the documentation, tinker with parameters, try different images, etc., but don’t dig into the algorithms too deeply until you have some sense how the algorithms can be used together at a high level.
Take an undergraduate course. Having a professor or instructor lead you through problems, and the need to make a grade, can help motivation if it sags.
Get an internship at a company that uses image processing in its products. Take ANY internship remotely related to code, then as appropriate ask engineers how things work, what to read, etc.
As a rule, I don’t recommend learning image processing piecemeal reading blogs, etc.
The more you try to solve practical problems on your own, the more you’ll appreciate some of the less appreciated problems in the field. Choosing the right camera, lightening, and other hardware choices becomes important as you try to make an image processing system work more robustly. Many demos you see online won’t work well in real-world situations. (For example, distinguishing objects by their expected color can lead to disappointing results even if the lighting, distance to the object, and orientation of the object change only slightly.)
Above all, try to find some particular problem that interests you: identifying animals; SLAM; facial recognition; predicting events based on video streams; determining the ripeness of fruit; or whatever. Try to find some aspect of image processing that overlaps some other interest of yours: sports, literature, music, theater, social networks, bike racing, animal husbandry, environmental science, or what have you. Once you’ve identified a problem of interest, tackle is problems of increasingly greater complexity.
And if you have more questions, feel free to send me a private message. I’ve been in the field for over two decades, and I like helping steer new folks into the field.
Also: you can get started with Python, Julia, or any of several other languages, but it’s still (as of 2019) common for image processing algorithms to be written in C or C++. So I’d suggest starting with the language you know and like the best, but spend some time practicing C++ as well. Most of the academic papers I read provide algorithms in C or C++, though typically in older style C++ that doesn’t require you to be familiar with C++11 and later.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
We are transitioning across to BDD. Currently using specflow and visual studio to run our automated tests via Jenkins and have over 1000 tests in Quality Centre written in a more traditional fashion of which, the regression tests will be converted to BDD in time.
I'm looking for a repository (similar to test plan in Quality Centre) to house all our test cases/feature files. It must be compatible with Specflow and Jira. What do people use as a manageable test case repository for their tests?
Cheers.
I'm not 100% sure I understand your issue, not being familiar with some of the tools you talk about, but when you have executable specifications your test cases are in the feature files which are stored in the code base. This is part of the point, that your test cases are the things that get executed, so they are always up to date.
What #Sam-Holder said is good; adding to that because I'm familiar with the issue and the tools you're talking about.
You're probably used to the idea that Quality Centre contains a bunch of test scripts, some of which pass and some of which don't (yet).
When you're doing BDD with automated scenarios, they pretty much always pass, all the time. Half the things that QC does simply aren't needed with modern Agile processes.
A pretty common practice is to put the scenarios into the Jira story until they're automated. They're transient. Nobody ever looks at Jira once the story's done. The codebase is the single repository of truth, and anything that lives in Jira gets ignored.
The automated scenarios are checked into the same codebase as the code. If the scenarios go red (fail), the team makes them green ASAP. They provide living documentation for the code. See if you can find someone to show you what Jenkins looks like in action and you'll get a better picture. Commonly the Jira number is added to the check-in comment to provide some level of traceability.
I think it's good practice to keep any manual test cases checked in alongside the automated ones (though please do question why they're not automated; if you automated them in QC you can usually do it with SpecFlow). This helps the test cases (scenarios) to provide living documentation for the code. In fact, getting rid of the word "test" was part of the reason why BDD came about, because BDD's really about analysis and exploration through conversation. It provides tests as a nice by-product.
To answer the question, the most commonly used tool at the moment is Git (at least for newcomers). It's version control that the devs are using. SVN / Mercurial are also OK flavours of version control. Get the devs to help you.
If you're still working in a silo and not talking to the devs, don't use BDD tools like SpecFlow - you'll find them harder to keep up-to-date, because your steps will probably be too detailed and English is trickier to refactor than code.
Better still, use the BDD tools and go talk to the devs and the BAs / SMEs / Product Owner who understands the problem. Get them to help you write the scenarios. When you start having the conversations, even over legacy code, you'll start understanding why BDD works.
Here's a blog post I wrote on using BDD with legacy systems that might also be helpful to you. Here's a blog post on the BDD lifecycle: exploration, specification and test by example. And here's one to get you started on how to derive that "Given, When, Then" syntax using real conversations.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What questions can I ask an interview candidate that would allow me to know whether he's a "copy-and-paste coder"?
We're finding that even when candidates answer coding questions well in an interview, once on the job they'll still tend toward copying rather than refactoring.
Anyone else have similar experiences?
The first step in our interview process is a 5-minute online question. We give the candidates something like "FizzBuzz" or "Recursive fibonacci" or "Find factorial of n".
We don't have any rules. Nothing about pasting, or the code needing to compile, or what language it should be in - just do it. The 5-minute timeframe forces most candidates down one of two roads - write some pseudocode (or mostly-working code), or Google it.
When we get the answer, we Google the answer. Roughly half the time, it's been copied from some site. Our expectation is that if they spent 5 minutes finding the answer on Google, it should not only compile but it should be the absolute cleanest, best example of a solution for that problem out there. About half the time, the pasted answers are utter crap. We even get a number that didn't paste the entire snippet in, missed a whole chunk!
Copy-pasters tend to be exposed when they don't have a compiler to check them. Their modus operandi is paste, compile, tweak, compile. If they just paste a solution from a web page into another web page and submit it, they have nothing telling them they need to fix it.
This has worked extremely well - no one has made it to the phone screening who shouldn't.
I have people describe (in detail) a hard problem than they were proud of having solved. It's pretty easy to tell if they never really understood the details or simply hadn't worked through the problem themselves. Enthusiasm (sparkle even!) while describing the solution is a big plus. Gotta have a love for problem solving!
I've had this problem with candidates as well. The trick is to reduce the number of questions that only rely on definitions. You can provide them with code that needs refactoring and ask them what they would do to improve the code. This is a very open-ended question that shows how the candidate thinks.
A lot of interviewers like to ask questions where the candidate writes new code, unfortunately it is rare that developer is writing new things from scratch. Focus more on presenting existing code to the candidate and asking them to work with it to solve a problem.
Even with these questions it is possible to get a copy-and-paste coder as an interview is not necessarily how they will act in the real world.
That's my two cents.
I have two approaches, and always use both of them. They take fifteen minutes total, and I use them as the last third of an entry-level job interview.
Ask a very simple question based in theory.
"Are you familiar with the Vector class in Java? Write in pseudocode an implementation of the class supporting add, get, and clear." If they're not familiar, ask about ArrayList. If they're not familiar on either, explain what they do. The idea is that they can write a
linked list, and know what one is.
If I'm unsure at that point, ask them to write a method to sort the list manually; no using Arrays.sort() or similar. Have them explain a sorting algorithm. I don't care which one they choose, I don't care how efficient it is, any will do.
"What's the last thing you wrote that you were proud of?"
We wrote a test that basically checks to see if someone knows how/why to refactor.
We created a simple mockup application (allow the user to create predefined shapes and move them around on the screen) but introduced many types of errors on purpose.
One of these was copy & paste coding (the same functionality repeated in multiple places). Another was to embed logic for each shape into the event handlers. Terrible, terrible stuff - the worst ideas we could think of.
This allows us to see whether the candidate would recognize the opportunities for improvement and which approaches they would take to solve them.
It was a take home test and the candidate could either rewrite the application or provide notes on what kinds of changes they would make.
Not that this excuses it, but one reason developers may copy and paste code is that they don't understand the code that they're working with. For example, if you hire a C# or Java developer, and put him on a Fortran system and tell him to get work accomplished, he is going to copy and paste throughout that system due to lack of understanding.
In addition that that, quality of code can play a part in this. I know of one particular system that was not allowed to be refactored, but new changes had to be introduced. The developers had to do what they had to do to get the task done in a timely manner.
Of course, both of these scenarios don't excuse copy and paste coding, but it's worth a look inside the organization to understand why this may happen.
Don't ask common questions and/or ask them to explain their code.
You could modify your approach a bit. Do your tech review and phone screen, sure, just up the challenge of your coding test. Instead of asking simple programming test questions as a pre-screen, come up with a fairly complex programming project that they can solve - something can be scrounged up pretty quickly that can be pretty much ungoogle-able. Give them time after the interview to complete it, and require that it be well document and easy to understand. Then schedule a follow-up where you discuss the solution and ask the candidate things such as "What were you thinking here?!"
Examples of the types of projects of which I am thinking:
Write a program that plays a single hand of poker among three players
Write a flood-fill program for a random field provided by the user
Write a small check register program that accepts input from a .CSV and a starting balance, and outputs the current balance, allowing the user to view the transactions that have been read.
If they are on-site, make them whiteboard something. Lets you see how they will divide-and-conquor a problem in abstract. Watch what they focus on, what they omit, ask questions as they continue, and if you want to be a little evil - change the rules halfway through.
Break out parts of it and have them write the pseudocode on the whiteboard.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I've been browsing Bjarne Stroustrup's new introductory programming book, Programming: Principles and Practice Using C++. It's meant for first-year university computer science and engineering students.
Early on in the book he works through an interesting extended example of creating a desktop calculator where he ends up implementing an arithmetic expression evaluator (that takes bracketed expressions and operator precedence into account) in a series of co-recursive functions based on a grammar.
This is a very interesting example, although arguably on the complex side for a lot of beginners.
I wonder what others thing of this particular example: would learning programming by seeing how to implement an expression parser excite and motivate you, or would it discourage you because of all the details and complexity?
Are there other good "real" programming examples for beginners?
When I was first learning to program, the best example I ever worked with was building a text adventure game from scratch. The basics just required knowing how to display text on the screen, receive input from the keyboard, and rudimentary flow control. But since text adventures always have room to add more features/puzzles/whatever, they can be easily adapted to explore aspects of whichever language you're learning.
Of course, not everyone finds games more interesting than calculators. It really depends on the programmer.
First, let me say that cognitive psychologists have proven in numerous studies that the most important factor in learning is desire to know.
If you want to learn about programming, you need to find a domain that stokes your desire to understand. Find a challenge that can be solved with programming.
I agree with the other folks when they suggest something that you are interested in. And games seem to be a common thread. As I reflect on my experience learning to program (too many years ago), math problems and a simple game was involved.
However, I don't think I really understood the power of software until I created a useful small program that helped a business person solve a real problem. There was a tremendous amount of motivation for me because I had a "client". I wasn't getting paid, but the client needed this program. There was sincere pain (gotta get my job done quicker) related to this situation.
So my advice is to talk to people you know and ask what small annoyance or computer-related obstacle to they have. Then try to fix it. It may be a simple web widget that reduces repetitive, manual tasks for an office worker.
One of my best early works was helping a little printing shop (no software, circa 1985) that struggled with estimating jobs to produce proposals that weren't money-losers. I asked alot of questions of the sales lady and of the operations manager. There was obviously an intersection of a common pain point with a really easy calculation that I could automate. It took me a couple of days to learn Lotus 1-2-3 (spreadsheet for you young-uns) enough to write a few macros. I was motivated. I had passion. I saw where I could make a difference. And that, more than anything else, drove me to learn some simple programming.
Having real people, real problems, and really simple solutions could be the inspiration you need as a beginning programmer. Don't try to write an accounting system. Just take one discreet piece of someone's frustration away. You can build on that success.
So, I wouldn't focus on the technique (yet). Don't worry about, "Am I doing this the most efficient way?" The main objective for a beginner is to have success, no matter how small, and build confidence.
BTW, that Lotus 1-2-3 set of macros grew into a full job tracking system. Very archaic, limited features, but made that little print shop much more profitable.
Create your motivation, fuel your desire, and develop your passion for programming like an artist unveils the masterpiece in a blob of clay. And be persistent. Don't give up when challenged with a roadblock. We all get stumped sometimes. Those are some of the best learning moments because humans learn more from failure than success.
Good luck.
I think making tiny games like text version of Tetris will be a good way of getting into pragramming world.
Board games are fun to design and code since they come in many shapes and difficulties
from tic-tac-toe to checkers to monopoly, its reinventing the wheel for educational purposes!
the best advice i can think of is to pick something from a field of interest you have because coding for the sake of coding might dim your resolve
Start small. Do examples that interest you. Stretch yourself just a little every time. Get comfortable with each step, to the point that you have confidence that you know what you're doing, and then try something a little harder the next time.
I think that any example program would help you learn a new language, but a beginner should try to work with something that is easy to understand in the real world, such as a mortgage calculator or something along those lines.
I think the answer is that it would depend on the person who is learning how to program.
One nice thing about something like an arithmetic expression evaluator is that it is a project that can start very small (make it work with just the format "X SYMBOL Y" where X and Y are single-digit numbers and SYMBOL must be a plus sign) and then you are slowly expanding the functionality to the point of a complicated system.
However, it might not be a great starter project for someone who doesn't really understand the concept of computers (hard disk, memory, etc.)
Try to think of something that you do on a computer that is repetitive, and could be easily automated. Then try to come up with how to make a program that automates that task for you. It can be anything, whether it's popping up a reminder every 15 minutes to stretch your legs or cleans up your temp directory on a regular basis.
The problem with this task is that it's conplex and not real life related. I don't need another calculator.
But once I had a CD with scratched surface near its center and lots of valuable JPEG files inside. I dumped the data from the unscratched part of the disk but all the filesystem was surely lost. So I wrote a program which analysed the dump and separated it into files. It was not very simple but was a nice and exciting file IO programming exercise.
Examples can be more complex than something you try to write yourself. It's easier to follow someone else doing something than it is to do it yourself. A real-world example like this calculator may be a fine way to introduce someone to a language. For instance, Practical Common Lisp starts with an example of an in-memory database (for CDs I think) and uses that as the springboard to explore parts of the language.
I prefer seeing a real example built up over time than just a lot of simple "Hello World" programs.
I've always found that implementing a game of some sort is sufficient incentive to learn various features of a language. Card games, especially, because they generally have simple rule sets to implement, but are sufficiently complex from an abstract point of view.
I would agree, though, with everyone else: find examples of things that interest you. Not everyone is a game fan, but something like a mortgage calculator would be far more interesting.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In pair programming, the experience of every member of the team can be spread to new member. This experience is always in sync with the code, because the "senior" of the pair knows how the code works and what the design is.
So what is the utility of design documentation in this case ?
UPDATE
I don't imply no design, I imply no documentation.
With a team which practice pair programming I think that everybody is disposable, because everybody knows the code. If the senior developer leaves, I think that there is always at least one person who knows the code, because the experience was shared before.
What if your team is larger than 2 persons?
Just because two people know a part of a system does not mean it shouldn't be documented.
And I would be glad to know that I don't have to remember every tiny detail of a system just because it it's stored nowhere else than in my head.
For a small system this might work, but as the system gets larger, your limiting yourself and your colleagues. I'd rather use the memory capacity for a new system than to remember everything of the old system.
Have you ever played "telephone?" I don't think you should play it with your codebase.
What if the senior programmer leaves the company/project?
The set of deliverables should be decided independently of whether you use pair programming or not.
Six months or two years later, all the people involved could be in a different project (or a different company). Do you want to be able to come back and use the design documentation? Then, produce it. If you don't want to come back, or the design is simple enough that with the specs and the code you can understand it without the aid of an explicit design document, then you may skip it.
But don't rely on the two people explaining the design to you one year later.
Maintenance. You can't expect the team to remain static, for there to be no new members or loss of old members. Design documentation ensures that those who are new to the project, that have to maintain it years down the line, have information on decisions that were taken, why the approach was chosen, and how it was to be implemented. It's very important for the long term success of a project to have this documentation, which can be provided via a combination of traditional documents, source comments, unit tests, and various other methods.
I don't see that pair programming makes design documentation obsolete. I immediately have to think about the Truck factor. Sure, the senior may know what the design is. But what happens when he is ill? What happens when he gets hit by a truck? What if he is fired?
Pair programming does spread knowledge, but it never hurts to document that knowledge.
Who knows about the first-written code? The answer is nobody knows, because it hasn't been written. The reason it hasn't been written is because nobody knows what to do, hence the need for a design document.
Pair programming is just two people sharing one computer. By itself, it says nothing about what kind of design methodology the pair(s) uses.
Pair programming, when taking as part of "Extreme Programming", means following the Extreme Programming guidelines for design. This typically involves gathering and coding to "user stories". These stories would then stand in place of other design documentation.
The experience of people may be in sync with the code, as you say. But the design decisions are not all captured in the code - only the choices made are there.
In my experience, to really understand why code is designed the way it is, you need to know about the design choices that were not selected, the approaches that had tried and failed etc. You can hope that the "chinese whispers" chain transmits that correctly, given that there's no record of this in the code to refresh memories or correct errors...
... or you can write some documentation on the design and how it was arrived at. That way, you avoid being taken down a dark alley by the maintenance programmers in future.
Depends what you mean by "design documentation".
If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.
If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...
Those are the two main forms of documentation I've used in XP teams that pair on all production code.
The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.
The code base may be so large you can't humanly remember every detail of what you were intending to implement. A reference is useful in this case.
Also, you need a design if you are interacting with other components etc.
Well if you want a spreadsheet program instead of a word processor a design doc use useful :-)
XP, pair programing, agile, etc... do not mean you do not have a plan, it is just a far less detailed plan (at the micro level) of what is going on. The use cases that the user picks are more of the design, and it is more of a living document than with other styles of design/programming.
Do not fall into the trap that because youa re doing something "cool" that you no longer need good practices - indeed this style of programming requires more discipline rather than less to be successful.
Pair programming is an opportunity for the team to avoid having to spend a large proportion of the project time on documenting everything. But the need for documentation depends on how good you are at remembering the important stuff and how good your code is. You may still want lots of documentation if the code is difficult to work with.
You could try some experiments:-
Document a couple of small parts of
the design and note how often you
have to refer to it.
Document stuff that is always a pain
to work with.
No Nor does lack of pair programming mean you need documentation. Documentation is needed! What it looks like may surprise you!
An agile team will decide when and what documentation is needed. A good rule of thumb, if no one is going to read it, don't write it. Don't get caught up in the waterfall artifact thinking by provide artifacts because the Project Manager says so.
Most think of documentation as something you do with Word. If an agile team is working properly, the code itself, with TDD (test driven development) will have a set of automated test that document and enforce the requirements. Image, documentation that is in sync with the code ... and it stays that way.
Having said that, pairing does help domain, application, practice and skill knowledge propagate through the team very quickly. Pairing also helps ensure that the team follow the engineering practices including TDD and other automated test. The results are that the application remains healthy and future change is easy to bring about.
So, bottom line, pair programming produces better documentation. It does not eliminate documentation (although you might not be able to find a Word document).
I am a pro-advocate and a fan of documentation. Pair programming does not require "one senior developer". In my experience with pair programming, developers of all levels are paired together, for the purpose of rapid development. There are many times I worked with junior developers and would trade off on the keyboard. There are many times I worked with senior architects and would trade off on the keyboard. Documentation is still necessary, especially with your core components and database.
Pair Programming only enables your coding and logical aspect.
But documentation is good practice. Always do documentation...