jueves, mayo 29, 2008

Batalla de los Ewoks?

En un url muy muy lejano...

Pues el último escrito de Steve Yegge generó todo tipo de reacciones:

Return of Statically Typed Languages
Guide You the Force Should
Revenge of the Statically Typed Languages
A New Hope - Polyglotism

Y me imagino que en este momento deberán haber otros cientos de entradas similares. Dentro de "la saga", la opinión con la que mejor me llevo es con la de "Ola Bini"

I guess that's the message of this post. Compare languages, understand your most important tools. Have several different tools for different tasks, and understand the failings of your current tools.


Lo cual va muy de la mano con otro comentario de Ted Neward:

Erik Meijer coined this idea first, and I like it a lot: Why can't we operate on a basic principle of "static when we can (or should), dynamic otherwise"?


Un algunos de ejemplos que se me ocurren podrían ser estos:

Uno de los fuertes por ejemplo dentro de los lenguajes dinámicos ha sido procesamiento de texto. Si uno se remonta a la historia puede uno darse cuenta que Lisp, Perl, Python han sido muy fuertes en este campo. Quien necesita tipos para hacer búsquedas y reemplazos en texto?

De la misma forma puede uno llegar a dominios de Problemas donde un lenguaje estaticamente Tipado sea mejor. Si necesito armar un árbol sintáctico y necesito hacer verificaciones... es bueno hacerlas en runtime? no es acaso mejor que el sistema de tipos me ayude con eso? Es por eso que a la hora de hacer compiladores mucha gente opta por Sistemas fuertemente tipados como Haskell y derivados de ML. Las propiedades de verificación de este tipo de lenguajes supera en forma enorme la de los lenguajes dinámicos(1).

Si quiero estar haciendo modificaciones de código en caliente para que me voy a complicar con tipos? Invito a cualquier persona a intentar simular comportamientos dinámicos como agregar-modificar métodos en runtime usando las capacidades de "Reflexion" de Java o C#. Y luego intente hacer lo mismo en Ruby. Estoy seguro que la elección del sistema de tipos de Erlang tiene mucho que ver con este punto.(2)

Consejo:
Sea crítico con este tipo de Flame-Wars. Muchas veces todos comparten cierta razón en lo que dicen. Y al final siempre se aprende. (Parecen inaportantes los Ewoks y al final...)

(1) Las posibilidades de los ML y Haskell para verificación no solo tienen causas en el sistema de tipos fuertemente tipados. El hecho de poseer transparencia referencial por ejemplo ayuda

(2) "Reemplazo de código en caliente" debe leerse a la ligera! El caso de capacidades dinámicas (como cambiar métodos) Es muy diferente lo que hace Erlang. Pero la idea es hacer referencia a ese tipo de comportamientos.

lunes, mayo 26, 2008

Recordar es vivir

Recuerdo que el primer lenguaje "declarativo" con el que empecé (mejor digamos... traté) fue Prolog. Me acuerdo que en aquella época no fui capaz de hacer siquiera un Fibonacci.

Hace algunos días me dió curiosidad cuando un compañero del trabajo me contó la historia de lo difícil que le fue encontrar un error de sintaxis (un punto en lugar de una coma) y No me aguante las ganas de bajar SWI Prolog y probarlo.

Hice solo un par de bobadas, y confieso que me costó un poco "acomodar el cerebro" con el modo de Prolog para expresar la recursión.

Fibonacci:


fib(0,1).
fib(1,1).
fib(N,FIB):-
N > 1,
N1 is N-1,
N2 is N1-1,
fib(N1,FIB1),
fib(N2,FIB2),
FIB is FIB1 + FIB2.


Sumatoria de una lista:


sum([],0).
sum([X|XS],A) :-
sum(XS,A1),
A is X + A1.


Sé que no son los ejemplos mas interesantes del mundo, pero la verdad me emocione cuando volví a leer el término "Clausula de Horn" en el tutorial.

Que piensan de la sintaxis comparada con la de los lenguajes funcionales usuales?
Alguien sabe que paso con los lenguajes Lógicos? En un video (si mal no recuerdo) Eric Meijer decía algo sobre cierta desilusión del paradigma lógico (creo que específicamente hablaba de que las cosas bacanas requería intervenir el backtracking o algo así)

Y que hay de la pureza?

jueves, mayo 15, 2008

Hoy aprendí:

Hay un blog que me gusta mucho y ese es Tumbolia Para el que no sepa, Tumbolia es el mundo de la inconsistencia que describe Douglas Richard Hofstadter En Gödel Escher and Bach. La estructura del Blog es simplemente, de vez en cuando mencionar una lista de cosas nuevas que uno aprendió.

Tengo ganas de hacer lo mismo de vez en cuando... así termine siendo esto un copy-paste de Slashdot y Reddit.

Y empecemos!

* La décima regla de Greenspun establece:


"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp"


* El sistema de Chat de Facebook está montado sobre Erlang. La razón es (sobre-simplificando) que Erlang permite procesos extremadamente ligeros.

* Según este blog es posible crear algorítmicamente palabras que parezcan escritas en otro idioma.

"...that if you compile a table of the relative frequencies of three-letter sequences (trigraphs) in English text, and then generate random text with the same trigraph frequencies"


Tengo ganas de hacer el experimento... El follow up contiene detalles de como hacerlo. (Alguien dijo hash tables? :P)

* Un libro que espero algún día comprar es Purely functional data structures Él autor tiene un también un blog que me parece muy interesante. No sabía que el "miedo a los arreglos" y el uso de Pseudo-Arreglos cuando las personas empiezan a programar es algo común.

Ese código con variables de la forma a1 a2 a3 se me hizo muy familiar :P

* Brace expansions en bash... un ejemplo vale mas que mil palabras:

Que hace?

diegoeche@multivac:\ mkdir {1,2,3,}log

lunes, mayo 05, 2008

Get the facts

Creo que esto es cuento viejo pero mi maldita personalidad me impide leer una cosa de éstas y quedarme "quieto"

www.getthefacts.com es una pagina de Microsoft donde se "ayuda" a realizar una buena decisión a la hora de escoger la plataforma para el server. Hay una pequeña pestaña de "Compare Windows to Linux" y simplemente da vergüenza la falta de inteligencia de ésta campaña. Empecemos por la metodología:

Es muy sencillo, existen varias pestañas con temas como "How Windows Reduces TCO (Total Cost Ownership)", "Understanding Platform Reliability" "The Real Story on Security" Cada pestaña incluye una gráfica que solo puede convencer al mas ingenuo de los ingenuos, un pequeño texto explicativo y "Casos de estudio".

How Windows Reduces TCO

Tengo mis dudas sobre el famoso 7% del costo del software (licencias) pero la verdad no tengo nada contundente que decir. Así que cojamos un caso de estudio cualquiera.

Speedy Hire

Contexto:
"Since its creation in 1977, the group has expanded into different markets and sectors, largely by taking over competitors such as, most recently, the tool-hire division of Hewden Stuart. These successful takeovers left Speedy Hire at the head of unreliable, heterogeneous software environments, all running independently from one another."

Solución:
Speedy Hire decided to switch to a Microsoft environment across the board. The first stage was to change the hire application to Microsoft Dynamics™ AX, in what was one of the organization's biggest IT projects to date. As part of this project, Speedy Hire replaced all of the computers in its depots, replacing Linux personal computers with Wyse V90 Winterms running Windows XP Embedded, and open-source office products with the 2007 Microsoft Office system.

Wow... estos tipos en serio se ganan el premio! Cambian un ambiente heterogeneo a uno homogeneo usando windows y las conclusiones son obvias. "Windows es mejor!" "Windows ahorra dinero". Una plataforma homogénea ahorra dinero sin importar por que sistema se opte y porque? porque se necesita menos conocimiento en IT, y eso usualmente es equivalente a tener menos personas dando soporte.

Pero momento... no era acaso también esta una evaluación a nivel de plataforma de server? porque se utiliza este caso de estudio? es relevante? NO

Understanding Platform Reliability

Empecemos por la brillante deducción:
"Organizations define reliability as more than uptime. A reliable solution is one that is:
* Easy to configure and maintain
* Predictable, especially as business requirements evolve
* Therefore, available to end users. "

Hace falta el:



Caso de estudio: Western Materials

Pues resulta que ellos usaban Nitix y también tienen casos de estudio.

Y obvio... como estamos hablando de Reliability:

“Nitix wouldn’t support anything newer than Outlook 2000. Anyone using Outlook 2003 had to manually maintain two Inboxes on the desktop and use a rule to move messages from one Inbox to the other.”

Suena música de X-Files, porque como no se absolutamente nada del mundo real me pregunto... ¿Que tiene de diferente Outlook 2003? alguien que me responda! yo estaba seguro que era cuestión de configurar el protocolo adecuado (IMAP, POP3) que me hace falta?

The Real "Story" on Security

Ve uno una gráfica al lado derecho con unas barras: El típico encargado de IT dice "Oh veo unas barras de colores!! La de windows vista es la mas pequeña!! Instalemos vista! ergo, mas seguridad!!" (añadir el tono de imbécil)

La versión con la que comparan Linux es Ubuntu 6.06 de Escritorio. (Contra vista y XP) pero momento. No es ésta acaso la página para escoger mi plataforma server? Porque comparan los sistemas de escritorio? Y bueno... sigamos con la comparación. Cuantos paquetes trae Ubuntu vs Windows por Default? Supuestamente se trata de una versión reducida PERO si uno mira el reporte en el que está basado:

"I manually excluded gimp and OpenOffice from the package list. I didn’t exclude anything
else because I felt that most users would not go to the effort to manually remove packages
from the default desktop installation."

Wow... eso si que hace la diferencia!

Ahora las métricas:

Entre tantas se destaca una que se lleva fácilmente el premio a "la falacia de pez rojo" mas grande de la historia. La métrica de la que se sienten super orgullosos es el número de "patch events" pero... que tiene que ver el numero de patch-events con la seguridad?

Otra cosa interesante es que se mide "número de vulnerabilidades encontradas" y "número de vulnerabilidades de éste conjunto que fueron arregladas" Él número de vulnerabilidades en Vista y XP es mucho menor que en Ubuntu, PERO eso qiere decir que Ubuntu sea mas inseguro?

La falacia con la que pretende razonar Microsoft es una especie de proporcionalidad entre vulnerabilidades existentes vs vulnerabilidades encontradas. Al decir que en Vista se han encontrado menos vulnerabilidades se pretende llevar al lector a pensar "si encuentran menos es porque hay menos" lo cual resulta totalmente falso. Una vulnerabilidad es en esencia una característica del software que en alguna circunstancia puede dar una oportunidad al atacante de aprovecharla. (Desarrollar un exploit) Én el caso de Vista y XP encontrar una vulnerabilidad usualmente se basa en técnicas de ingeniería inversa.

Que es más facil, encontrar una vulnerabilidad de Buffer overflow en él código C con comentarios de Ubuntu 6.06 con reportes técnicos y demás. O en él código objeto Hexadecimal de Windows Vista justo después de su release sin ninguna documentación?

Ahora bien. La métrica que prefiero utilizar... usando los mismos datos es "porcentaje de Vulnerabilidades Arregladas"

Veamos las gráficas:



En Windows Vista es alrededor de un Ratio 50/50 una vulnerabilidad la arreglan, otra no. Muy perezosos para mi gusto la verdad... Porque con todo el dinero de microsoft y con lo costoso de una licencia tienen ese horrible ratio de vulnerabilidades arregladas?

(será que internamente usan una moneda y todo?)

y en Ubuntu? Usando el método súper científico de medir con el dedo sobre la pantalla el gráfico me da que el 95% de las vulnerabilidades fueron arregladas.