Google
 

jueves, diciembre 27, 2007

¡Parad de una vez!

Me estáis volviendo loco con tantos lenguajes nuevos y relecturas de antiguos lenguajes. Parece que desde que Java ha sido adoptado masivamente por las empresas esta dejando de ser cool y los programadores necesitan una vía de escape para intentar llegar al nirvana.
- D
- Lisp
- Scheme
- Dylan
- Ruby
- Haskell
- OCaml
- Erlang
- Clojure
- F#
Por citar sólo los mas nombrados. Todos esos lenguajes tienen tres cosas en común:
1º) Él es el mejor lenguaje, todos los demás son basura (obviamente todos se equivocan).

2º) Intentan llevar el cálculo lambda a su máxima expresión.

3º) El paradigma imperativo de programación está definitivamente muerto. Una prueba es que se le da menos importancia al for/loop que nunca, todos los lenguajes intentan reducirlo al mínimo.

lunes, diciembre 17, 2007

Programas asesinos (literalmente)

Uno nunca para de sorprenderse sobre los peligros de un programa mal diseñado:
- Mariner 1 (1962): Un error al transcribir una fórmula al programa desvió el cohete de la ruta programada por lo que tuvieron que destruirlo sobre el océano atlántico para evitar mayores desgracias.

- Gaseoducto soviético (1982): la CIA introdujo expresamente un bug en el software que una empresa canadiense vendió a los soviéticos. Resultado: la mayor explosión no nuclear de la historia del hombre.

- Therac-25 (1985-1987): Un fallo en el software controlador en un aparato de radioterapia produjo varias muertes por quemaduras.

- Servicio de ambulancias de Londres (1992): por culpa de escoger una empresa desarrolladora de software con poca experiencia hubo un gran número de llamadas perdidas y muchas otras duplicadas.

- Ariane-5 (Junio-1996): a causa de una excepción provocada por un programa escrito en Ada hubo una perdida absoluta del control de dos misiles no tripulados poco después de su despegue.

- Sobreexposición en Panamá (22-Mayo-2001): Otro aparato de radioterapia mató a 8 pacientes. Además, otros 20 sufrirían, a la larga, serías complicaciones.

- Toyota Prius (2004-2005): un fallo de programación en el software controlador de los coches Toyota Prius provocaba que bajo ciertas condiciones se pararan en seco.

- National Defence Force (17-Octubre-2007): el fallo en el programa de un cañón antiaéreo provocó la muerte a 9 soldados e hirió a otros 14.
Para ser un buen asesino en masa ya no es necesario salir de casa, con estudiar ingeniería del software es suficiente.

Fuente: Curso 6.170 del MIT + Google

martes, diciembre 11, 2007

C++ / #pragma once

Todos los que hayan programado en C/C++ conocerán de sobra los include guards (no sé como lo llaman en español):
#ifdef CABECERA_H
#define CABECERA_H

// TODO código

#endif
Pero hay otro método:
#pragma once

// TODO código
El segundo método ofrece algunas grandes ventajas:
  1. Menos código a escribir (una línea en lugar de tres).
  2. Nos evitamos posibles colisiones con los nombres de las macros (CABECERA_H podría estar usándose en otro archivo).
  3. Ayuda a mejorar la velocidad de compilación ya que si se declara el #pragma once el compilador usa el propio archivo para averiguar si ya ha sido declarado o no, con lo que se evita el tener que pasar el código por el preprocesador.
Como desventaja diría que no forma parte del estandard pero hoy en día todos los compiladores lo soportan.


Fuente: http://www.answers.com/topic/pragma-once

martes, diciembre 04, 2007

Lost in the Static

Me encantan los juegos originales y este es uno de ellos. Seguramente te aburras a los cinco minutos pero es un must see como dirían los americanos.

Échale un vistazo a Lost in the Static. No os dejéis engañar por las capturas de pantallas.

jueves, noviembre 29, 2007

Haskell ganando puntos

Y es que no paran de salir "truquitos" para este lenguaje, a cada cual más interesante que el anterior. El último va sobre lo fácil que es paralelizar tu código para usar toda la potencia de tus múltiples CPUs (cada vez mas frecuente en los PC). De hecho, una de las mayores quejas, totalmente injustificada que usan los trolleros para meterse con este lenguaje es que el soporte de hilos de Erlang es superior, cuando a la hora de la verdad Haskell no tiene nada que envidiarle.

Se calcula, calculo chorra donde los haya, que Haskell es más o menos el doble de lento que C (una cifra bastante buena). Pero claro, si implementar un algoritmo en Haskell es infinitamente más fácil que en C a pesar de ser un lenguaje más lento obtendremos resultados mejores.

jueves, noviembre 22, 2007

¿Está VRML muerto?

La primera versión salió el año 1994. Después apareció VRML2 en el 1997. Actualmente está el estándar X3D, totalmente compatible con VRML.

Hacia muchísimo tiempo que no miraba nada de VRML y me he llevado una grata sorpresa. Soporte para shaders, motor de físicas (aún en desarrollo), scripts en JavaScript y Java entre otras cosas. Es sencillo de crear a mano aunque también existen editores (libres como Flux Studio pero la mayoría comerciales).

No sirve para crear el nuevo éxito de ventas estilo World Of Warcraft pero es perfecto para una gran gama de productos.

Pasaros por los ejemplos de Octaga y por los de Flux y os podréis hacer una idea mejor.

jueves, noviembre 08, 2007

¿Lenguajes "alternativos" en los motores de juegos?

No nos desengañemos, salvo honrosas excepciones en C# o Java como jMonkeyEngine, no hay ni un sólo motor 3d (al menos que yo tenga constancia) orientado a juegos comerciales que usen otro lenguaje que no sea C/C++.

¿Es que no es posible crear un buen motor 3d en algún lenguaje funcional? Puedo entender que no se escoja Lisp por no ser tan rápido como C/C++ (aunque considero que es lo suficientemente rápido) pero ¿porqué no tirar de OCaml o de Haskell por poner dos ejemplos? Creo que los lenguajes funcionales son perfectos para el desarrollo de un motor 3d. Además, hoy en dia todos los lenguajes tienen FFI para poder acceder a librerias como OpenGL o OpenAL.

Soya3D está escrito integramente en Python. Aunque aún le falta mucho camino por recorrer es un buen ejemplo.

También tenemos Flag, un juego escrito totalmente en Haskell.

miércoles, noviembre 07, 2007

IOCCC 2007

Vía Barrapunto leo que ya han salido los ganadores del último International Obfuscated C Code Contest. Para los que no sepan de que va el concurso decir que es ya todo un clásico en cuanto a osificación de programas escritos en C, ejemplos extremos del mal uso al que se le puede dar un lenguaje.

Aún no han publicado el código fuente de los últimos ganadores, pero para ir abriendo boca podéis ver los de los anteriores certámenes.

Para que se os vaya abriendo el apetito os dejo todo un clásico en cuanto a programas ofuscados. El fractal del Mandelbrot:
float e,a,b,c,d;int i;main(){for(b=0;b<4;b+=.091){for(a=0;a<4;a+=.051)
{c=0;d=0;for(i=99;--i&&c*c+d*d<4;)e=c*c-d*d+a-2,d=2*c*d+b-2,c=e;
putchar(". ·*%#"[i&5]);}puts("");}}

martes, octubre 23, 2007

Control de versiones distribuido

Hoy en día nadie se mete en el desarrollo de un proyecto, por muy pequeño que sea, sin tirar de algún sistema de control de versiones. Los más tradicionales como CVS, Subversion o Visual SourceSafe (menudo horror de programa) están dejando pasar a un nuevo concepto: control de versiones distribuido.

La principal diferencia es el cambio de mentalidad. Mientras que con los sistemas tradicionales tenemos un servidor central en el que se guardan todos los cambios, con el sistema distribuido cada usuario tiene su propio repositorio. Todos los cambios son locales en el ordenador (con la mejora de velocidad que comporta no usar una red para conectar al servidor). Cuando hayamos decidido que estamos listos podemos enviarles los cambios a los repositorios de los otros usuarios.

El control de versiones distribuido más usado actualmente es Mercurial. Mirad su tutorial en español.

¿Beneficios? Obtener los cambios de los archivos casi al instante y sobretodo el poder crear todas las ramas que te de la gana para experimentar cuanto quieras (en los sistemas tradicionales suelen haber bastantes conflictos a la hora de juntar una rama secundaria con la principal).

martes, octubre 16, 2007

Marketing Wii vs Marketing Playstation 3

Mirad este spot de la Playstation 3. Ahora mirad este otro de la Wii. ¿No os entran ganas de ir corriendo a la calle a compraros una Wii?

Mientras los de Sony muestran a un tipo soso con cara de estar divirtiéndose más bien poco, los de Nintendo, en todos sus anuncios, no hacen más que intercalar gente (normalmente acompañados) con caras radiantes de felicidad y de estar divirtiéndose hasta niveles que parece que les va a dar un síncope.

Creo que la gran campaña de publicidad que ha hecho Nintendo ha sido una de las principales razones por la que ha vencido a Playstation 3 y a XBox 360.

miércoles, octubre 10, 2007

Mitos sobre C/C++

La gente suele asociar a C/C++ como el lenguaje de programación más rápido sobre la faz de la tierra (con perdón del ensamblador). Me gustaría recalcar varias cosas :

- Primero que C++ es más lento que C.

- Que el lenguaje más rápido, aunque no suele aparecer en las comparativas, es Fortran.

- Que lenguajes que la gente suele pensar que son interpretados (normalmente porque suelen ser lenguajes que se pueden ejecutar en modo interpretado o en modo compilado) como Lisp pueden llegar a ser más rápidos que C++.

- A pesar de haber lenguajes tan rápidos como C pero de más alto nivel (OCaml) la gente no suele ni siquiera plantearse la posibilidad de escribir el programa en algo que no sea C, incluso aunque ello signifique menos bugs y menor tiempo de desarrollo (Wings3D está escrito en erlang).

- Que aunque las STL en C++ son tremendamente lentas comparadas con una alternativa escrita en C (hasta unas siete veces) la gente sigue usándolas en situaciones críticas.

Aunque sigáis programando en C/C++ espero al menos haberos metido en el cuerpo "el gusanillo de la duda".

jueves, octubre 04, 2007

Popurrí de enlaces

domingo, septiembre 30, 2007

XEmacs + Slime + CLisp + ASDF + CFFI + Windows

XEmacs: editor de texto optimizado para el desarrollo de aplicaciones. Es el emacs de toda la vida pero con esteróides.
Slime: el mejor plugin para emacs para editar programas en Lisp.
CLisp: uno de los mejores intérpretes Lisp opensource.
ADSF: gestor de paquetes para Lisp.
CFFI: módulo para Lisp para poder usar DLLs sin tener que escribir una sola linea en C.

Podéis ver un video básico de como funciona Slime, puede parecer complicado pero cuando te pones es bastante sencillo. Pero si queréis exprimir de verdad XEmacs y Slime o simplemente deseáis ver todo su potencial (como usarlo de editor remoto con el intérprete Lisp en otro ordenador) ved este otro video, totalmente recomendado.

En Linux es realmente fácil instalarlos, los seleccionas en el gestor de paquetes para instalar y listo. Pero en Windows los programadores siempre nos lo ponen más difícil, acabas haciéndolo todo a mano.

¿Cómo se instala en Windows?
  1. Para instalar XEmacs te bajas el instalador (no los binarios sueltos) y lo instalas en C:\Archivos de Programa\XEmacs.

  2. Instalar Slime también es fácil, te lo bajas y lo descomprimes en el mismo directorio que XEmacs: C:\Archivos de Programa\XEmacs.

  3. Ahora te bajas CLisp y lo descomprimes en raíz en C:\lisp-2.41. Es importante hacerlo en raíz o en un directorio sin espacios. A continuación ejecuta el archivo install.bat.

  4. Ahora lo más complicado, los archivos de configuración. Van todos en tu directorio de usuário C:\Documents and Settings\Administrador en mi caso.

    Para configurar XEmacs crear un subdirectorio .xemacs y el archivo init.el con:
    (add-to-list 'load-path "c:/archivos de programa/xemacs/slime-2.0/")
    (setq inferior-lisp-program "c:/clisp-2.41/clisp.exe -I")
    (require 'slime)
    (slime-setup)

    Para configurar CLisp (para meterle el ASDF) crea el archivo .clisprc.lisp:
    (load "c:/clisp-2.41/central/asdf.lisp")
    (push "c:/clisp-2.41/central/" asdf:*central-registry*)
    Es importante la barra final en el directorio de la segunda linea porque sirve para indicar que es un directorio y no un archivo.

    Puede que tengáis problemas para crear archivos con un punto delante. Usad la linea de comandos.

  5. Ahora acabaremos de configurar el ADSF para CLisp. Crea el directorio central en c:\clisp-2.41 y copia allí el archivo asdf.lisp.

  6. Para probar que el ASDF funciona correctamente instalaremos CFFI. Se podría hacer con el asdf-install pero no lo he conseguido hacer funcionar. De cualquier forma es trivial instalarlo uno mismo.

    Descomprime cffi en c:\lisp-2.41\central. Ahora tan sólo haz un acceso directo del archivo cffi.asd en el directorio central que se llame igual cffi.asd (yo lo arrastro con el segundo botón del ratón y después renombro el archivo).

  7. Probemos que funcione:
    • Arranca XEmacs
    • Alt+X slime
    • (asdf:oos 'asdf:load-op 'cffi)
Y eso es todo, no fue tan complicado. Para cualquier duda usad los comentarios.

jueves, septiembre 27, 2007

Linus Torvalds y la tonteria del C vs C++

Tras la reciente polémica levantada por el flameware de Linus Torvalds con respecto al C vs C++ me gustaría dejar patente mi opinión al respecto: menuda gilipollez de comparación.

El paradigma en desarrollo de software es la filosofía que se sigue, no la metodología sino la forma en que ves el programa, el como lo sientes. Mientras C usa programación imperativa C++ usa esa más la orientada a objetos. Obviamente en C se pueden hacer objetos de forma un poco rudimentaria pero ese no es el objetivo del lenguaje, no es la forma de sentir de un programador en C.

¿A donde quiero llegar con esto? Que C y C++ son dos formas diferentes de programar y es absurdo comparar esos lenguajes como es absurdo meter a alguien en la cárcel por ser gay. Es cuestión de gustos y con que te encuentres más cómodo.

lunes, septiembre 24, 2007

Lenguajes ¿prehistóricos?

Si, pero prehistóricos solos por el año en que fueron diseñados. Mirad ésta gráfica (bastante conocida por Internet).

Fortran, un lenguaje diseñado para ser usado en tarjetas perforadas datado en el año 1954, se sigue usando a día de hoy.

Cobol, del 1959 es, sorprendentemente, el lenguaje más usado con diferencia. Se calcula que durante el 2005 el 75% de los datos generados por negocios eran procesados por programas escritos en este lenguaje.

Y Lisp, mi favorito, del 1958. No han tenido que cambiar ni una sola linea del estándar para incluir técnicas "modernas" como programación orientada a objeto.

Luego hay otros lenguajes, como Forth (1965), que a pesar de que hoy en día ya no se usan, tienen bastantes cosas que enseñaros. Pero de eso ya hablaremos otro día.

sábado, septiembre 22, 2007

C++ y las tres bes: bonito bodrio y... bacalo (Capítulo I)

He estado varios meses sin actualizar el blog por falta de tiempo pero ya vuelvo al pie del cañón. Vuelvo para hacer pública mi opinión acerca de un lenguaje que prometió el oro y el moro pero que acabó convirtiéndose en un estorbo. Si, me refiero a C++.

Con la gran explosión de lenguajes que estamos viviendo en estos últimos años (Ruby, Lua, Python, etc...) se va haciendo cada vez más patente los grandes defectos de C++. El principal, desde mi punto de vista, y el que más me putea es el conocido como name mangling.

¿Que qué carajo es eso? Empecemos con la explicación para C. Cuando compilas tu programa el compilador de C no usa los nombres de las funciones que elijes porque el programa que se encarga de linkar necesita información extra. Así que el compilador retoca un poco los nombres. En C ésto, el mangling scheme, es algo definido en el estándar, da igual el compilador que uses, da igual el lenguaje que uses que al ser estándar todos se entienden entre sí.

Ahora vamos con el C++ que funciona igual excepto un pequeño y desastroso detalle... no hay un estándar, no entiendo porqué pero no lo hay. Cada compilador gcc, msvc, etc... usa un formato diferente para nombrar las funciones durante la compilación, con lo que todos son incompatibles entre si.

¿Como nos afecta esto? Intentad hacer una DLL en C++ y veréis que bonito resultado. Observad como todos los nuevos lenguajes tienen soporte directo para usar llamadas a C pero no a C++ Linkar archivos .obj de diferentes compiladores juntos y observad que bonito error aparece en vuestras pantallas.