Proyectos (era Re: Problemas con GTK)

[Alvaro Herrera]

Horst von Brand escribio:
> Alvaro Herrera <alvherre en alvh.no-ip.org> wrote:
> > Ricardo Mun~oz A. escribio:
> > > El vie, 07-10-2005 a las 17:17, Franco Catrin escribió:
> > > > El tiempo no solo considera lo que necesitas para construir, tambien
> > > > tienes analisis, diseño, construccion, pruebas, documentacion, etc.  En
> > > > el equipo hay gente que se distribuye esos trabajos.  Por estos lados
> > > > del planeta, mas del 95% de los proyectos son asi.  (tirando un
> > > > porcentaje al ojo, podria ser mayor).
> 
> > > cierto, el lenguaje al parecer solo es relevante en construccion y
> > > tambien algo en documentacion.
> 
> > Hmm ... que tanto soporte para "debugging" te ofrece un lenguaje es una
> > consideracion muy importante.  Este solo detalle me hace descartar PHP
> > para casi cualquier cosa.
> 
> Linus difiere fuertemente con tu punto de vista... es por su imperturbable
> oposicion que Linux no tiene un "debugger oficial" integrado al nucleo.

Siempre he considerado esa posicion bastante absurda.  Un debugger puede
ayudar a entender _donde_ esta el problema, y con esa informacion
corregir el problema de fondo.  Por supuesto, si un idiota cualquiera
toma la informacion del debugger y corrige el sintoma en lugar del
problema, es un idiota como los que se encuentran en cualquier parte; no
es culpa del debugger.

> > Una cita extremadamente interesante de Brian Kernighan, que agrega mas
> > OT a este thread:
> > 
> > "Debugging is twice as hard as writing the code in the first place.
> > Therefore, if you write the code as cleverly as possible, you are, by
> > definition, not smart enough to debug it."
> 
> Excelente punto. Pero sigo de acuerdo con Linus que el uso de debuggers
> tiende a llevar a que la gente vea los sintomas, y los "corrige" en vez de
> corregir el problema de fondo. Precisamente /eso/ es lo que es dos veces
> mas dificil que escribir el problema, lo de seguir el programa y torcer su
> funcionamiento cuando se ve que va en direccion equivocada es facil, pero
> dan~ino a largo plazo.

El uso incorrecto de las herramientas es algo que existe desde que estas
se inventaron.  Dejarlas de lado no es la solucion, sino aprender a
usarlas como corresponde.  Acaso nos deshacemos de los martillos porque
hay gente que se golpea los dedos?

Yo no soy un programador demasiado brillante -- por ejemplo, nunca he
hecho uno de esos programas ofuscados que a la gente le gusta poner en
el pie de sus firmas.  En cambio, prefiero buscar soluciones simples a
los problemas que me planteo.  Esta aproximacion me ha permitido
resolver problemas grandes, y usar depuradores para ver errores en mis
soluciones.  El paradigma "programacion por contrato" ayuda mucho en
este aspecto, y el depurador es una buena herramienta para buscar nuevas
clausulas para los contratos, y ver donde estan fallando.

PHP no es un lenguaje que se preste para esto -- por ejemplo los
Assert() son demasiado debiles, y la OO no tenia las suficientes
facilidades que a mi me habria gustado.  (Observaciones de hace tiempo
ya; quizas PHP 5 haya corregido esto).

-- 
Alvaro Herrera                         Architect, http://www.EnterpriseDB.com
"If you have nothing to say, maybe you need just the right tool to help you
not say it."                   (New York Times, about Microsoft PowerPoint)