Softenido.

FindRepe 0.9.0 - ES

2010-07-22T20:07:00.003+02:00

Ahora en la versión 0.9.0, FindRepe puede buscar dentro de zips y jars usando las opciones --zip y --zip-only. La opción --verbose ha sido implementada finalmente, en las versiones previas esta opción era meramente decorativa.

La opción --zip tiene un bug, causado por un bug en la última release estable de "Apache Commons Compress", que puede provocar un bucle infinito en algunos zips incorrectos. Este bug ya ha sido corregido pero aún estoy a la espera de que sea liberado.

-Download findrepe-0.9.0.zip

-Descomprimirlo usando el comando

unzip findrepe-0.9.0.zip

-Instalar el lanzador con uno de los siguientes comandos

java -jar findrepe-0.9.0/FindRepe.jar --install

java -jar findrepe-0.9.0/FindRepe.jar --install-home

sudo java -jar findrepe-0.9.0/FindRepe.jar --install-home=/opt/jdk1.6

-Trastealo y disfrutalo con

Usuarios de windows:

findrepe c:\ e:\

Usuarios de GNU/Linux, OpenSolaris y cualquier otro sabor unix:

findrepe /backup/mp3 /backup/src

(English version)

FindRepe 0.9.0 - EN

2010-07-22T19:52:00.003+02:00

Now in version 0.9.0, FindRepe can search within zips and jars using options --zip and --zip-only. Option --verbose finally has been implemented, in previous versions this option was a dummy option.

Option --zip has a bug, due a bug in the last "Apache Commons Compress" stable release, it can cause an infinite loop in some buggy zips. This bug has been fixed but hasn't been released yet.

-Download findrepe-0.9.0.zip

-Decompress it using the command

unzip findrepe-0.9.0.zip

-Install the launcher with one of the following commands

java -jar findrepe-0.9.0/FindRepe.jar --install

java -jar findrepe-0.9.0/FindRepe.jar --install-home

sudo java -jar findrepe-0.9.0/FindRepe.jar --install-home=/opt/jdk1.6

-Play and enjoy it with

Windows users:

findrepe c:\ e:\

GNU/Linux, OpenSolaris and any other unix flavor users:

findrepe /backup/mp3 /backup/src

(Versión en Español)

La escandalosa mentira del tabaco asesino

2010-07-21T18:18:00.004+02:00

Como es sabido por mis conocidos, detesto el tabaco de forma vehemente. No siempre ha sido así, en tiempos pasados fue algo simplemente molesto. La vehemencia fue en aumento con la información, y tras ver varias muertes causadas por el tabaco.

Por eso hoy toca información, ya sea para que lo dejes si eres fumador o para tener argumentos contra los que se empeñan en hacerte fumador pasivo. Y que mejor que estas dos entradas en genciencia

La escandalosa mentira del tabaco asesino (I)

La escandalosa mentira del tabaco asesino (y II)

Asnos Estupidos - 2.053

2010-07-17T09:00:00.000+02:00

Uno de los relatos de Isaac Asimov, titulado Asnos estupidos e incluidos en el libro "Compre Júpiter" relata como la Tierra es anotada en un pequeño libro para ser tachada a continuación. Para los que crean que no hay motivo suficiente, puede que la siguiente animación que reproduce a un mes por segundo las 2.053 explosiones nucleares sucedidas en el periodo 1945-1998, les abra los ojos ante la estupidez humana.

Visto en microsiervos

State of the Lambda by Brian Goetz

2010-07-16T00:19:00.002+02:00

Borrowed from State of the Lambda by Brian Goetz, 6 July 2010

This is an updated proposal to add lambda expressions (informally,
"closures") to the Java programming language. This sketch is built on
the straw-man proposal made by Mark Reinhold in December
2009.

Background; SAM classes
The Java programming language already has a form of closures:
anonymous inner classes. There are a number of reasons these are
considered imperfect closures, primarily:
- Bulky syntax
- Inability to capture non-final local variables
- Transparency issues surrounding the meaning of return, break,
  continue, and 'this'
- No nonlocal control flow operators
It is not a goal of Project Lambda to address all of these issues.

The standard way for Java APIs to define callbacks is to use an
interface representing the callback method, such as:
```
public interface CallbackHandler 
{ 
    public void callback(Context c);
}
```
The CallbackHandler interface has a useful property: it has a single
abstract method. Many common interfaces and abstract classes have
this property, such as Runnable, Callable, EventHandler, or
Comparator. We call these classes SAM classes.

The biggest pain point for anonymous inner classes is bulkiness. To
call a method taking a CallbackHandler, one typically creates an
anonymous inner class:
```
foo.doSomething(new CallbackHandler() 
{ 
  public void callback(Context c) 
  { 
    System.out.println("pippo");
  }
});
```
The anonymous inner class here is what some might call a "vertical
problem": five lines of source code to encapsulate a single statement.

Astute readers will notice that the syntax used for examples in this
document differ from that expressed in the straw-man proposal. This
does not reflect a final decision on syntax; we are still
experimenting with various candidate syntax options.

Lambda expressions
Lambda expressions are anonymous functions, aimed at addressing the
"vertical problem" by replacing the machinery of anonymous inner
classes with a simpler mechanism. One way to do that would be to add
function types to the language, but this has several disadvantages:
- Mixing of structural and nominal types;
- Divergence of library styles (some libraries would continue to use
callback objects, while others would use function types).

So, we have instead chosen to take the path of making it easier to
create instances of callback objects.

Here are some examples of lambda expressions:
```
{ -> 42 }

{ int x -> x + 1 }
```
The first expression takes no arguments, and returns the integer 42;
the second takes a single integer argument, named x, and returns x+1.

Lambda expressions are distinguished from ordinary statement blocks by
the presence of a (possibly empty) formal parameter list and the ->
token. The lambda expressions shown so far are a simplified form
containing a single expression; there is also a multi-statement form
that can contain one or more statements.

SAM conversion
One can describe a SAM type by its return type, parameter types, and
checked exception types. Similarly, one can describe the type of a
lambda expression by its return type, parameter types, and exception
types.

Informally, a lambda expression e is convertible-to a SAM type S if
an anonymous inner class that is a subtype of S and that declares a
method with the same name as S's abstract method and a signature and
return type corresponding to the lambda expressions signature and
return type would be considered assignment-compatible with S.

The return type and exception types of a lambda expression are
inferred by the compiler; the parameter types may be explicitly
specified or they may be inferred from the assignment context (see
Target Typing, below.)

When a lambda expression is converted to a SAM type, invoking the
single abstract method of the SAM instance causes the body of the
lambda expression to be invoked.

For example, SAM conversion will happen in the context of assignment:
```
CallbackHandler cb = { Context c -> System.out.println("pippo") };
```
In this case, the lambda expression has a single Context parameter,
has void return type, and throws no checked exceptions, and is
therefore compatible with the SAM type CallbackHandler.

Target Typing
Lambda expressions can only appear in context where it will be
converted to a variable of SAM type; the type of 'this' inside the
lambda expression is (a subtype of) the SAM type to which the lambda
expression is being converted. So the following code will print
"Yes":
```
Runnable r = { -> 
                 if (this instanceof Runnable) 
                     System.out.println("Yes");
             };
r.run();
```
The following use of lambda expressions is forbidden because it does
not appear in a SAM-convertible context:
```
Object o = { -> 42 };
```
In a method invocation context, the target type for a lambda
expression used as a method parameter is inferred by examining the set
of possible compatible method signatures for the method being invoked.
This entails some additional complexity in method selection;
ordinarily the types of all parameters are computed, and then the set
of compatible methods is computed, and a most specific method is
selected if possible. Inference of the target type for lambda-valued
actual parameters happens after the types of the other parameters is
computed but before method selection; method selection then happens
using the inferred target types for the lambda-valued parameters.

The type of the formal parameters to the lambda expression can also be
inferred from the target type of the lambda expression. So we can
abbreviate our callback handler as:
```
CallbackHandler cb = { c -> System.out.println("pippo") };
```
as the type of the parameter c can be inferred from the target type
of the lambda expression.

Allowing the formal parameter types to be inferred in this way
furthers a desirable design goal: "Don't turn a vertical problem into
a horizontal problem." We wish that the reader of the code have to
wade through as little code as possible before arriving at the "meat"
of the lambda expression.

The user can explicitly choose a target type by specifying a type
name. This might be for clarity, or might be because there are
multiple overloaded methods and the compiler cannot correctly chose
the target type. For example:
```
executor.submit(Callable<String> { -> "foo" });
```
If the target type is an abstract class, it is an open question as to
whether we want to permit an argument list so a constructor other than
the no-arg constructor can be used.

Lambda bodies
In addition to the simplified expression form of a lambda body, a
lambda body can also contain a list of statements, similar to a method
body, with several differences: the break, return, and continue
statements are not permitted, and a "yield" statement, whose form is
similar to to the return statement, is permitted instead of a return
statement. The type of a multi-statement lambda expression is
inferred by unifying the type of the values yielded by the set of
yield statements. As with method bodies, every control path through a
multi-statement lambda expression must either yield a value, yield no
value, or throw an exception. Expressions after a yield statement are
unreachable.

The complete syntax is given by:
```
lambda-exp := "{" arg-list "->" lambda-body "}"
arg-list := "(" args ")" | args
args := arg | arg "," args
arg := [ type ] identifier
lambda-body := expression | statement-list [ ";" ]
statement-list := statement | statement ";" statement-list
```

Instance capture
Once the target type of a lambda expression is determined, the body of
a lambda expression is treated largely the same way as an anonymous
inner class whose parent is the target type. The 'this' variable
refers to the SAM-converted lambda (whose type is a subtype of the
target type). Variables of the form OuterClassName.this refer to the
instances of lexically enclosing classes, just as with inner classes.
Unqualified names may refer to members of the SAM class (if it is a
class and not an interface), or to members of lexically enclosing
classes, using the same rules as for inner classes.

For members of lexically enclosing instanaces, member capture is
treated as if the references were desugared to use the appropriate
"Outer.this" qualifier and Outer.this is captured as if it were a
local final variable.

Local variable capture
The current rules for capturing local variables of enclosing contexts
in inner classes are quite restrictive; only final variables may be
captured. For lambda expressions (and for consistency, probably inner
class instances as well), we relax these rules to also allow for
capture of effectively final local variables. (Informally, a local
variable is effectively final if making it final would not cause a
compilation failure.)

It is likely that we will not permit capture of mutable local
variables. The reason is that idioms like this:
```
int sum = 0;
list.forEach({ Element e -> sum += e.size(); });
```
are fundamentally serial; it is quite difficult to write lambda bodies
like this that do not have race conditions. Unless we are willing to
enforce (preferably statically) that such lambdas not escape their
capturing thread, such a feature may likely cause more trouble than it
solves.

Exception transparency
A separate document on exception transparency proposes our strategy
for amending generics to allow abstraction over thrown checked
exception types.

Method references
SAM conversion allows us to take an anonymous method body and treat it
as if it were a SAM type. It is often desirable to do the same with
an existing method (such as when a class has multiple methods that are
signature-compatible with Comparable.compareTo().)

Method references are expressions which have the same treatment as
lambda expressions (i.e., they can only be SAM-converted), but instead
of providing a method body they refer to a method of an existing class
or object instance.

For example, consider a Person class that can be sorted by name or by
age:
```
class Person 
{ 
    private final String name;
    private final int age;

    public static int compareByAge(Person a, Person b) { ... }

    public static int compareByName(Person a, Person b) { ... }
}

Person[] people = ...
Arrays.sort(people, #Person.compareByAge);
```
Here, the expression #Person.compareByAge is sugar for a lambda
expression whose formal argument list is copied from the method
Person.compareByAge, and whose body calls Person.compareByAge. This
lambda expression will then get SAM-converted to a Comparator.

If the method being referenced is overloaded, it can be disambiguated
by providing a list of argument types:
```
Arrays.sort(people, #Person.compareByAge(Person, Person));
```
Instance methods can be referenced as well, by providing a receiver
variable:
```
Arrays.sort(people, #comparatorHolder.comparePersonByAge);
```
In this case, the implicit lambda expression would capture a final
copy of the "comparatorHolder" reference and the body would invoke
the comparePersonByAge using that as the receiver.

We may choose to restrict the forms that the receiver can take, rather
than allowing arbitrary object-valued expressions like
"#foo(bar).moo", when capturing instance method references.

Extension methods
A separate document on defender methods proposes our
strategy for extending existing interfaces with virtual extension
methods.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

2010-07-07T19:36:00.003+02:00

This entry of Joel on Software titled "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" is as it says, so if you are a programmer, read it, (No Excuses!).

http://www.joelonsoftware.com/articles/Unicode.html

Some phrases from the article:

It does not make sense to have a string without knowing what encoding it uses

How do we preserve this information about what encoding a string uses? Well, there are standard ways to do this. For an email message, you are expected to have a string in the header of the form

Content-Type: text/plain; charset="UTF-8"

For a web page, the original idea was that the web server would return a similar Content-Type http header along with the web page itself -- not in the HTML itself, but as one of the response headers that are sent before the HTML page.

Java 4 Ever - Java por Siempre

2010-06-28T20:22:00.003+02:00

Los Riesgos de las Universidades-Java

2010-06-07T21:01:00.004+02:00

Me he permitido copiar esta traducción de este artículo de Joel Spolsky.

Antes de que empieces déjame presumir, después de que con 14 años mi cerebro quedase dañado por un curso de verano de MSX BASIC, conseguí recuperarme a causa de no tener ordenador con el que practicar. Hasta que a los 18 años me compré mi primer ordenador (un 486 2MB de RAM y 120MB de disco duro lo mejorcito de la epoca) con mis ahorros obtenidos como camarero. Lo usé para practicar C que aprendí practicando en papel con un libro "C Manual de referencia de Herbert Schildt". La única dificultad de C es la compresión de los punteros, conseguido esto, lo demás es trivial. Como dice el artículo, el desconocimiento de los punteros es generalizado en las nuevas generaciones de programadores. Aunque los filtros siguen ahí, pero ahora las "purgas" las hacen las "crisis" y los "ascensos".

Los Riesgos de las Universidades-Java

por Joel Spolsky Jueves 29 de diciembre de 2005

Chicos perezosos.

¿Qué pasó con el trabajo duro?

Un seguro indicio de mi decadencia hacia la senilidad son mis continuas quejas y lamentos sobre “los chicos de hoy”, y cómo ya no quieren o no pueden hacer cosas difíciles.

Cuando yo era un muchacho, aprendí a programar con tarjetas perforadas. En esos tiempos si cometías un error, no tenías ninguna de esas modernas funciones como la tecla “backspace” para corregirlo. Tenias que tirar la tarjeta y empezar todo de nuevo.

Cuando empecé a entrevistar programadores en 1991, les dejaba usar generalmente cualquier lenguaje que quisieran para resolver los problemas de programación que les planteaba. El 99% de las veces, ellos elegían C.

Ahora ellos tienden a elegir Java.

No me malinterpreten: no hay nada malo con Java como lenguaje de implementación.

Un momento, quiero rectificar eso último. No digo, en este artículo en particular, que haya algo de malo con Java como lenguaje de implementación. Hay un montón de cosas mal con Java, pero tendrán que esperar hasta otro artículo.

En cambio, lo que quiero decir es que Java no es, generalmente, un lenguaje de programación lo suficientemente difícil para que pueda ser usado para distinguir entre excelentes programadores y programadores mediocres. Puede ser un buen lenguaje para trabajar, pero ese no es el tema de hoy. Puedo ir incluso mas allá y decir que el hecho de que Java no sea lo suficientemente difícil es una característica, no un bug, pero que tiene ese problema.

Si puedo ser atrevido, diría que en mi humilde experiencia han sido dos las cosas tradicionalmente enseñadas en las universidades como parte de la carrera de Ciencias de la Computación (CS) las que mucha gente nunca llega realmente a comprender: punteros y recursión.

En aquellos tiempos lo normal era empezar la universidad con un curso de estructuras de datos, con listas enlazadas, tablas hash y, por qué no, con un uso intensivo de punteros. Esos cursos eran frecuentemente usados como filtros: eran tan difíciles que cualquiera que no pudiera soportar el desafío mental de un grado en CS se daría por vencido, lo que era bueno, porque si piensas que los punteros son difíciles, espera hasta intentar probar cosas en teoría de punto fijo.

Todos esos chicos que lo habían hecho muy bien en la secundaria escribiendo juegos de “pong” en BASIC para su Apple II, iban a la universidad, tomaban el curso CompSci 101, sobre estructuras de datos, y cuando llegaban al asunto de los punteros, sus cerebros estallaban completamente; y lo próximo de lo que tenías noticias es que estaban especializándose en Ciencias Políticas, porque la escuela de leyes parecía ser una mejor idea. He visto todo tipo de de índices de deserción en CS y usualmente están entre el 40% y el 70%. Las universidades tienden a ver esto como un derroche; yo creo que es sólo la poda necesaria de gente que no va a ser feliz o exitosa en una carrera de programación.

El otro curso difícil para muchos jóvenes estudiantes de CS era el curso donde aprendías programación funcional, incluyendo programación recursiva. MIT puso una barrera muy alta en esos cursos, creando un curso obligatorio (6.001) y un libro de texto (Estructura e Interpretación de Programas de Computadora de Abelson y Sussman, el cual era usado en docenas o quizás cientos de carreras de CS prestigiosas como el estándar de facto para la introducción a las Ciencias de la Computación. (Puedes, y deberías echarle una ojeada a la antigua versión de las clases en línea).

La dificultad de esos cursos es asombrosa. En la primera clase has aprendido casi todo Scheme, y ya has sido introducido a la función de punto fijo que toma otra función como parámetro. Cuando me esforzaba en pasar un curso similar, CSE121 en Penn, observaba cómo muchos sino la mayoría de los estudiantes simplemente no lo lograba. La materia era muy difícil. Inclusive escribí un largo email de lloriqueando a mi profesor diciendo que “simplemente no era justo”. Alguien en Penn debe haberme escuchado (o a alguno de los otros llorones), porque ese curso se dicta ahora con Java.

Desearía que no hubiesen escuchado.

Aquí radica el quid del debate. Años de lloriqueo de estudiantes perezosos como yo, combinados con quejas de la industria acerca de cuan pocos graduados en CS salen de las universidades americanas, han pagado su precio, y en la ultima década un gran numero de otrora perfectamente buenas universidades se han vuelto 100% Java. Esta de moda, a los reclutadores que usan “grep” parece gustarles, y, lo mejor de todo, no hay nada lo suficientemente difícil en Java como para filtrar aquellos programadores sin la parte del cerebro que entiende punteros y recursión. Así es que la deserción es menor, y los departamentos de ciencias de la computación tienen mas alumnos y mayores presupuestos y todo está bien.

Los afortunados chicos de esas Universidades-Java nunca van a toparse con raros fallos de segmentación tratando de implementar tablas hash basadas en punteros. Nunca se van a volver locos tratando de empaquetar cosas en bits. Nunca tendrán que ocupar sus cabezas en cómo en un lenguaje puramente funcional, el valor de una variable nunca cambia, y aun así, ¡cambia todo el tiempo! ¡Una paradoja!

Ellos no necesitan esa parte del cerebro para obtener un 4 en la materia.

¿Soy sólo uno de esos viejos cascarrabias anticuados, vanagloriándose acerca de cuán duro era sobrevivir a todas esas dificultades?

Rayos, en 1900, el Latín y el Griego eran asignaturas requeridas en la universidad, no porque sirvieran de algún propósito, sino porque de alguna manera eran considerados un requisito obvio de la gente educada. De cierta manera mi argumento no es diferente del argumento expuesto por la gente pro-Latín: “[El Latín] entrena tu mente. Entrena tu memoria. Desembrollar una sentencia en Latín es un excelente ejercicio del pensamiento, un verdadero acertijo intelectual y una buena introducción al pensamiento lógico”, escribe Scout Barrer. Pero ya no puedo encontrar una sola universidad que requiera Latín. ¿Son los punteros y la recursión el Latín y el Griego de las ciencias de la computación?

Ahora, admito que programar con punteros no es necesario en el 90% del código escrito en la actualidad, y de hecho es totalmente peligroso en el código de producción. OK. Está bien. Y que la programación funcional no es muy empleada en la práctica. De acuerdo.

Pero todavía sigue siendo importante para algunos de las tareas más excitantes en programación. Sin punteros, por ejemplo, nunca serías capaz de trabajar en el Kernel de Linux. No puedes entender una sola línea del código de Linux, o de hecho, de cualquier sistema operativo, sin realmente entender punteros.

Sin entender programación funcional, no podrás inventar MapReduce, el algoritmo que hace Google tan masivamente escalable. Los términos Map y Reduce vienen de Lisp y la programación funcional. MapReduce es, en retrospectiva, obvio para cualquiera que recuerde de su clase equivalente a 6.001 que los programas puramente funcionales no tienen efectos colaterales y por ende son trivialmente paralelizables. El simple hecho que Google inventara MapReduce, y no Microsoft, dice algo del por qué Microsoft está aun jugando a lograr que funcionen algunas características básicas de búsqueda, mientras Google se ha movido ya al siguiente problema: construir Skynet^H^H^H^H^H^H, la mayor supercomputadora masivamente paralela del mundo. Simplemente no creo que Microsoft entienda completamente cuan retrasados están en ese campo.

Pero mas allá de la importancia a simple vista de los punteros y la recursión, su valor real radica en que construir grandes sistemas requiere del tipo de flexibilidad mental que adquieres aprendiéndolos, y de la actitud mental que necesitas para no huir de los cursos en donde son enseñados. Punteros y recursión requieren cierta habilidad para razonar, para pensar en abstracciones, y más importante, para ver un problema en diversos niveles de abstracción simultáneamente. Por lo tanto, la habilidad para entender punteros y recursión esta directamente correlacionada con la habilidad de ser un gran programador.

No hay nada en grado académico 100% Java que realmente descarte a los estudiantes que carecen de la agilidad mental para tratar con esos conceptos. Como empleador, he visto que las Universidades 100% Java han empezado a producir en serie una buena cantidad de graduados quienes simplemente no son lo suficientemente listos para trabajar como programadores en nada mas sofisticado que “Sólo Otra Aplicación Contable en Java”, aunque se las han arreglado para colarse a través de la (ahora simplificada) carrera. Esos estudiantes nunca sobrevivirían al 6.001 del MIT o al CS 323 en Yale y, francamente, esa es una razón por la cual, como empleador, un título en CS del MIT o Yale tiene más peso que uno de Duke, que recientemente se hizo 100%-Java, o de Penn, donde remplazaron Scheme y ML por Java tratando de enseñar la materia que casi nos mata a mis compañeros y a mi, CSE121. No es que no quiera contratar chicos listos de Duke o Penn, lo hago, es sólo que es mucho más difícil para mí darme cuenta de cuáles son. Yo estaba acostumbrado a decir que los chicos listos eran aquellos que podían desmenuzar un algoritmo recursivo en segundos, o implementar funciones de manipulación de listas enlazadas usando punteros tan rápido como podían escribir en la pizarra. Pero con graduado sde Universidades-Java, no puedo saber si padecen esos problemas a causa de haber sido mal educados o si los padecen porque realmente carecen de esa parte del cerebro que van a necesitar para ser buenos programadores en el trabajo. Paul Graham los llama “Blub Programmers“.

Ya es bastante malo que las Universidades-Java fallen en filtrar los chicos que nunca van a ser buenos programadores, algo que las universidades podrían justificablemente decir que no es su problema. Después de todo es la industria, o al menos los reclutadores-que-usan-grep, quien está pidiendo a gritos que se enseñe Java.

Pero las Universidades-Java fallan también en entrenar las mente de los chicos para ser hábiles, ágiles y lo suficientemente flexibles para lograr buen diseño de software (y no me refiero al “diseño” OO, donde gastas incontables horas acomodando tu jerarquía de objetos, o preocupándote de “problemas” superfluos como “tiene-un” vs. “es-un”). Necesitas entrenamiento para pensar en las cosas a varios niveles de abstracción simultáneamente, y ese tipo de pensamiento es exactamente lo que necesitas para diseñar excelentes arquitecturas de software.

Puedes estar preguntándote si la enseñanza de programación orientada a objetos (OOP) es un buen sustituto de los punteros y la recursión para el filtrado. La respuesta rápida: no. Sin debatir acerca de los meritos de la OOP, simplemente no es lo suficientemente difícil para filtrar a los programadores mediocres. OOP en las universidades consiste básicamente en memorizar un puñado de términos de vocabulario como “encapsulacion” y “herencia” y tomar exámenes del tipo “multiple-choice” acerca de las diferencias entre polimorfismo y sobrecarga. No más difícil que memorizar fechas destacadas y nombres en una clase de historia, la OOP tiene desafíos mentales inadecuados para espantar a los estudiantes de primer año. Cuando te enfrentas con un problema de OOP, tu programa aun funciona, sólo que es algo difícil de mantener. Supuestamente. Pero cuando te enfrentas a un problema con punteros, tu programa produce línea Fallo de segmentación y no tienes ni la menor idea de lo que está pasando, hasta que te paras, tomas una fuerte bocanada de aire y tratas de forzar tu mente a trabajar en dos diferentes niveles de abstracción simultáneamente.

Los reclutadores-que-usan-grep, de hecho, son ridiculizados aquí, y por un buen motivo. Nunca he conocido alguien que pueda usar Scheme, Haskell y punteros en C, que no pueda entender Java en dos días, y crear mejor código en Java que gente con cinco años de experiencia en Java. Pero trata de explicar eso al zombie de Recursos Humanos.

¿Pero que hay de la misión del compromiso con las CS de las facultades de CS? ¡Ellas no son escuelas vocacionales! No debería ser su trabajo entrenar gente para trabajar en la industria. Eso queda para los terciarios y los programas de capacitación del gobierno para trabajadores desplazados, dirán. Ellas se suponen que están para dar a los estudiantes las herramientas fundamentales para vivir sus vidas, no para prepararlos para sus primeras semanas de trabajo. ¿No es cierto?

Aun así, las CS son demostraciones (recursión), algoritmos (recursión), lenguajes (cálculo lambda), sistemas operativos (punteros), compiladores (cálculo lambda), y entonces la conclusión es que la Universidad-Java que no enseña C y no enseña Scheme, tampoco está enseñando realmente ciencias de la computación. Tan inútil como el concepto de currificación de funciones puede serle al mundo real, es un obvio prerrequisito para un graduado en CS. No puedo entender por qué los profesores en las comisiones curriculares de las facultades de CS han permitido que sus programas sean embrutecidos a tal punto que no sólo no pueden producir programadores operativos, sino que ya ni siquiera pueden producir graduados en CS que puedan obtener PhDs y puedan competir por sus puestos de trabajo. Oh, esperen. No importa. Quizás entienda.

Si volvemos en el tiempo y analizamos las discusiones que tomaron lugar en el mundo académico durante el “Gran Levantamiento Java”, encontraremos que la mayor preocupación fue que Java no era lo suficientemente simple para ser usado como un lenguaje de enseñanza.

Mi Dios, pensé, ¡están tratando de embrutecer la curricula aun mas! ¿Por que mejor no le llevamos la comida a la boca a los estudiantes? Dejemos que los ayudantes de cátedra den los exámenes por ellos también, entonces nadie se cambiara a Estudios Americanos. ¿Cómo se supone que alguien aprenderá algo si la curricula ha sido cuidadosamente diseñada para hacer todo más fácil de lo que ya es? Parece haber una comisión de trabajo (PDF) intentando idear un subconjunto simple de Java que pueda ser enseñado a estudiantes, produciendo documentación simplificada que esconde cuidadosamente toda esa basura EJB/J2EE de sus tiernas mentes, de manera tal que no tengan que preocupar sus cabecitas con otras clases que no necesiten para resolver sus aun más fáciles problemas de CS.

La interpretación mas compasiva de por qué las facultades CS son tan entusiastas en embrutecer sus clases es porque ello les dará más tiempo para enseñar verdaderos conceptos de CS, así no necesitaran dos clases enteras para esclarecer a los alumnos las diferencias entre, digamos, un int y un Integer en Java. Bueno pero si ese fuera el caso, 6.001 tiene la respuesta perfecta: Scheme, un lenguaje de enseñanza tan simple que el lenguaje entero puede enseñarse a estudiantes brillantes en unos 10 minutos; entonces puedes gastar el resto del semestre enseñando puntos fijos.

Fiu…

Voy a regresar a los unos y ceros.

(¿Te tocaron unos? ¡Bastardo suertudo! A nosotros nos tocaron todos ceros.)

Esta traducción está basada en la versión disponible en el Wiki de Joel Spolsky, corregida y adaptada por Javier Smaldone.

Towards a Universal VM by Alex Buckley

2010-06-06T09:30:00.000+02:00

This is a very good presentation by Alex Buckley about the JVM.

http://www.infoq.com/presentations/Towards-a-Universal-VM

Carl Sagan vs Iker Jimenez - El dragón en el garaje

2010-06-04T21:35:00.005+02:00

Cuarto milenio tiene algunas cosas interesantes, pero el "ansia viva" por rellenar e infundir de un halo de importancia a verdaderas ~~vanalidades~~ banalidades, hace que yo particularmente lo considere un programa "chorra", porque admitámoslo, ofrecen como ciertas y veraces, autenticas "chorradas".

Todo esto viene a colación de este vídeo (encontrado aquí) sobre la historia del dragón en el garaje que obtuve aquí y que puedes leer debajo del vídeo.

"En mi garaje vive un dragón que escupe fuego por la boca."

Supongamos (sigo el método de terapia de grupo del psicólogo Richard Franklin) que yo le hago a usted una aseveración como ésa. A lo mejor le gustaría comprobarlo, verlo usted mismo. A lo largo de los siglos ha habido innumerables historias de dragones, pero ninguna prueba real. ¡Qué oportunidad!

- Enséñemelo – me dice usted.

Yo le llevo a mi garaje. Usted mira y ve una escalera, latas de pintura vacías y un triciclo viejo, pero el dragón no está.

- ¿Dónde está el dragón? – me pregunta.

- Oh, está aquí – contesto yo moviendo la mano vagamente -. Me olvidé decir que es un dragón invisible.

Me propone que cubra de harina el suelo del garaje para que queden marcadas las huellas del dragón.

- Buena idea – replico – , pero este dragón flota en el aire.

Entonces propone usar un sensor infrarrojo para detectar el fuego invisible.

- Buena idea, pero el fuego invisible tampoco da calor.

Se puede pintar con spray el dragón para hacerlo visible.

- Buena idea, sólo que es un dragón incorpóreo y la pintura no se le pegaría.

Y así sucesivamente. Yo contrarrestro cualquier prueba física que usted me propone con una explicación especial de por qué no funcionará.

Ahora bien, ¿cuál es la diferencia entre un dragón invisible, incorpóreo y flotante que escupe un fuego que no quema y un dragón inexistente? Si no hay manera de refutar mi opinión, si no hay ningún experimento válido contra ella, ¿qué significa decir que mi dragón existe? Su incapacidad de invalidar mi hipótesis no equivale en absoluta a demostrar que es cierta. Las afirmaciones que no pueden probarse, las aseveraciones inmunes a la refutación son verdaderamente inútiles, por mucho valor que puedan tener para inspirarnos o excitar nuestro sentido de maravilla. Lo que yo he pedido que haga es acabar aceptando, en ausencia de pruebas, lo que yo digo.

Lo único que ha aprendido usted de mi insistencia en que hay un dragón en mi garaje es que estoy mal de la cabeza. Se preguntará, si no se puede aplicar ninguna prueba física, qué fue lo que me convenció. La posibilidad de que fuera un sueño o alucinación entraría ciertamente en su pensamiento. Pero entonces ¿por qué hablo tan en serio? A lo mejor necesito ayuda. Como mínimo, puede ser que haya infravalorado la falibilidad humana.

Imaginemos que, a pesar de que ninguna de las pruebas ha tenido éxito, usted desea mostrarse escrupulosamente abierto. En consecuencia, no rechaza de inmediato la idea de que haya un dragón que escupe fuego por la boca en mi garaje. Simplemente, la deja en suspenso. La prueba actual está francamente en contra pero, si surge algún nuevo dato, está dispuesto a examinarlo a ver si le convence. Seguramente es poco razonable por mi parte ofenderme porque no me cree; o criticarle por ser un pesado poco imaginativo... simplemente porque usted pronunció el veredicto escocés de "no demostrado".

Imaginemos que las cosas hubiesen sido de otro modo. El dragón es invisible, de acuerdo, pero aparecen huellas en la harina cuando usted mira. Su detector de infrarrojos registra algo. La pintura de spray revela una cresta dentada en el aire delante de usted. Por muy escéptico que se pueda ser en cuanto a la existencia de dragones – por no hablar de seres invisibles – ahora debe reconocer que aquí hay algo y que, en principio, es coherente con la idea de un dragón invisible que escupe fuego por la boca.

Ahora otro guión: imaginemos que no se trata sólo de mí. Imaginemos que varias personas que usted conoce, incluyendo algunos que está seguro que no se conocen entre ellas, le dicen que tienen dragones en sus garajes... pero en todos los casos la prueba es enloquecedoramente elusiva. Todos admitimos que nos perturba ser presas de una convicción tan extraña y tan poco sustentada por una prueba física. Ninguno de nosotros es un lunático. Especulamos con lo que significaría que hubiera realmente dragones escondidos en los garajes de todo el mundo y que los humanos acabáramos de enterarnos. Yo preferiría que no fuera verdad, francamente. Pero quizás todos aquellos mitos europeos y chinos antiguos sobre dragones no eran solamente mitos...

Es gratificante que ahora se informe de algunas huellas de las medidas del dragón en la harina. Pero nunca aparecen cuando hay un escéptico presente. Se plantea una explicación alternativa: tras un examen atento, parece claro que las huellas podían ser falsificadas. Otro entusiasta del dragón presenta una quemadura en el dedo y la atribuye a una extraña manifestación física del aliento de fuego del dragón. Pero también aquí hay otras posibilidades. Es evidente que hay otras maneras de quemarse los dedos además de recibir el aliento de dragones invisibles. Estas "pruebas", por muy importante que las consideren los defensores del dragón, son muy poco convincentes. Una vez más, el único enfoque sensato es rechazar provisionalmente la hipótesis del dragón y permanecer abierto a otros datos físicos futuros, y preguntarse cuál puede ser la causa de que tantas personas aparentemente sanas y sobrias compartan la misma extraña ilusión.

10+1 things they never teach in college about programming.

2010-05-30T21:57:00.002+02:00

these are the 10+1 things from this entry (where you can find extended) about what they never teach in college about programming.

1.- We’re always wrong.

2.- If something can break, it will break.

3.- All code is crap.

4.- There is always a bug.

5.- The most important thing is the client.

6.- Design on paper doesn’t work.

7.- Less is more.

8.- Coding is only 20% of what we do.

9.- The customer doesn’t know what he/she wants NEVER!.

10.- Someone has done it before.

Bonus: Hey! Our job is cool!

and of course if your job is about programming, yeahhhhh, it's cool, very cool!!!

George Carlin - El Sueño Americano - Subtitulado

2010-04-25T20:27:00.001+02:00

Aunque sea humor, tiene tooooooda la razón

visto en maldiaparadejardefumar

Pinnacle PCTV 310i with ubuntu 9.10

2010-04-19T22:04:00.003+02:00

I've been upgrading my ubuntu from 8.04 to 8.10, 9.04 and now to 9.10. The last step (9.04 to 9.10) hasn't been as clean as spected, Pinnacle PCTV 310i doesn't work after upgraded to 9.10, there is an aditional step needed to watch dvd-t TV, you have to install "linux-firmware-nonfree", it's said you have to reboot the computer, in my case it started working intermediately.

So this is the command for ubuntu command-line:

sudo apt-get install linux-firmware-nonfree

1984 o casi

2010-04-15T20:49:00.001+02:00

Eludiendo la cadena de una puerta

2010-04-06T22:09:00.001+02:00

Furia de Titanes 3D - un timo como una casa

2010-04-02T23:33:00.005+02:00

Hoy he visto "Furia de Titanes" en 3D, y la experiencia ha valido la pena, ya puedo decir que NO MERECE LA PENA ir a ver una película en 3D, al menos si es como ésta (que según parece no es 3D sino 2D tratado). Aunque las imágenes sí se veían distintas casi nunca para mejor, las escenas oscuras no se veían nada bien, las escenas de acción o con movimientos ligeramente rápidos eran muy complicadas de seguir, sólo las excenas de paisajes con suficiente luz, y a gran distancia tenían algo que aportar, el resto no. En general la sensación es de reducción del angulo de visión, he terminado con molestias en los ojos (nada grave o permanente).

En lo que se refiere a lo que sería la película en 2D, no es mala, aunque tampoco es un peliculón.

SvnHg, migrating from subversion (svn) to mercurial (Hg)

2010-04-01T22:12:00.008+02:00

Few weeks ago I've started reading about mercurial (Hg) and what's the diference with subversion (the one I'm currently using at work and for my personal software). Now I want to migrate my personal software hosted in google code but none of the tools I've tried have worked, or was easy enough for me. So I've done mine :-)

SvnHg is very simple, it just use svn and hg commands to do the job.

You can download here, unzip and install it (or use the java -jar ...).

to install

sudo java -jar SvnHg.jar --install

to migrate just type

svnhg -v dirname

you can use options or just let the program ask you what he need to work.

enjoy it!!!

me-tv mutes all programs (solved)

2010-03-31T22:15:00.003+02:00

After upgrading my ubuntu from version 8.04 to 9.04 (through 8.10), me-tv mute button (or key M) mutes all programs, mplayer, chrome, firefox, ..., to fix the problem just change in ~/.me-tv/xine.config the following line

gui.audio_mixer_method:Sound card

to this one

gui.audio_mixer_method:Software

if this line is preceded by a # delete it, or the entire line will be ignored.

now restart me-tv and enjoy it.

Mercurial: The Definitive Guide by Bryan O'Sullivan

2010-03-20T00:58:00.002+01:00

This is a book about mercurial (Hg), the revision control manager.

Mercurial: The Definitive Guide by Bryan O'Sullivan

Hg Init: a Mercurial tutorial

2010-03-19T00:50:00.001+01:00

http://hginit.com is a good tutorial to start with mercurial (Hg) by Joel Spolsky

Cambio de Look

2010-03-14T10:51:00.002+01:00

He cambiado el Look and Feel de mi blog, no por que me guste más, no porque cargue más rápido, sólo para que quepa mejor el widget de una palabra en inglés al día. Y ya de paso, para que todo quepa mejor, estaba harto de estrecheces.

A todo el mundo le encanta la música clásica! solo que todavía no lo han descubierto.

2010-02-20T10:15:00.000+01:00

Magnífica explicación del Preludio Op.28, No.4 de Chopin

excellent explanation of the Prelude Op.28, No.4 Chopin

visto en enchufa2

Quo Vadis JDK7?

2010-02-17T23:49:00.002+01:00

This is an Oracle "The TechCast Show" with Mark Reinhold talking about JDK7.

You can also read this resume

David Bravo - Entrevista en Buenafuente

2010-02-13T09:04:00.001+01:00

I.M.P.S. The Relentless – Chapter 2: Norca System

2010-02-06T09:00:00.000+01:00