viernes, diciembre 14, 2007

Mandelbrot en F#

Una vez un profesor dijo lo siguiente. "Para aprender un lenguaje (de programación) lo primero es entender su sintaxis para lo cual basta con pegarse a leer la especificación sintáctica en BNF, el resto es conocer las API's". En cierta forma estoy de acuerdo. Sin importar que tan bueno se sea jugando con la sintaxis de un lenguaje o las posibilidades de estilo de programación que permite, aprender un lenguaje es en cierta forma conocer sus API's.

Como reto a corto plazo quiero hacer un pequeño Ray-Tracer en F#. Alguna vez hice uno en Java no fue muy difícil. Para esto hay básicamente 2 componentes

1. La parte que coja las librerías de dibujo y a partir de un bitmap pinte la imagen
2. Más importante aún, el algorítmo de Ray-Tracing

Nunca en mi vida había utilizado librerías de Microsoft. Nunca en mi vida había utilizado MSDN y puedo decir que resulta relativamente fácil. Entonces, para superar la primera parte decidí hacer un pequeño reto que pintara sobre un bitmap. Pero que iba a pintar?

Me acordé que cuando hice el Ray-Tracer en Java, saque la parte que pintaba en un bitmap de un ejemplo que pintaba el bien conocido Mandelbrot. Entonces decidí empezar por ésto. Intentar pintar el Mandelbrot.

Busca uno en wikipedia y se encuentra el algoritmito

y listo... Primer problema. él algoritmo como suele suceder es imperativo. Pues bien, F# permite código imperativo y algún día tenía que aprender.

Entonces...

let mandelbrot (x,y) =
let x0 = ref x in let y0 = ref y
let i = ref 0
while (!x0 * !x0 + !y0 * !y0 < 4.0) && (!i < 1000) do
let tmpx = !x0 * !x0 - !y0 * !y0 + x
let tmpy = 2.0 * !x0 * !y0 + y
x0 := tmpx
y0 := tmpy
i := !i + 1
if !i = 1000 then 0.0 else 1.0

Algunas generalidades sobre él código.
Para alguien cuya experiencia con código funcional haya implicado únicamente Haskell él código debe resultar espantoso. Por? Simplemente por el while. Para generar éste while se hace uso de objetos mutables (ref i, ref x0 y ref y0). A diferencia de Haskell, F# permite utilizar objetos con estado. estas ref, son casi como apuntadores. Hacen referencia a partes en memoria, lo cual implica side effects y todas las cosas "maravillosas" del mundo imperativo.

En fin... después de tener ésto implementado (Junto con la parte de System.Drawing) se genera la siguiente imagen:



En este momento la imagen es binaria. si el punto pertenece al conjunto se pinta, sino no. Nada impresionante. Una forma de hacerlo más bonito es asignando un color dependiendo de la cercanía al conjunto. Cuestión de devolver un valor no binario que se tendrá en cuenta a la hora de pintar. Yo lo hice de la siguiente manera. Reemplacé en el código anterior la última línea por ésta:


1.0/(Float.of_int (!i + 1))


El resultado:



Todo el código fuente está aquí.

martes, diciembre 11, 2007

Comenzando con F#

Si todo sale de acuerdo a lo planeado haré mi práctica trabajando en un "nuevo" lenguaje de Microsoft llamado F#. Éstas últimas semanas estuve viendo diferentes alternativas para ver donde iba a comenzar a cacharrear con el lenguaje entonces me tope con las siguientes opciones:

1. Partición Windows con Visual Estudio
2. Mono
3. Windows Virtualizado

Después de mucha pereza de instalar Windows decidí optar por instalarlo con Mono. La primera vez que lo intenté me sacaba un error con unas dlls entonces dije "Porque no virtualizo un windows y trabajo ahí? la verdad solo necesito el compilador y hago copy paste del código que escriba con mi hermoso emacs". El resultado fue ésto:



Visual estudio corriendo en un Windows virtualizado sobre KVM.

Pero lo que parecía una fantasía taaan prometedora falló en algo bien básico.

* No es posible hacer copy-paste (además no es tan cómodo como lo imaginé).

* La eficiencia se va pal carajo. La sola instalada de VS me tomó alrededor de 4 horas

* Si le hace a uno a veces falta espacio para ver el código por el montón de bobadas abiertas, Visual Estudio no colabora (en la imagen se ve)


Entonces dije "volvaaamos a intentar con mono". El asunto resulto ser mas simple de lo que pensé, para que me corriera bien solo hacía falta instalar las librerías faltantes lo cual con aptitude es muy muy fácil.

Una vez instalado hice lo primero que uno debe hacer

diegoeche@Multivac:~/Desktop/FSharp-1.9.2.9/workspace$ cat Hello.fs
printf "Hola FSharp!\n"
diegoeche@Multivac:~/Desktop/FSharp-1.9.2.9/workspace$ mono ../bin/fsc.exe Hello.fs
diegoeche@Multivac:~/Desktop/FSharp-1.9.2.9/workspace$ mono Hello.exe
Hola FSharp!


No hay monadas. Todo es simple y lleno de side-effects :P. Es decir F# no es un lenguaje puramente funcional lo que permite llamar funciones de entrada salida donde uno quiera.

Pues bien, no me podía quedar ahí y tenia que hacer algo para sentirme programando realmente en forma funcional. Entonces arregle el .emacs para trabajar con un modo para Caml llamado Tuareg porque la sintaxis de F# y Caml tiene algo de similar. Ya con un ambiente de desarrollo DE VERDAD (emacs y un compilador, que mas necesita un hombre de verdad? :P) éste fue el resultado:

open List

let rec fib x =
match x with
| 1 -> 1
| 2 -> 1
| n -> (fib (n-1)) + (fib (n-2))

let rec size x =
match x with
| [] -> 0
| x::xs -> 1 + size xs

do print_any(map (fun x -> 2 * x) [1..10])
do System.Console.WriteLine(size [1..10])


Pattern matching Recursividad, map, y una función anónima son cosas para querer empezar a trabajar ya!

:D

viernes, noviembre 23, 2007

Fotos soho

Pues por ahí vi un código en Java para bajar las fotos de Soho en 550 lineas de código. Si alguien lo quiere ver, está aquí. El código está horrendo (éste horrendo es una opinión personal)

Un amigo lo hizo en 54 usando Bash. Está aquí
Lo cual me hizo dar ganas de aprender sed.

Yo no me podía quedar atrás, entonces hice uno muy sencillo en Ruby.

El Link al código bonito en HTML usando el modulo de Steve Yegge.

Y el script está aquí

Voy a ver si en otro desparche lo hago en Haskell.
Lo mas charro de todo es que ni he visto las Fotos.

miércoles, noviembre 21, 2007

Algo mejor que Ruby

Por fin me encontré con algo mejor que Ruby para desarrollo Web!

Creo que ésto superará con creces la agilidad de esas herramientas nuevas :P

jueves, noviembre 15, 2007

Problema de Definiciones

Últimamente he tenido un par de problemitas con definiciones de Ingeniería de Software.

El primer problema surgió cuando estaba discutiendo sobre si Linux era o no usable. Yo sostenía que Linux era bastante usable, era claro de entender, simple y demás. "Fácil de usar" era mi definición pero luego la persona con la que estaba hablando empezó a asociar a usabilidad cosas como "intuitivo " y "fácil de aprender a usar".

Yo todavía me quedo con mi definición.

La otra y más traumática fue con la definición de Transparencia. Para mi transparencia tenía mucho que ver con lo que mencioné en otra entrada.

Para mi básicamente era simplicidad y ocultación. Mi definición incluía muchas cosas... para hacerme entender esta digamos RMI, RMI es un mecanismo de invocacion remota de objetos en Java. Esto permite que si ud tiene un objeto en una máquina pueda llamar métodos de este desde otra de manera Simple y Ocultando toda la complejidad de abajo (Sockets, Marshaling y otras cosas). Es decir RMI era para mi un método transparente de invocación remota de objetos.

Ahora bien, Leyendo "The Art of Unix Programming" Me di cuenta que existe una definición totalmente diferente. Para Eric Raymond Transparencia tiene que ver con la facilidad de entrar en el código, de ver su funcionamiento. El habla de "discoverability" algo así como "la habilidad de descubrir".

Eric Raymond menciona por ejemplo, como una opción --verbose que diga todo lo que hace un programa, hace de éste mas transparente.

Pensemos por ejemplo en un reloj... imaginémoslo ahora transparente. Todos los engranajes se ven y el funcionamiento es fácil de descubrir.

La pregunta que me surge es... ¿De donde salió la definición que tenía inicialmente?

jueves, noviembre 08, 2007

The Art of Unix Programming

Últimamente he estado leyendo "The Art of Unix Programming" de Eric Raymond y con ésto me he dado cuenta que soy muy cerebrilavable.

En éste libro uno no se encontrará con cantidades de código shell o C, sino mas bien con una buena explicación de la filosofía Unix; la historia de Unix; las lecciones aprendidas a través de la historia, remontándose a la PDP-7; EL lenguaje predecesor de C y otro montón de cosas.

El librito es bastante ameno de leer y creo que le vendría bien incluso a las personas que no son amantes de Unix. Por ejemplo, se pasa por propiedades deseables del software, con ejemplos claros desde el punto de vista de un programador. Es decir, estoy acostumbrado a escuchar imbéciles que no han echado una sola línea de programación hablando de Modularidad. Gente que solo es capaz de asociarla al paradigma OO y se enredan ellos solos con sus Patrones, Factorys, Mixins y demás pendejadas. Mientras este libro recorre las mismas temáticas de un curso de Ingeniería de Software solo que con un acercamiento que yo lamaría De Verdad.

Como por ejemplo: como se usa C como capa delgada de pega, como se aplica la modularidad a nivel de shared libraries en Linux o con casos de estúdio como el diseño el sistema de Plugins en Gimp.

Sería tan bacano una clase de Ingeniería de software así!


Mas que repetir lo que dice el libro (eso sería muy daña libros de mi parte). Dejaré éste link a la versión online.

jueves, octubre 04, 2007

La generación de Código Automática.

Pues leyendo Slashdot me encontré un link a uno de esos artículos de Joel Spolsky (cuando realmente escribía cosas interesantes).

Uno de los puntos mas bacanos es cuando habla de la generación de código automático como una leaky abstraction. Y es ahí cuando pienso en las "maravillosas" clases de Sistemas distribuídos en Eafit.

En las clases de sistemas distribuidos la idea es pasar por los diferentes paradigmas como el clásico Cliente-Servidor, como también P2P y sistemas emergentes como agentes móbiles, Grid Computing.

Inicialmente yo estaba super entusiasmado con la clase. Yo sabía algo de sockets, entonces siendo el primer reto hacer un pequeño programa en sockets hasta lo hice en Haskell por gomoso. Después pasamos a lo que el profesor llama "middleware de alto nivel", nos olvidamos de sockets y pasamos a cosas del estilo de RPC y webservices.

¿Como debería ser una clase de Web Services?

La pregunta interesante es ¿Se deberia enseñar Web Services? Yo diría (mirando por encima de los hombros a quien se atreva a contradecirme) Web Services es tecnología, eso es como enseñar estructuras de datos enseñando como usar el paquete util de Java. Uno solito puede aprenderla a usar. Pero bueno Digaaamos que soy un radical-purista-cuasi-snob que "no esta consciente de lo que las grandes empresas de software como intergrupo y alcuadrado están necesitando".

Una clase de WS no debe ser de esta forma:

-Bueno ya que no fuimos capaces de poner NetBeans 5.5.1 con eso de Web-Services, ábranse el .Net 2003, y den Crear Proyecto Web-Service. Metan el código en esta línea. Y luego creen otro proyecto y vean como llamamos de fácil un WS. Ven?"

-Bueno si... pero como funciona bien eso de WSDL? Como hace el para construir los stubs y esas cosas?"

-Esa es la mejor parte. Es mágia! Simplemente .Net por ser una herramienta costosísima y de una gran corporación hace lo que otras herramientas no hacen. MAGIA!

Y si hablara de la explicación de P2P. Siendo un área tan interesante, con taaantos problemas por resolver terminó siendo.

-"La arquitectura de P2PS es esta. Existen otros Middlewares como JXTA pero es muuuy complicado...

...Y como ven uno como programador solo se preocupa de crear estos AdvertisementPipes, RendevouzPipes blablablabla"

"Pero vení no entiendo y la localización?"

"Se hace por medio de los advertisements"

"Si pero a quien le llegan?? pues... esque, en algun lugar se debe especificar el puerto, IP o algo"

"No... Es MAGIA!!"

Mentiras. Después de Preguntar mas de lo debido el me explico que se monta sobre UDP-Multicast y que en caso de no haber esto configurado se debe hacer explicito otros Pipes de Mas para comunicar entre subredes.

Hay Solución?

Pues una de las pocas personas que creo que sabe como debe ser la forma de dictar los cursos parece estar resignado. Esa persona era el ex-director del departamento.

Segun él, al parecer ya no se trata de ingeniería sino de técnica, aprender a utilizar una herramienta bien y listo. Algo que muchos dicen pero es triste escucharselo a él.

Al final uno vuelve al Fahrenheit de Bradbury... No piense, pensar es malo, Pensar lleva a la infelicidad.

lunes, septiembre 17, 2007

Feliz cumpleaños!

Y si

Ayer cumplí la tierna edad de 22 añitos.

Y casualmente (ese tipo de casualidades me dan miedo) En explosm pusieron esto.



Otro día hablo de cosas realmente interesantes

jueves, agosto 30, 2007

Estética de la sintáxis

Mi reunión quincenal de programación en Haskell se ha convertido en un pequeño proyecto para conocer como implementar "Parsers Combinadores" (no sé si se pueda traducir así) La idea es que antes de echar código, teníamos que leer algo de Parsers Combinadores (1). Leyendo el artículo caí en cuenta que no sabía que era un Parser Combinador (si... yo se :P) entonces googleando encontré Este Link Súper Interesante.

Mas que ser una tremenda explicación sobre Parsers Combinadores, la entrada despertó una tremenda curiosidad en SmallTalk.

Y esto porqué?

Por ejemplo SmallTalk permite Closures.

El autor dice:
"
(self letter | [self digit]) star
which yields a parser that accepts zero or more occurrences of either a letter or a digit.
In a syntax more people understand, this would look something like:
(1) letter().or( new DelayedParser(){ public Parser value(){ return digit();} }).star()
If Java had closures, it might look like this:
(2) letter().or({=> digit()}).star()
"


Y hace el comentario.

"This is better, but either way, the goal of writing an executable grammar tends to get lost in the noise. Nevertheless, it seems most people prefer (1), and the vast majority of the rest prefer (2) over the “bizarre” Smalltalk syntax. Who knows what darkness lies in the hearts of men."

En fin... usaré mi tiempo pagado en la universidad para aprender ST :)

(1)S. Doaitse Swierstra. "Combinator Parsers: From Toys to Tools"

sábado, agosto 25, 2007

Pajasos mentales para una nueva adicción

Pues con la adicción del momento a World of Warcraft puedo soñar con que realmente estoy ayudando al porvenir de la humanidad.

LINK

jueves, agosto 23, 2007

El mundo fuera de sus cuatro paredes

Pues si... Hace poco vía reddit Encontré este súper diagrama

genial no?

lunes, agosto 20, 2007

La entrada Poliglota :P

Bueno... aqui estará la entrada poliglota... la idea es hacer el famoso Hello World! usando sockets y ver que resultados obtenemos.

Por motivos de testing, puse que antes de responderle al cliente el servidor gastara algo de ciclos. Ademas, puse que para atender a cada usuario se realice un hilo.

En C
El Servidor
El Cliente

La ventaja de escribirlo en C es total control sobre como se hacen los sockets. El manejo de Hilos realizado con pthreads tiene su complique (pasar como argumento un apuntador void lo hace a uno sentir mas hombre, pero el código pierde claridad) Además toca escribir muucho mas código

En Java
El Servidor
El Cliente

Pese al alto nivel de Java, escribir un programa tan sencillo como el de sockets requiere mucho código verbose. Pese a que se ahorra uno unas cuantas líneas comparando con C, resulta necesario escribir mucho mas y separar a veces las expresiones dejando una variable temporal para no pasarse uno de los 76 caracteres por línea.

La ventaja es la legibilidad. Pese a que hice el programa muy reducido, los tipos hablan por si solos. Resulta también mas fácil de depurar.

En Ruby
El Servidor
El Cliente

Salve oh gran minimalismo de Ruby. Si uno requiere un lenguaje para salir del paso lo mas rápido posible éste es Ruby. Si se escribe bien puede ser muy claro el código, si se escribe mal puede ser tan reducido y críptico como Perl. Sin embargo, echar tan poco código trae sus desventajas. La primera es que Ruby es bastante lento y su sistema de threads a nivel de usuario no saca ningún provecho de arquitecturas SMT.

En Haskell
El Servidor
El Cliente

Este es el que a mi parecer resulta en el equilibrio perfecto. Por un lado son programas cortos. Lo fuertemente tipado ayuda a la claridad y a la correctitud. Cumplen con otra pres facil de pensar e implementar.

jueves, agosto 16, 2007

Bitacora del capitán

Fecha estelar...

No mentiras.

Casi que cerebri-lavado por mis amigos de la universidad por fin me decidí a instalar World of Warcraft. Inicialmente mi plan era tratar de emularlo usando Wine y fallé miserablemente. Intente con cedega y también falle (con wine al renderizar con opengl se ve lentísimo y con cedega error 132).

Entonces me dije "Instaleeemos Windows". Se me ocurrió instalarlo en un disco externo que tengo por ahí. Con riesgo de perder mis 160 GB de música y vídeos particioné el disco pero a la hora de instalar windows me salio error. Razón? Por ahi alguien de servicio técnico dijo "Los sistemas operativos se instalan en discos internos, los discos externos son para backups" Eso es tal vez de lo que no me gusta de Windows, odio que me digan que puedo y que no puedo hacer con las cosas que YO compro.

Después intente hacer una minipartición en un área extendida del disco... volví a fallar. Windows tampoco permite instalación en memoria extendida.

En fin ya estoy en este momento instalando windows Vamos a ver como me va.

sábado, agosto 11, 2007

Tutorial de Assembler

Pues por solicitud de de mis fans (No mentiras). Aquí está el link a un pequeño tutorial de Lenguaje ensamblador (sobre Intel (32 bits) y Linux) usando gas.

Este tutorial es el que utilizo para las inducciones en el curso de Arquitectura del Computador, del cual soy Monitor.

TUTORIAL

Alguna vez alguien me dijo que habían unos errores (y es lo mas probable) pero nunca los corregí. Si se encuentra algún error deje su comentario y yo lo corrijo.

El tutorial es muuuy básico, pero quien quita que a alguien le sea de utilidad.

jueves, agosto 02, 2007

Emacs, la edición de código y yo

En la entrada pasada escribí algo muy básico sobre IDE's, Editores y compiladores. Esta vez hablaré del proceso de edición de código y mi paso de Eclipse a Emacs.

El Programador Ideal y El Programador Real
El programador ideal (aquel que no se equivoca) tendrá una labor de la forma.

Genera los esqueletos del fuente que necesita con scripts-generador de código del IDE. Escribe el resto del código, compila y listo.

Con valores imaginarios sería algo así:
Generación de Código 5%
Escribír de código 90%
Compilación 5%

El caso real (o será solo mio?) sería:
Genero los esqueletos, Escribo código, pruebo, corrijo... eventualmente me arrepiento del nombre de alguna variable, refactorizo, me doy cuenta que algo se puede flexibilizar mejor, genero nuevo archivo (Cut-Paste), Corrijo errores de espacios de nombres, compilo, pruebo -> y así hasta terminar.

Compilación 10%
Generación de Código 10%
Escribir de Código 40%
Refactorización 5%
Cut-Paste 10%
Leer él código buscando errores 25%

Si uno se pone a ver bien, casi todo corresponde a edición.

La solución en los IDE's (mas bien de Eclipse para trabajar con Java) para hacer mas fáciles y mejores es la siguiente:

En Eclipse por ejemplo para generar código esta la pestaña source. Ahí uno puede generar getters, setters y overrides. Refactor permite cambiar nombres a las clases y además en todos los archivos del proyecto.

Una pestaña de edición: Con esto se pueden hacer pequeños find-replace, el problema resulta cuando son varios archivos, o los criterios de búsqueda no son fácilmente expresables. A veces hay posibilidad de hacer lo mismo con regex

Escribiendo código hay tres cosas fundamentales. Autoidentación, Autocompletar y facilidad para desplazarse. En Eclipse la autocompletación es mientras se va escribiendo (por ejemplo cuando se escribe punto) o también por medio de C-SPACE hasta da ideas para los nombres de las variables y además solo aconseja opciones que tienen sentido tanto sintáctica como semánticamente. Para desplazarse realmente hay un menú a la izquierda con las clases, métodos y atributos.

Para seleccionar texto está Shift y las diferentes combinaciones con Ctrl, Pg up, Pg Down y flechas. Y para leer código como hacer sin un buen highlighting?

Y ahora Emacs

Que tiene Eclipse que no tiene Emacs? Algo fundamental es la integración de la documentación. Pese a que esto no es edición, juega un papel importante en la autocompletación. Con esto uno puede saber cual es el método que uno quiere escribir y esto definitivamente ahorra tiempo a alguien que no se sabe los mil y un detalles en cuanto a parámetros y clases de java.

Pero bueno, las ventajas de eclipse se acaban cuando uno se pasa a trabajar a otro lenguaje. Los plugins disponibles para C, C++, Ruby resultan insuficientes. Carecen de todas las ventajas que acabo de mencionar.

En que es mejor Emacs?

Universalidad y Extensibilidad.
Emacs por ejemplo posee Modos para cualquier lenguaje concebible y resulta mucho mas extensible que cualquier IDE que conozca. Realizar funciones en e-lisp es mucho mas alcanzable que meterse con el API de Eclipse.

Todo está en el teclado.
Esto pareciera algo trivial. Pese a que soy alguien que no sabe teclear (es decir, usaré máximo 6 dedos de 10) resulta mas fácil concienciarse de las acciones repetitivas cuando uno las hace tecleando que cuando se hacen con mouse o por medio de un montón de wizards del editor de turno.

Emacs no pasa de moda.
JEJEJE esto parece bobo, pero no lo es. Alguna vez programe en Visual Basic 6.0. Después trate de hacer lo mismo que hacía con .Net y no fui capaz de hacer nada. Los programas que se mantienen pese a los cambios no hacen sino demostrar que poseen un buen diseño. Emacs es como los cocodrilos, si sigue existiendo... sin cambios significativos después de tanto tiempo es por algo.

No hay ventanas estorbosas!
Si. El caso típico son las búsquedas incrementales. Si uno va a buscar algo para que va a necesitar una ventana enorme sobre el texto? Por ejemplo... una búsqueda incremental en IExplorer vs Firefox quien gana?

Y es mas liviano que cualquier IDE.

sábado, julio 28, 2007

IDEs, Editores y Compiladores

Tengo que aceptarlo. Hasta tercer semestre para programar en java usaba JCreator, y para programar en C++ usaba Visual C++. Si no tenia dichas herramientas (cada uno con su respectivo botoncito de compilar super visible) no era capa de hacer nada.

El asunto de usar este tipo de herramientas no tiene nada de vergonzoso. Lo vergonzoso resulta en que a veces, tanto "user friendly" en las herramientas de programación resulta perjudicial... especialmente cuando uno está aprendiendo.

Pues bien. El semestre pasado estaba de monitor de Matemáticas Especiales 2 (Traducido a un lenguaje mas universal sería algo así como Matemáticas Discretas) y como "motivación" era un pequeño trabajo en Haskell. Cuando empecé a dar la inducción al lenguaje y comencé por lo básico.

Diego: "Bueno... Inicialmente las herramientas mas usadas son GHC y Hugs. Existe versión para Windows y Linux..."
Estudiante: "Ahí descargamos el IDE?"
Diego: "No... ahí encuentran el compilador o el interprete"
Estudiante: "Por eso"
Diego: "Ehm no... no son la misma cosa"

A eso es precisamente a lo que me refiero. Algunos personajes creen que la labor pedagógica consiste en hacerle las cosas fácil al pequeño padawan y en este intento surgen oleadas de profesionales incapaces de salirse del ambiente Java .Net de turno. Y respecto a eso hay una historia muy curiosa.

Pascal, el lenguaje desarrollado por Niklaus Wirth, tenía como objetivo principal un uso educacional de la programación estructurada. De hecho uno a veces se topa en mucho articulo que el formalismo no muy práctico de pascal resulta conveniente para escribir pseudocódigo. El uso académico de dicho lenguaje resulto en la utilización del mismo para aplicaciones de verdad simplemente porque a la hora de que el nuevo profesional escogiera una herramienta, usaría la que conocía.

En fin, no me desviare mas.

Que es un Editor?
Esta es fácil.
Básicamente hay dos tipos, editores de texto plano, y editores de "richt text" (texto enriquecido?). Los primeros son los que nos interesan. Estos permiten manipular texto en alguna de sus diversas codificaciones, pero usualmente se refiere a editores de texto plano ASCII.

A veces estos poseen capacidades para reconocer que el texto que se escribe, posee algún tipo de gramática y otras veces tienen herramientas para interactuar con el entorno (Acceso a Shell por ejemplo).

Que es un Compilador?
Sin meternos mucho en discusiones casi filosóficas como que el compilador debe ser tipo 2 en la jerarquía de Chomsky no es compilador, o cosas del estilo, entenderemos por compilador como aquel programa que, toma un Programa fuente, y entrega un Programa Objetivo.

Un Compilador es un traductor y nada mas.

Que es un IDE?

Integrated Development Environment. La idea es esa, tener un compilador, un editor y otras cosas, por ejemplo:

Debugger:
Usualmente se refiere a la posibilidad de poner puntos de parada en el programa y revisar el estado de las variables.
Perfiles de compilación
Si. Posibilidad de tener varias formas a la hora de compilar el proyecto, para ajustar opciones de optimización y demás.

y muchas otras cosas.

En fin. Creo que hasta ahí hay suficiente contexto y pese a que digo solo cosas elementales tenía que hacer un esfuerzo por arreglar el camino al resto de Desencaminados. Probablemente mañana hable de mi reciente experiencia con Emacs ya que hoy me extendí mucho.

domingo, julio 22, 2007

Estricto o Perezoso? 2

Bueno... ya no me rinde tanto la escritura por acá pero continuo con el tema.

Pues bien, estaba el problema de querer forzar a que Haskell evaluara en forma estricta y existen varias alternativas para hacer esto.

Casi Tooodo lo saque de acá

Existe una técnica llamada CPS, pero a mi parecer solo ofusca el código. Asi que pasaré directamente a seq

La primitiva seq de Haskell hace lo siguiente, dado x seq y, se revisa que x no sea _|_ (bottom), se descarta el resultado y se pasa a evaluar y.

Este mecanismo pareciera estúpido, pero con este se pueden hacer cositas como la siguiente. Digamos que queremos forzar la evaluación de y en esta función foo x y

Podemos hacer
foo x y | y seq True = f y 
| otherwise = undefined


Otra forma de forzar la evaluación es mediante el operador $!

el cual está definido así

f $! x = x seq f x


Esto quiere decir que x $! y $! z
Evalúa z, después evalúa y y se lo aplica a z y hace lo mismo con y.

Por último si se está utilizando ghc, se puede utilizar la extensión de bang patterns. La cual permite de una vez en el pattern matching de una función evaluar en forma estricta. Siguiendo el ejemplo de foo es simplemente hacer lo siguiente.

foo x !y = f y


En fin espero que esto le sirva a alguien :)

lunes, julio 16, 2007

Aviso parroquiano

Bueno ya arregle la imagencita de arriba y ya actualice los blogs de la derecha siguiendo la vieja regla de convivencia "linkeame que yo te linkearé" jajajaja

:)

jueves, julio 05, 2007

Estricto o Perezoso?

Pues si... desde hace poco ando trabajando en un proyectico de programación en Haskell, y no hago sino encontrarme inconvenientes :P.

Haskell es un lenguaje funcional llamado perezoso por la forma como evalúa las "expresiones" (diría funciones, pero así queda mas entendible para vírgenes mentes imperativas... como la mía).

La forma de evaluar perezosa básicamente implica que se comienza desde lo que está mas afuera:
Por ejemplo en C o C++ (o casi cualquier lenguaje imperativo) si escribimos...
F1(F2(argumento1),F3(argumento2)); 

El orden de evaluación sería F3, F2, F1 en cambio en un lenguaje perezoso (Lazy) se evaluan F1, F2, F3.

La pregunta obvia que surge es la siguiente...
Como voy a evaluar F1?? no tengo F2 y F3!!

Y la respuesta es sencilla... Los necesito o puedo seguir la ejecución? cuando los necesite los evalúo, sino guardo en memoria un recordatorio (hey acordate de evaluar F1 y F2)... usualmente al final ya toca evaluarlos, pero en los lenguajes funcionales muchas veces se suele reescribir y reescribir los terminos y yaaaa al final se evalúa.

Por ejemplo (sacado de estesitio)

La función:
foldr (+) 0 [1,2,3,4]

Va a operar con + todos los números (Partiendo del cero que se le pasa).

Lo interesante es ver como pospone la evaluación...
   1.  foldr (+) 0 [1,2,3,4]
2. 1 + foldr (+) 0 [2,3,4]
3. 1 + (2 + foldr (+) 0 [3,4])
4. 1 + (2 + (3 + foldr (+) 0 [4]))
5. 1 + (2 + (3 + (4 + foldr (+) 0 [])))
6. 1 + (2 + (3 + (4 + 0)))
7. 1 + (2 + (3 + (4 + 0)))
Y ahora...
Para que evaluación perezosa?

Hay muchas cosas bacanas (de hecho el link anterior tiene muchas), pero mi favorita es la posibilidad de manipular objetos infinitos.
take 5 [1..]

La lista [1..] es la lista de todos los enteros positivos (una lista por comprensión). Teniendo esto claro, la función anterior toma los primeros 5 elementos de los enteros positivos... con una evaluación estricta, se evaluarían inicialmente los parámetros, lo cual implicaría tiempo infinito, mientras que con evaluación perezosa evaluo solo lo que necesito.

El problema?

Pues lo que llame recordatorios ocupan memoria... y a veces todo el heap se va en recordatorios :S

Como Solucionarlo?
Dado que me extendí mucho eso lo dejo para el próximo post.

lunes, julio 02, 2007

Desconfianza...

Hace poco se aprobó en mi universidad lo que será el nuevo pénsum de ingeniería de sistemas (En Eafit). Esta reforma había sido precedida por otra reforma la cual tenía un especial interés en hacer énfasis en Ingeniería de software. Contemos mas bien que se iba a hacer y que se terminó haciendo.

Inicialmente se pensaba eliminar algunas materias de ciencias básicas, para dar mayor profundidad a elementos de construcción de software (que clase de temas se habrían de incluir en estas materias... no me pregunten) Entre las materias que se pensaban eliminar estaba por ejemplo Electricidad y magnetismo (Si, es cierto, iban a hacer ingenieros de sistemas que cuando conectan un computador no saben que es voltaje), se planeaban eliminar materias como cálculo vectorial y otras... El énfasis mencionado abrió hasta la posibilidad de mutar a la carrera para convertirla en Ingeniería de Software (esto no le gustó incluso a muchos Egresados)

En fin, después de unas críticas de algunos profesores se le dió un vuelco total a la reforma y se decidió por eliminar mas bien algunas materias de ingeniería de software (que actualmente es algo así como UML 1, 2 y 3 con algo de tabú programming) y se decidió por conservar casi en su totalidad el programa. A excepción de UNA cosa.

Se planea fusionar la parte de diseño de compiladores con otra materia (actualmente Matemáticas Especiales 3, que es mas bien "Fundamentos de teoría Computabilidad").

Hace relativamente poco leí un articulo bien interesante

Respecto a esto pareciera existir una inevitable tendencia a la ocultación de los mecanismos detrás de la computación. No se porque pareciera que un profesor es capaz de dar una materia en forma de curso nocturno de java y dormir tranquilo. Tal vez la ausencia de curiosidad de los estudiantes por tener el conocimiento para domar la máquina (o la falta de capacidad intelectual para afrontarla) sea un factor predominante para esto.

sábado, junio 30, 2007

Mitos y realidades

Hay simplemente algo que no soporto.

Que es?

Gente discutiendo en forma ilógica. Gente añadiendole nieve a la bola mito de turno y además creyéndose los seres mas tesos del universo.

Hablando desde mi ignorancia casi fingida hago que un recién conocido diga que Linux es una Mierda, que FreeBSD es el BSD de las putas, que al kernel de Linux todo el mundo le mete la mano, que el kernel de BSD de estilo pseudo-microkernel es mas rápido que el de linux (En serio necesito que alguien me explique como se mide la "velocidad" de dos kernels distintos).

Cuando sepa al respecto entenderé algo respecto a esto.

(PD... me dijeron desarrollador y no me gustó)

jueves, junio 28, 2007

"False Advertising"

Inicialmente hice este blog como reemplazo al pedazo pseudoliterario que tenia en msn spaces. Sin embargo, por razones del destino (Y con esto me refiero a que no sé porqué) este blog se ha vuelto en cierta forma monotemático hablando de lenguajes de programación, software y renegando de la ineptitud de todo el mundo.

En la imagencita se da uno cuenta que realmente es "false advertising" porque no volví a escribir de sci-fi ni tampoco de matemáticas.

siendo asi... dejare este exclusivamente para cosas de computación... y de matemáticas... Lo cual tiene su estrategia yo creo que de target :P

Dejaré aqui las cosas "duras"... (Después cambio el letrerito).

Y las criticas literarias de alguien que no sabe nada, las descargas psicomorboafectivas y temas para el noingenierodesistemas irán en el otro

lunes, junio 25, 2007

Anti-Objetos

Leí un articulo hace poco que muy interesante sobre la noción de antiobjeto.

Hacen el ejercicio de poner estudiantes a que generen códigos de inteligencia artificial para los fantasmitas de pacman. En estos intentos sucede esto:

The psychology of programming attempts to explain
programmer’s intuition. Syntonicity [31] is an introspective
behavior that makes us want to be the ghost in order to think
about what the ghost should do and how it should do it.


En el contexto que habla el artículo, pareciera (y aqui hablo soy yo, el artículo en ningún momento resulta una crítica) que la orientación a objetos favorece esta introspección. La delimitación de un programa a "entidades abstractas con identidad, comportamientos y relaciones entre si" es un escenario mas apto para la introspección que un programa digamos lógico ó estructurado.

Me explico:

El razonamiento usando la modularidad de objetos da esto: "huy tengo una clase fantasma (probablemente con una posición y algo mas) y otra pacman... que haría si yo fuese un fantasma para cazar a pacman?"... que tiene esto de malo?... en el artículo muestran como puede lograrse con una cosa que llaman "difusión colaborativa", obtener una propiedad emergente simplemente asociando una función de cercanía a pacman que es computada por las "baldosas?" del piso (quien habría tenido en cuenta las baldosas en el UML... yo no :P)

Ahora bien, aquí es donde radica mi infundada teoría... creo que la noción del programa estructurado, como totalidad (aquí olvídense de módulos y esas maricadas... programas horribles en quick basic sin funciones donde todo esta en un archivo y todo está mezclado) impide esta introspección y en cierta forma puede permitir descubrir estas soluciones que dependen no de la reacción de la suma de las partes sino de las reacciones de un sistema holístico.

Ya solo falta tomar el conjunto de ratas de laboratorio de primer semestre y hacer la prueba.

(No sé hasta que punto los lenguajes funcional inhiban la introspección)

jueves, junio 14, 2007

"Orientado a Objetos" 2

Please don't fall into the trap of believing that I am terribly dogmatical about [the goto statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline! (Edsger Dijkstra)

Anteriormente dijimos como OO surge como una forma adicional de agregar modularidad, en forma análoga a como en algún momento lo hizo la programación estructurada; sin embargo, muchas veces el hype resulta contraproducente y degenera las buenas ideas en abominaciones imprácticas. Estas abominaciones no son mas que mitos de las especie "OMG it have to be OO!!!" y sobre eso será este post, Los mitos de la programación orientada a objetos

OO Flexible
Inicialmente creo que la flexibilidad siempre será un trade-off do otras propiedades del software. Este blog dice lo que pienso al respecto. A la hora de echar código comience por la brevedad y luego optimice las otras propiedades en la medida de lo necesario.

Pero sin importar lo que yo piense, algo incomprensible, son las formulitas con las que trabajan los que solo conocen de objetos (habrán excepciones obviamente)

K * clases = Flexibilidad
C * (interfacesImplementadas) = Flexibilidad

Es Decir a mas clases y mas interfaces implementadas mayor flexibilidad.

Clases de la forma: public class Point implements Serializable, Collection, Cloneable, List, Geometry, Observable, Map, Enumeration...

Que no tienen nada de malo si uno usa todas las interfaces... sino botadera de tiempo y memoria.

La verdad olvide que mas iba a decir en este post... era mas bien una critica a ciertos programadores. En fin

lunes, junio 11, 2007

Nuevo C++

Pues en estos momentos se esta diseñando lo que sería el nuevo estándar de uno de los lenguajes mas usados del mundo. Hace poco vi aqui la descripción de algunos de los nuevos features por puño y letra del mismo Stroustrup.

Me parecen muy bacanas algunas de las cosas que se tienen planeadas. Y a modo de repetición mencionare (o parafraseare?) las que a mi mas me gustaron :P

1: template <> using Vec = vector <>>;
2: Vec v = { 2.3, 1.2, 6.7, 4.5 };
3: sort(v);
4: for(auto p = v.begin(); p!=v.end(); ++p)
5: cout << *p << endl;

Que es lo nuevo?
1. El using, es una especie de typedef pero permite tener definidas algunas cosas dentro de la definición del template, ahi utilizan el allocator "My_Alloc" pero permiten que uno defina el tipo T.
2. Asignamos el vector con una lista de elementos. Esto solo se podía con los "agregados" (i.e arreglos y estructuras)
3. Usualmente habría que definir un montón de cosas para hacer las cosas asi tan campantes. Pues esto ilustra el mayor cambio en el estándar, se llaman "Concepts". Según Stroustrup es:

Basically, a concept is the type of a type; it specifies the properties required of a type.


Algo parecido a las jerarquía de clases de haskell? tal vez. Eso fue lo que me pareció.

4. Esto es lo que mas me llamó la atención... hay un blog que me dejo marcado respecto a a forma de pensar respecto a los lenguajes de programación.
hablaba de:
Rule #2: Dynamic typing with optional static types.

Pues esto esta lejos de ser tipado dinámico, pero el auto es para seleccionar el tipo dependiendo de lo que devuelva la expresión (supongo en tiempo de ejecución). Lo cual resulta mas corto que:
for (Vec <> ::const_iterator p = v.begin(); p!=v.end(); ++p)
cout << *p <<>

y Además mas apto para programación genérica.
Dentro del otro tipo de cosas que piensan agregar es:

*Garbage collection opcional.
*Hash Maps
*ReEx

Y depronto una librería de sockets y una de hilos :)
Todo esto sin perder compatibilidad con el estándar anterior (C++98) y sin aumentar el overhead.

PD: si jaime, use el formato (copiado del source de geekorito) para el código, gracias :)

domingo, mayo 27, 2007

A veces la película no es tan entretenida.

Antier me iba a ver Life of Brian de Monty Python pero lamentablemente los subtítulos estaban con un delay respecto a la película. Busqué entre las opciones de Totem pero no vi forma de cambiarlo.

Entonces dije... "pues no seré un hacker pero demás que el formato no es del todo inentendible"

Abrí el archivito y resulta que el formato era hasta pendejo.

345
00:24:34,850 --> 00:24:38,718
¿ Qué es esto?
¿''Romanes eunt domus''?


Lo primero era el número del subtitulo, lo segundo la hora en la que aparecía dentro de la película (inicio-->final). y después lo que se decía en ese instante.

Y pues bueno, con este scriptsito corregí los subtitulos.

Al final ya me dio sueño, y no me vi toda la película. :P

martes, mayo 15, 2007

Que es orientado a objetos?

Hace poco leí un articulo(1) donde definen un lenguaje funcional como:

"A functional language is one in which function types are first-class"

y definían first class como los tipos que pueden ser retornados, pasados por parametro, almacenados en estructuras de datos y otras cosas.

Lamentablemente para los objetos no sucede lo mismo. Tal consenso en la definición no existe, sin embargo, hay otro articulo(2), que revisaba gran parte de la literatura sobre objetos y clasificaba cuales eran los conceptos mas asociados a este paradigma.

Para mi sorpresa el concepto mas asociado no es ni objeto ni clase.
Sino...

Herencia (CHAN CHAN CHAAAAAN) le seguían objeto, clase y encapsulación.

Aquí es cuando uno se pregunta, puede haber programación orientada a objetos sin herencia? sin encapsulación?

Pues bien... yo diría que si, pero no soy nadie para decirlo. Para mi un lenguaje orientado a objetos es:

"A OO language is one in which Objects types are first-class"

Y a esto agregaría un conjunto de operadores de generación de objetos (llámelos composición herencia blablabla).

Y que es un objeto?

Inicialmente es un tipo de dato. Además posee identidad, estado y un conjunto de comportamientos.
con base a esto seguirán las posteriores divagaciones

:D

(1) Functional programming is not Self-modifying Code
(2) The quarks of object oriented development

domingo, abril 29, 2007

"Orientado a objetos" 1

Recuerdo una frase de Stroustrup que decía:
Certainly not every good program is object-oriented, and not every object-oriented program is good.


Pues bueno, tengo planeado divagar sobre el paradigma objetual y para esto planeo hacer 2 o 3 post al respecto. Inicialmente trataré de definir que es lo que quiere decir orientado a objetos, hablaré un poco de la historia de los lenguajes de programación (creo que mas que la historia, sobre el desarrollo de los diferentes paradigmas en una forma muy libre).

Al principio, todo era caos y oscuridad. Inicialmente la programación se realizaba siempre en lenguaje maquina. Dada la escasez de maquinas, y las capacidades limitadas se requería que cada programa fuese óptimo. De hecho, una anécdota interesante es que cuando se diseñaba FORTRAN se decía que este debía generar código comparado al generado "manualmente" en ensamblador ya que sino nadie lo utilizaría.

Pues bueno, en esta época de programas dependientes de las máquinas, había total libertad, por ejemplo se podía generar control flujo mediante la modificación del mismo programa. (Una forma de hacer esto es reescribir una instrucción de salto con una que no haga nada dada una condición.) y bien... posteriormente llego la programación procedimental a la que siguió la estructurada.

El cambio entre la programación procedimental a estructurada fue básicamente dado por un articulo de Edsger Dijkstra "Go To Statement Considered Harmful"... La idea detrás de la satanización del goto era básicamente dada porque un programa elaborado con sentencias de selección (switch, if) y sentencias loop (repeat for while) era mas fácil de entender. Y esto es consecuencia simplemente porque cada bloque podría entenderse por separado. (cabe mencionar que existe una demostración de equivalencia entre programación estructurada y funciones computables... turing completitud?)

En fin. De la misma manera, surge posteriormente el paradigma objetual. Lo que hacia la programación estructurada modularizando los procedimientos, lo hacia el objetual con fragmentos de código-datos en algo llamado TDA (tipos de datos abstractos). Y bien, es en este punto donde la gente discute sobre la revolución de los objetos. Es acaso el polimorfismo? la noción de mensaje que introdujo smalltalk? encapsulamiento? no se. Realmente, pese a que todas las características anteriores son propias de objetos hay una falta de formalismo que responda a.

Que es un objeto?

Eso lo dejo para el próximo post.

(Correcciones a mi introducción historica seran bienvenidas... porque la hice de memoria y probablemente abunden :P)

martes, abril 24, 2007

Frustración

Pues, si.

Este es un post fruto de la ineptitud y auto-compasión de alguien que hace una huxley-ana jerarquía de la humanidad, quiere ser un alfa, pero al parecer es un beta. Peor aun... no soporta ser un beta.

La búsqueda de practica fue una perdida de tiempo. Terminaré probablemente en el mismo lugar que aquel asesino del hacha. En el subconjunto al que no quiere pertenecer.

A todos los que les dije imbéciles en la cara, siguen siendo imbéciles.

jueves, abril 12, 2007

Verdadero amor

Y si... tan especial como la primera vez

Nada tan incomodo y emocionante como la pasta dura :D



Recién me los trajeron ayer, pero ya hay cositas super interesantes (como la frase que cite en la entrada anterior de Stroustrup) Pero bueno, todavía me falta invertir mucho mas tiempo a ambos libros, pero contemos algo que sucedió que tal vez a alguno le sorprenda.

Hace poco estuve en un pequeño seminario de investigación con algunos profesores de la universidad. El tema que se trato fue el de la aplicación de métodos formales en la industria y la persona que daría la charla no era nada mas ni nada menos que una de las profesoras en la universidad que cuenta con doctorado (chan chan chaaan).

Dentro del tema, surgió UML (porque?, no sé) el caso es que un amigo hizo la perfecta pregunta. ¿UML es solo para orientación a objetos? la respuesta de la señora esta fue, palabras mas palabras menos, que uml dentro de su montón de diagramas especificados de carácter sobrespecífico tenia posibilidad de modelar de formas diferentes a la objetual (una respuesta mas diplomática que correcta)

Con el handbook Computer Science en mi poder, me dio por revisar cuales eran los temas tratados en la sección de ingeniería de software. Casualmente pasando paginas encontré diagramas de casos de uso. Este diagrama hacia parte de una breve explicación de UML (3-4 pags máximo) de un capitulo llamado Object Oriented Design, el cual contaba con alrededor de 12 pags (si, aunque no lo crean UML ES para diseño orientado a objetos y mas sorprendente aun, mas de la mitad de la sección de diseño orientado a objetos no era UML)

Para poner las cosas en perspectiva, esta sección de diseño orientado a objetos con una tercera parte de UML es el segundo capitulo mas pequeño dentro de la sección de ingeniería de software (después de arquitectura de software), es decir, de 10 capítulos de la sección de ingeniería de software, UML es la tercera parte del segundo capitulo mas pequeño. Y HAY DIAGRAMAS EJEMPLO!!

miércoles, marzo 21, 2007

Siguiendo con Java

Acabo de leer un "interesante" articulo llamado Why I Am Not A Java Programmer

Hay que aceptar que hay cosas charras y que comparto como:

``Hello World'' should be one statement

There's more to life than OO

Bureaucratic privacy rules

No dynamic method generation


y blablabla.

Pero bueno, al final se habla de algo bien interesante. Una cita de Stroustrup que dice lo siguiente:

"The connection between the language in which we think/program and the
problems and solutions we can imagine is very close. For this reason
restricting language features with the intent of eliminating
programmer errors is at best dangerous."

Yo realmente siempre he creído en algo. Si bien es cierto que Java es un lenguaje con muchas restricciones, y que la forma de pensar es influida por las herramientas que usamos para programar, creo que diseñar soluciones con espacio de pensamiento reducido es también un reto intelectual. A veces la falta de recursos permite explotar el ingenio que solo surge ante la escasez.

Creo también que por mas multiparadigma que sea un lenguaje de programación, no hay mejor forma de ampliar los horizontes del pensamiento, que conocer asi sea superficialmente cuantos lenguajes de programación se atraviesen. A mi me sucedió esto cuando conocí los lenguajes funcionales, Haskell para ser exactos. Es difícil en un principio manejar la recursión, pero una vez dominada resulta muy útil...

Como siempre queda un texto sin conclusión ni nada.

lunes, marzo 19, 2007

Desatrasandome de java 1.4

Bueno, después de mucho tiempo, por fin me dio por programar otra vez en java. Y esta vez me puse a leer sobre las cositas nuevas en Java 1.5 (ya se que estamos en la 1.6, pero en la 1.6 no vi cambios que uno realmente utilice).

Los cambios son básicamente los siguientes:

Annotations.
Es básicamente un metalenguaje, es decir, viene siendo algo parecido al preprocesador de C.

Genéricos:
No mas Casts! ya las colecciones pueden usar algo parecido a los templates de c++.

Ej:

Vector <Integer >= new Vector<Integer>();

AutoBoxing Auto-Unboxing: Una de las cosas que le critico a java es no poder hacer 27.metodo_de_la_clase_Integer. Pues bueno. Pese a que este nuevo feature no lo permite hacer, facilita un poco las cosas para trabajar con la dualidad objeto-primitiva

Ej (Todos son sacados de Java5 in a nutshell):

Antes:
ArrayList<Integer> list = new ArrayList<integer>();
list.add(0, new Integer(42));
int total = (list.get(0)).intValue();


Ahora:
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(0, 42);
int total = list.get(0);

Iteradores: todavía se esta lejos de poder hacer un array.each{blabablabla} pero ya facilitan las cosas

Ej:
ArrayList<Integer> list = new ArrayList<Integer>();
for (Integer i : list) { ... }

(aqui particularmente la sintaxis me parece fea... pero desde que sirva :S

La parte de enumeraciones: Nunca he utilizado enumeraciones, se me olvidan que existen. pero bueno, a quien pueda interesar:

public enum semaforo{rojo,verde,amarillo}

Imports estáticos: A veces es cansón hacer la de java.util.paquete.Clase.constante, Pues bueno, puede uno hacer los imports estáticos:

Ej:

import static java.awt.BorderLayout.*;
...
getContentPane().add(new JPanel(), CENTER);

Salida con formato: Básicamente el printf:

System.out.printf("name count%n");
System.out.printf("%s %5d%n", user,total);

Entrada con formato: Entrada estandar siempre ha sido una mierd* en java... ya es menos mierd*.

Scanner s= new Scanner(System.in);
String param= s.next();
int value=s.nextInt();
s.close();


Y... para terminar! args variables!

void argtest(Object ... args) {
for (int i=0;i < args.length; i++) {
}
}

argtest("test", "data");

Si ya se, no es la gran maravilla pero algo es mejor que nada. A mi la verdad el desarrollo de java en estrategia bola de nieve no me gusta. Al final nadie es capaz de lidiar con una sintaxis tan llena de casos especiales, pero bueno.

martes, febrero 27, 2007

Programmers Don't Like to Code

Pues estaba viendo en reddit una pequeña discusión sobre si los programadores les gusta o no programar.

Inicialmente estaba la postura de este donde básicamente dice que los programadores no gustan de programar, sinó mas bien de resolver problemas. Que si los programadores disfrutaran realmente programar no disfrutarían tanto una buena librería :P

Por otro lado estaba: este otro y el título es mas que diciente...

Esto que dice resulta interesante.

A lot of companies and managers like to fill the programmer's life with lots of other stuff, like meetings and status reports and requirements analysis and writing test plans and fighting environment issues and begging for decent computers.


Pues bueno...

Cuando decidí estudiar sistemas fueron básicamente 2 las motivaciones.

1. Resolver Problemas
2. Aprender de Muchas Áreas (Multidisciplinaria).

Resolver Problemas. Tal vez ahí es donde encuentro la mayor satisfacción, sin embargo, a diferencia de lo que pensaba el primer blogger yo creo que la etapa de codificación es de por si otra etapa de solución de problemas.

Por un lado esta la etapa "abstracta"... llámese hacer pseudocódigo, diagramas de clases, de flujo, modelos formales o en mi caso simplemente obsesionarse con el problema y no prestar atención en clase, rayando cosas que solo yo entiendo en la hoja de atrás del cuaderno. En esta etapa la solución al problema resulta ser "ideal" y en cierto sentido platónico pura :P. Aquí es donde tal vez menos estress me dá.

Después de llegar a una posible solución sigue una etapa de verificación. Para mi esta etapa sería hacer un programa que realmente funciona (en el caso de modelación formal podría uno arrancar a hacer demostraciones... que cool :D). Aqui ya surgen otro conjunto de problemas de tipo técnico

Que lenguaje utilizo? (lo cual contempla: en cual lo hago mas fácil, rápido, eficiente y bonito)
Que librerías uso? (Cuales puedo ya existen, cuales se manejar, cuales me toca aprender, cuales me toca hacer)

Después de la parte de solución técnica de herramientas... echando código sigue oootra etapa de solución de problemas. MATAR BUGS. Nada mas satisfactorio que encontrar que la bobada que le estaba tirando a uno el programa y que al corregirla hace que funcione. A veces la obsesión misma no me deja dormir, sueño con puro código y al otro dia el sueño me ha revelado el problema.

en fin.

sábado, febrero 17, 2007

Primera computadora cuántica (comercial)

Pues si... Después de buscar mucho rato, POR FIN! un buen articulo al respecto. (esos imbéciles de slashdot solo son capaces de hacerse publicidad a sus pobres blogs).

Pues bueno, algunos apartes (los que a mi me gustaron) de la entrevista a David Deutsch sacada de aquí

WN: Can you talk a little about the importance of simulating quantum systems, and give an example?

Deutsch: Yes. Whenever we design a complex piece of technology we need to simulate it, either in theory by working out the equations that govern it, or as a computer simulation, by running a program on the computer whose motion mimics that of the real system.

But when we come to designing quantum systems, we're going to have to simulate the behavior of quantum super positions, which is, in Many Universes terms, when an object is doing different things in different universes. On a classical computer you'd have to work out what every single one of those was, and then combine them in the end with the equations governing quantum interference.

...

WN: For your purposes, the importance of quantum computing is in the general case more than in the specific-use case.

Deutsch: Yes. The fact that the laws of physics permit themselves to be simulated by a quantum computer is a deep fact about the nature of the universe that we will have to understand more deeply in the future.

...

WN: That's actually D-Wave's stated goal as well: essentially 1,000 qubits in two years. Do you think engineering-wise, and this is not completely within your realm, they will be able to maintain enough coherence at that level to create a practical computer.

Deutsch: As you said that really isn't my field. Maintaining coherence itself isn't quite enough. They've got to maintain coherence in the operation that I spoke of; that is, the arbitrary superposition, the arbitrary entanglement, and so on....

I don't know. The technologies I've seen so far have got way fewer than 1,000. They've got way fewer than 16. I always have to ask whether the claimed number of qubits are qubits that I would count as qubits by these stringent criteria, or whether it's merely two-state systems that can in some sense act in a quantum way. Because that's a much more lenient criterion.



Y si... aquí es cuando uno se llena de escepticismo y espera que se hagan las pertinentes verificaciones que el método científico manda
Sera que si alguna vez la computación cuántica reemplaza la convencional seguirán existiendo los casos de uso?

domingo, febrero 11, 2007

Puro Odio!

No se hasta que punto tengo el síndrome de...

all work and no play makes jack a dull boy all work and no play makes jack a dull boy all work and no play makes jack a dull boy

La verdad si se hasta que punto. Y no me importa...

Reviso Correo y veo una duda de uno de los estudiantes de monitoria

From: estudiante inepto cualquiera
subject: Ayudaa!!

Monitor, a ver si me podías ayudar con los ejercicios 6-9 y 38... gracias, mandámelos al correo antes del martes.

No se hasta que punto cada vez creo que la actitud servicial con la que comencé fue desplazada por la de Diego Neurótico. Los ejercicios por los que me preguntó resultaban ser unos sobre crecimiento de funciones, y como precisamente estos resultaban ser tema no explicado en clase Le repondí a ese estudiante de la forma mas críptica posible. (BUAJAJAJA) (realmente no fue críptica, pero creo que igual no entenderá)
Ayer por ejemplo dando el tutorial de circuitos lógicos sucedio lo siguiente.

Diego: "Mira es muy fácil... El sumador básicamente es esto.
B0 + B1 = C R

Solo se genera carry cuando B0 = B1 = 1 (i.e 1 + 1 = 10)
Y R solo es 1 cuando los valores de B0 y B1 son diferentes (i.e 1 + 0 = 01 y 0 + 1 = 01 )

Que compuertas lógicas podemos asociar?
Fácil! un And y un Xor!"

Persona: "WOOOOOOWWWW vos sos un duro en electrónica"

Hay Dios... siquiera el scope de carrera de esa gente no es (y nunca sera) aplicaciones de verdad.

Y hay otras decepciones...

Pero las dejare para otro día.

miércoles, enero 31, 2007

Dawn of the age of Robots

Acabo de leer un articulo de Bill Gates sobre la robótica, y sobre como impulsar este campo usando algunas de las tácticas utilizadas en la revolución del PC.

Básicamente, Gates habla de estandarización, de crear puentes comunes entre software-hardware, de facilitar la labor de desarrollo de robots de la misma forma que BASIC facilitó la utilización de los diferentes computadores personales y puso el desarrollo de estos en manos de mas personas. también habla del esfuerzo de investigación de Microsoft en esta área de integración (muy a grandes rasgos).

Como aficionado a la ciencia ficción e IA, los robots han pasado por mi cabeza muchas veces y la verdad creo que el momento en el que la humanidad se dedique a hacer únicamente cosas creativas y dejar las rutinas a los robots (como en algún momento lo establece Moravec) esta bastante lejos. Y esto básicamente por dos cosas... Creo que hay "rutinas" que están muy lejos de la realización robótica, y que la creatividad esta lejos de muchos especímenes humanos (lease maquinitas de hacer dinero haciendo paginitas web o cualquier otra actividad casi mecánica)

Sobre el efecto de una llamada revolución de robots se ha escrito mucho (no todo Sci-fi)... lo único que espero es no tener que hacer Defrag a mi a mi robot domestica cada 2 o 3 semanas. :P

domingo, enero 21, 2007

Las cinco innovaciones...

Acabo de leer el articulo de enter donde se habla de las "revolucionarias" innovaciones que quizás nos sorprendan dentro de 5 años.

Salud a distancia... creo que ya hay casos (sé de cirugías a distancia)
Solución Crisis de agua... soluciones caras para los sauditas, dinero facil y eso.
Traducción en tiempo real... hay avances en sistemas estadísticos para traducción, no le daría 5 años
Celulares leerán Mentes... esas interfaces como la del videito famoso del señor manejando el mouse con el cerebro me llenan de dudas, pero ahi si no se.

Pero por favor... Internet 3D??

Que clase de persona en su sano juicio cree esto tiene alguna utilidad??

Hay muchas razones para pensar que el Internet 3D tendría problemas y todas giran en torno a la simplicidad.

Simplicidad y errores

Un profesor dice muy sabiamente que aquel que haga software partiendo del hecho que no se van a cometer errores cometió ya el primero. Los bugs han contaminado desde los "hola mundo" de los novatos en programación, hasta una que otra sonda de NASA, y ha medida que el software se hace mas complejo, es mas fácil equivocarse y las consecuencias pasan de ser incomodas a catastróficas.

Decir que el Internet 3D es mala idea porque es agregar complejidad y probabilidad de error a las aplicaciones seria en cierta forma mediocridad, seria dejar de hacer algo por sus dificultades... falta de ambición tal vez. Partir del hecho que no habrá errores seria ingenuo... que clase de errores podrían suceder?

Seria gracioso que alguien programara una tienda en Internet (3d obviamente) que con un mal Clipping hiciese que cualquier ladrón modelado con polígonos al revés pasara inadvertido por el vigilante. Una mala detección de colisiones permitiría pasar las paredes de la caja del banco y todo tipo de absurdos...

No mentiras, la ingenuidad es a propósito... estos errores nunca sucederían. Pero acaso puede justificarse el extra de complejidad por la experiencia 3D?, es útil? y si lo es que ventajas trae?

Congestión en red y Requerimientos mínimos

Como dije en el blog pasado, me canse de msn live, porque mi maquinita de 800 Mhz, no me daba para mostrarme ese montón absurdo de animaciones innecesarias. Cuando escribia se hacia un lag de unos 2 Segundos hasta que por fin me mostrara las letras.

Hay que aceptarlo... no todos tenemos los computadores mas actuales, ni las conexiones mas rápidas. Con que cara los desarrolladores de este tipo de tecnologías le dirán al tercer mundo "lo lamento, tu computador no cumple los requerimientos mínimos". No poder entrar a una tienda por no disponer de la ultima tecnología o el dinero para comprarla seria simple discriminación, no? el equivalente tener un centro comercial no adaptado para gente en silla de ruedas.

Ya lo veo venir.

"este sitio todavía no esta adaptado para minusválidos sin flash"

(lo peor es que ya me ha pasado)

Usabilidad

Un amigo alguna vez dijo (palabras mas, palabras menos) que por mas Opengl y directX 10, una experiencia que utilice una pantalla no deja de ser una experiencia 2D.

Quien no ha visto a alguien con poca experiencia e los juegos 3d volteando la cabeza y el control en una curva? La verdad, veo difícil explicarle a mi madre como moverse por un mall virtual en 3d.

Ennnn fin...

Si algo tiene de bueno el internet es adimensionalidad. Si compro algo en internet es simplemente hacer click para ir de un lugar a otro sin pasar por un montón de puntos intermedios innecesarios.

Si no quiero andar en un supermercado, para que voy andar en uno virtual? chocando con gente y frustrándome porque no me dejan pasar o ver las cosas que quiero ver...

gracias...

Pero no gracias

martes, enero 02, 2007

Hasta la vista baby...

Alan Turing hizo grandes aportes a la ciencias de la computación. Pese a ser conocido principalmente por la maquina de Turing, Turing fue de los pioneros en temas como la hipercomputación con su famosa Turing con oráculo, redes neuronales (redes "B-Type") y muchas otras cosas.

Dentro de su trabajo con la maquina de Turing, es famosa su demostración sobre la indecibilidad del problema de la parada, la cual implica la inexistencia de un programa el cual recibiendo como entrada otro programa pueda decir que este termina o se queda en un bucle infinito. Esta demostración (como la mayoría de demostraciones de inexistencia) parte del hecho que el algoritmo existe, pero a partir de la elección de una entrada particular (en este caso el algoritmo mismo) se llega a una paradoja.

Recuerdo que cuando leí por primera vez esto, me preguntaba si seria posible un replanteamiento del algoritmo que en vez de 2 salidas (si, no) pudiese dar como salidas (si, no, tal vez), es decir, dividir las entradas en "definitivamente paran" "no paran" "realmente no se"... En medio de mi ingenuidad creía que la mayoría de los problemas de parada con los que se encontraría un programador serian de la clase "se me olvido incrementar i" (donde i es un entero de 32 bits) y otro tipo de bobadas que se podían hallar simplemente a punta de fuerza bruta.

La pregunta que me intrigaba en ese entonces era; mas que hacer un algoritmo que espere a ver si para otro algoritmo (eso lo puedo hacer yo :P); ver que tan lejos podría llegar un algoritmo en disminuir la cantidad de "tal vez" dentro del espacio de posibles entradas. Tenia hasta la ligera idea (sin absolutamente ningún argumento para creerla) que los "tal vez" podían llevarse a un porcentaje mínimo...

Sin divagar mas, hace poco leí en el "new-scan" de Scientific American sobre un software que precisamente hacia el debug anti "freeze" , el cual lo estan utilizando especificamente para los drivers del Windows Vista. El nombre del programa... Terminator. El programa convierte la representación del código fuente (los loops y esas cosas) y lo convierte a una representación finita, y luego busca una demostración de correctitud (muy a lo Dijkstra).

Este programa no tiene ningún problema con la demostración de Turing, el programa puede resolver el 99.5% de las entradas (como sacaron el 99.5%? ni put@ idea)... ademas hacen la salvedad que en el "pequeño" espacio de entradas solubles, no entran problemas difíciles matemáticos, así que la ideita de hacer un driversito que incluya una version de la conjetura de Goldberg, o algunos problemas de Hilbert y esperar una respuesta del debugger es mas bien ingenua.

Los drivers ademas de lo anteriormente mencionado tienen mas simplificaciones que hacen posible a Terminator. Son relativamente independientes de otras instancias de software (llámense librerías o procesos) son relativamente pequeños y la interacción con usuarios es nula. Estas ventajas para análisis son vistas como retos a enfrentar para los autores de Terminator, y no es del todo absurdo algún día tener un mensaje de error de la forma:


Semantic Error at line 247
...While's condition never breaks

(me late que eso esta en un muy mal ingles)