(define (pascal n)
      (if (= n 0) (list 1)
       (begin
       (let ((L (pascal (- n 1)))
           (ret (list 1))) 
       (do ((i 0 (+ i 1)))
           ((= i (- (length L) 1)))
           (begin (set! ret (append ret (list (+ (list-ref L    i) (list-ref L (+ i 1))))))))
       (append ret (list 1))
        ))))

This is better scheme:

(define (pascal n) (if (= n 0) (list 1) (let ((L (pascal (- n 1)))) (append (list 1) (map + (cdr L) L) (list 1)))))

As for your particular questions:

1. map yields an error under mzscheme

I'm at work, and didn't have access to a proper scheme, so I used an online REPL[1], which apparently is more forgiving. Regardless, you can write your own map (a good exercise!) that stops as soon as one of the arguments is exhausted. Make it tail-recursive[2] as well!

2. list-ref is bad

Lists are beautiful data structures designed for recursive algorithms. If you are using lists and not using recursion (or a hidden recursion in the form of map), you're doing something wrong. list-ref uses list as a vector, which has a performance implications - your algorithm is O(n^3) while mine is O(n^2).

3. set! is bad

Margins are too small for a proper explanation :), but basically set! has side-effects[3], and functional programming should avoid having them.

Have fun learning Scheme!

[0] http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-9.html#... [1] http://www.bluishcoder.co.nz/jsscheme/ [2] http://en.wikipedia.org/wiki/Tail_call [3] http://en.wikipedia.org/wiki/Side_effect_(computer_science)

(define next (lambda (l) (if (null? (cdr l)) '(1) (cons (+ (car l) (cadr l)) (next (cdr l))))))

(define pascal (lambda (n) (cond ((< n 1) '()) ((= n 1) '(1)) (else (cons 1 (next (pascal (- n 1))))))))

Here's mine:

  #include <stdio.h>
  #include <stdlib.h>

  long *pascal(int row) {
    long *ret = (row == 1 ? NULL : pascal(row - 1));
    ret = realloc(ret, sizeof(long) * row);
    ret[row - 1] = 1;
    for (int i = row - 2; i > 0; i--)
      ret[i] += ret[i - 1];
    return ret;
  }

  int main(int argc, char *argv[]) {
    int row = atoi(argv[1]);
    long *data = pascal(row);
    for (int i = 0; i < row; i++)
      printf("%ld ", data[i]);
    printf("\n");
    free(data);
    return 0;
  }

I ran your code and it does run well. However fails for large cases such as pascal(200000).

You mentioned you worked for Google and Amazon, how can you modify the code to get an answer for pascal(200000)

  1. use double to get approximately-correct answers
  2. use an abitrary-precision library like GMP

  #include <stdio.h>
  #include <stdlib.h>

  int main(int argc, char *argv[]) {
    int row = atoi(argv[1]);
    long data[row];
    for (int i = 0; i < row; i++) {
      data[i] = 1;
      for (int j = i - 1; j > 0; j--) data[j] += data[j - 1];
    }
    for (int i = 0; i < row; i++) printf("%ld ", data[i]);
    printf("\n");
    return 0;
  }

Edit: To down voters I think this question is important because it helps us understand why certain softwares are successful despite other successful competitors. I am not trying to start a flame war on which version control system is better.

Socially, it first had a big userbase because the kernel is a large enough project and the switch was made top-down as far as I remember (not everybody was forced to do it but it was much easier if you could). This means a lot of people had to get acquainted with it, and this set of people turned out to be somewhat competent at changing it to make it faster, more stable, and easier to use (up to a point). Linus's personality played an important role here, as he entertainingly made a case for why it was good, which created a certain "cool factor". Second, there was the github factor which allowed this user base to explode exponentially by making it really cheap and easy to use.

1. By being "stupid", git doesn't treat the user as stupid.

2. git allows repositories to be uploaded or transferred anywhere for others to use with a single, simple command.

3. git is efficient and fast. No one likes waiting for their computer to do a seemingly easy task -- especially software developers/hackers who know something should be O(1) complexity and could be written in X lines of code.

4. Merging/branching is easy.

1. Celebrity nerd Torvalds creates a vcs. It is not terrible.

2. Linux development moves to git.

3. Rails development moves to git.

4. Github.

That said, the answer IMO seems to have something to do with the fact that some very important communities ready for a different VCS model, and some very good and influential developers answered that call at roughly the right time. For example, both Mercurial and Git were started in direct response to the Linux Kernel having their bitkeeper license revoked.

Github is really a killer app for git, and that's probably one reason it's gotten as popular as it has.

I picked up git because I know I needed to use SOMETHING for version control. Looking around a few years back I saw CVS, SVN, and the rest.

So I Google/ask around. I see that git is getting mentioned pretty regularly. I also see Hg being mentioned. I basically search for free hosting for both. Github just seemed more friendly. The UI was bigger and easier to read than bitbucket. So I just went with git.

Often it is the stupid reasons that people adopt something: it looks nicer, my friends are using it, I can pronounce the name.

Maybe less but still important IMHO is that it's far more pronounceable than e.g. SVN. That could help build the hype.

"Git" is definitely a nice name.

http://www.urbandictionary.com/define.php?term=git

This is partly why I have, so far, not joined the "Git Hub".

All in all, I think a better name could have been chosen. But, most of the time, I only type it - and it IS certainly nicer to type than `svn', I'll give it that.

  DOOM 1.3.1.1304-debug linux-x86 Nov 24 2011 00:27:04
  found interface lo - loopback
  found interface eth0 - 10.0.0.19/255.255.255.0
  ------ Initializing File System ------
  Current search path:
  /home/xx/.doom3/base
  /home/xx/doom3.gpl/neo/base
  game DLL: 0x0 in pak: 0x0
  Addon pk4s:
  file system initialized.
  --------------------------------------
  ----- Initializing Decls -----
  ------------------------------
  ------- Initializing renderSystem --------
  idRenderSystem::Shutdown()
  Sys_Error: _default material not found

  DOOM 1.3.1.1304-debug linux-x86 Nov 24 2011 00:27:04
  found interface lo - loopback
  found interface eth0 - 10.0.0.19/255.255.255.0
  ------ Initializing File System ------
  Current search path:
  /home/xx/.doom3/base
  /home/xx/doom3.gpl/neo/base
  game DLL: 0x0 in pak: 0x0
  Addon pk4s:
  file system initialized.
  --------------------------------------
  ----- Initializing Decls -----
  ------------------------------
  ------- Initializing renderSystem --------
  idRenderSystem::Shutdown()
  Sys_Error: _default material not found

or zlib-dev if your distribution separates out development packages