Proyectos (era Re: Problemas con GTK)

Alvaro Herrera alvherre en alvh.no-ip.org
Lun Oct 10 19:21:46 CLST 2005


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)


Más información sobre la lista de distribución Linux