diegoeche

;; Gist
(require 'gist)

diegoeche

sealed case class Sphere (center:Vector3d , radius: Double)
{
  val center = center;
  def intersect (): Option [(Vector3d)]= {
    return Some(this.center);
  }

}

diegoeche

import javax.vecmath._;

case class Sphere(center:Vector3d , radius: Double) {

  def intersect (): Option [(Vector3d)]= {
    return Some(this.center);
  }

}

diegoeche

Cuando un proyecto (de software) uno lo empieza a hacer con otra gente, y uno no sabe
si las ideas sobre la api estan bien o depronto de un día para otro le da a uno por
reescribir toda la API porque descubrió una forma mas linda. O no se tenían coding
guidelines y se establecen. Vale la pena haber hecho una documentación seria?

Ahí miré los casos que ponés. Rails vs la api que mostras ¿Qué proyecto está mas
maduro? ¿La documentación de emacs que tanto riesgo tiene de quedarse obsoleta de un
día para otro?

A mi una wiki me parece una buena forma de empezar a documentar un proyecto en sus

diegoeche

;; Exercise 1.19 of SICP

(define (fib n)
  (fib-iter 1 0 0 1 n))

(define (fib-iter a b p q count)
  (cond ((= count 0) b)
        ((even? count)
         (fib-iter a
                   b

diegoeche

(define (fib n)
  (fib-iter 1 0 0 1 n))
 
(define (fib-iter a b p q count)
  (cond ((= count 0) b)
        ((even? count)
         (fib-iter a
                   b
                   (+ (* p p) (* q q))
                   (+ (* q q) (* 2 p q))

diegoeche

*Main> (perm [3]) :: Maybe [Int]
Just [3]
*Main> (perm [3]) :: [[Int]]
[[3]]

diegoeche

import Control.Arrow
import Data.List
import Data.Ord

articles = ["Crimen y castigo", 
            "Humillados y ofendidos",
            "Fin de la Eternidad",
            "Siberiada"]

matches x = length

diegoeche

import Control.Arrow
import Data.List
import Data.Ord
import Text.Regex.Posix

articles = ["Crimen y castigo", 
            "Humillados y ofendidos",
            "Fin de la Eternidad",
            "Siberiada"]

diegoeche

Djkstra - “Goto Statement Considered harmful” - which raised the innovative claim that programs ought to be easy to reason about, and language elements that made them hard to reason about were bad Wirth - “Program development by stepwise refinement” - which pointed out that a program is a series of design decisions, and these decisions give rise to a family of related programs, corresponding to different design choices. Parnas - “Information Distribution Aspects of Design Methodology”. I haven’t read this one! I thought I had read all his papers. It sounded a lot like his modularity paper. “The connections between modules are the assumptions that the modules make about each other.” Liskov - “A Design Methodology for Reliable Systems” Balzer - Dataless Programming - I read this one a long time ago but I don’t remember it and ought to read it again Dahl and Hoare - Hiearchical Program Structures”, in “Structured Programming” from 1972. She said there were three very good papers in this book. I