style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

blog de OscarRyz

Día de Ryz, 2013

El año que acaba de concluir fue bastante lento para Ryz, la razón es que me pasaron muchas cosas.

- Cambié de trabajo para entrar a Knowtion y esto me absorbió la mayor parte de mi tiempo libre.
- La otra gran parte de mi tiempo libre me la pesé haciendo otras cosas que me hacían mucho, mucho, pero muucho muy feliz.

Estuvo bien, no hay queja. El objetivo de Ryz no es competir contra los otros lenguajes, ni siquiera contra Java mismo, no hay prisa.

En el 2012 lenguajes existentes y nuevos han ido consolidando algo que pretende hacer Ryz, simplificar el uso de Java. Java 8 incluirá closures finalmente, IDE's como Intellj IDEA 12 ya tienen soporte para ello. La comunidad (al menos en la que me encuentro) tiene ya bastante familiaridad con el uso de bloques y la programación funcional está empezando a consolidarse como paradigma al lado de la POO. Hay al menos un lenguaje con tipado estructurado que está siendo usado con éxito en producción actualmente. Todos hablan ya de Smalltalk y así por el estilo. Mucho e esto estaba en la base de Ryz, mucho solo en mi cabeza.

Loop recognition in C++/Java/Go/Scala

Encontré esta comparación de lenguajes que me parece interesante compartir.

http://research.google.com/pubs/pub37122.html

No estoy muy acostumbrado a leer este tipo de documentos, pero encuentro bastante entretenido aunque sea solo ojearlo y ver los dibujitos.

Una cosa que encuentro es que en Scala se puede escribir con mucho menos código, pero que esa brevedad se transmite muchas veces al tiempo de ejecución, es decir debes de verdad saber que estás escribiendo y que impacto tiene ahorrarse algunas lineas de código, claro ejemplo los for-comprehensions que Ezamudio ya explicó por acá anteriormente.

Voy a seguir viendo las figuritas, se ve bastante interesante.

Les dejo la conclusión (ya todos saben que no hay que hacer caso a estas conclusiones verdad? bien)


Hemos implementado un algoritmo compacto bien especificado
en cuatro lenguajes, C++, Java, Go y Scala, y evaluado los resultados
en varias dimensiones, encontrando factores de diferencia en todas las
areas. Hemos discutido varias optimizaciones subsecuentes especificas
a cada lenguaje que nos indican puntos débiles comunes en el desempeño
de cada lenguaje
.

El garbage collector y los memory leaks

Antecedente

Una de los aportes más relevantes de Java es la inclusión del recolector de basura ( garbage collector) tanto que hoy en día es un estándar y ni se menciona como una característica del lenguaje. Java no lo inventó, pero si aportó mucho para su adopción.

El GC corre automáticamente en la JVM cada cierto tiempo. No hay forma de proveer cuando lo hará (o si lo hará) ni de forzar a que corra (o que no lo haga). Existen varias estrategias de implementación y es todo un tema que sigue en desarrollo e investigación. Lo mejor de todo es que como usuarios de la plataforma tenemos muy poco que hacer para utilizarlo.

Referencias

La regla para que un objeto pueda ser recolectado es sencilla, no debe de haber referencias al objeto.

....
Empleado a = new Empleado("God"); // a es la 1ra referencia
Empleado b = a; // b es la segunda referencia al mismo objeto "God"
...

En el ejemplo anterior se creó un objeto de tipo Empleado y hay dos referencias a él (a y b). Este objeto no será recolectado por el gc y su memoria seguirá en uso.

Cuando ya no hay referencias al objeto:
 

Convenciones de escritura en Java

Siguiendo un comentario de Jose Manuel escribo acá un poco sobre las convenciones para escribir código Java, en particular sobre las llaves que van en la misma línea.

Más que obsesión es para tener consistencia en el uso del lenguaje.

El compilador no lo manda como advertencia ni nada. Es más bien para los que leen el código.

Más importante aún es tener consistencia con el equipo de trabajo. Si todo el equipo elije poner las llaves en la columna 80 esa es la convención en ese proyecto

import java.net.*                                         ;
import java.io.*                                          ;
import java.util.*                                        ;
public class Server                                       {
    public static void main( String[] args)               {
        try                                               {
            ServerSocket sock = new ServerSocket(4712,100);
            while(true) new Handler(sock.accept()).start();}
        catch(IOException e) {System.err.println(e);}     ;}}

Refactoring para entender mejor

TD;DR; Ver el antes y después hasta abajo

Ya tenía tiempo sin postear así que ahí va un ejemplo de refactoring y como se puede usar para entender mejor código legado.

No importa mucho lo que el código hace ( guarda recetas de cocina ), el objetivo es mostrar como un método que hace una sola cosa a la vez es más fácil de entender, que uno que hace varias a la vez.

Para leer mejor este post hay que buscar solamente el código que esta comentado ( que se esta eliminando o moviendo ) y el comentario que dice //<-- aqui que es el que lo reemplaza.

Espero les sea de ayuda

Inicio ( no lo lean, nomas véanlo )

        public int guardaRecetas() {

            if ( validaDatosRequeridos() ) {
                DataSet recetasDs = new DataSet();
                DataTable recetasDt = new DataTable();
                int usuarioLogeado;
                int tipoId;
                recetasDs.getColumns().add("id_usuario", Integer.TYPE );
                recetasDs.getColumns().add("desc_bloqueo", String.class );
                SomeUtility.changeMaping(recetasDs.getColumns(), SomeUtility.SOME_FLAG);

El balance entre el uso de métodos como operadores.

Estaba escribiendo una respuesta al post de ezamudio Operadores en Ceylon pero como siempre me extendí más de la cuenta y mejor cree esta entrada separada.

El tema es la sobre carga de operadores en Ceylon.

Es interesante tratar de alcanzar el balance entre el uso de operadores y métodos en un lenguaje de programación.

Por un lado, si se permite que cualquier método se pueda utilizar como operador, se puede terminar creando código que solamente el autor del programa o la biblioteca entienda y eso cuando aún lo tiene fresco en la mente. Me parece que este es una de las críticas más fuertes hacía C++ y a Scala ( aunque Scala además permite una sintaxis diferente para la invocación de métodos que es sin usar punto )

Por otro lado si se prohibe del todo se tiene un lenguaje que es sumamente claro y fácil de entender por cualquiera pero que resulta tedioso porque el programador tiene que escribir toooodo el nombre del método y no simplemente un operador ( Java , Javascript y Go por ejemplo )

What have you tried?

Les dejo un link a un post muy interesante sobre como hacer preguntas.

http://mattgemmell.com/2008/12/08/what-have-you-tried/

Espero traducirlo en algún momento.

Saludos

Feliz día de Ryz!!!

El año pasado anuncié que estaba trabajando en un lenguaje de programación llamado Ryz ( /reies/ ) y poco tiempo más tarde hice una pequeña presentación del mismo en el #HackerRoom para un "selectísimo" grupo de personas. Este post es una revisión del estado del lenguaje y siguientes pasos.

Historia

  • octubre 2010 El primer Hola Mundo de Ryz.
  • enero 2011 Anunció en Java México y creación del repositorio en http://code.google.com/p/ryz/
  • mayo del 2011 Presentación del lenguaje y una aplicación muy sencilla para sacar screenshots.
  • mayo del 2011 Se creó el repositorio en https://github.com/OscarRyz/Ryz/
  • octubre 2011 Se planeaba terminar la funcionalidad básica que le permitiera entrar en fase alpha, pero por motivos de trabajo ( en agosto del 2011 inicié un proyecto que me consumió hasta los fines de semana ) y ya no pude avanzar como quería

Encapsulamiento

Toca el turno al concepto de la programación orientada a objetos llamado "encapsulamiento".

Como su nombre lo indica.....

Bueno mejor un ejemplo:

class Persona {
    String nombre;
    int edad;
    int edad() {
        return this.edad;
    }
}

Este código define una clase llamada Persona con dos atributos nombre y edad.

Aunque parece trivial y obvio este es uno ( otro ) de los aspectos más importantes de la programación orientada a objetos; definir los datos y los métodos para acceder/modificar los datos en el mismo lugar.

A este simple concepto se le llama "encapsulamiento" pues los datos están dentro de la capsula que forma la definición de la clase.

Y.... yap!.. eso es todo en serio. Es un concepto muy fácil de entender.

Ahora, para máximizar la eficacia de este concepto algunos lenguajes de programación como Java permiten tener diferentes "modificadores de acceso" para restringir o permitir más o menos visibilidad de los atributos ( modificar la forma en la que esos datos pueden ser accedidos ).

Se decidió ya sobre la sintaxis de los closures en Java 8!!

Bueeeeno pues ya que salió Java 7 podemos empezar a decir: "Y Java 8 para cuando?" :P

Pues bueno al menos al parecer que se decidió sobre la sintaxis final que tendrán los lambdas ( closures ) en Java 8

La sintaxis es:

    x => x + 1
   ( x ) => x + 1
   (int x) => x + 1
   (int x, int y) => x + y
   (x, y) => x + y
   (x, y) => { System.out.printf("%d + %d = %d%n", x, y, x+y); }
   () => { System.out.println("I am a Runnable"); }

Al parecer también hay una buena carga de inferencia de tipo como se puede ver en algunos ejemplos.

La explicación por esta sintaxis es que ya funciona en lenguajes existentes ( específicamente C# y Scala ) y con esto se evita tener que inventar algo nuevo.

Esta discusión tiene ya varios años y también desde hace varios años se decidió meter esta funcionalidad a Java y aunque venía para Java 7 se decidió aplazarlo para Java 8.

Distribuir contenido

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">