Java – Indalcasa

Lenguajes de programación semánticos (python) contra matemáticos (c#)

Hace tiempo escribí un artículo en el que hablaba de frameworks web para programar y fui criticado por criticar django. Bueno como aclaratoria, escribo este artículo, en el que detallo las diferencias de los programadores, una gran batalla entre lenguajes semánticos vs matematicos; en este caso python vs c#.

Veamos primero que es cada uno, un lenguaje semántico es un lenguaje de programación que pretende ser similar a un lenguaje real, como el español, inglés, etc. mientras que un lenguaje matemático es mas parecido a ecuaciones con llaves, corchetes, paréntesis, etc. Pero veamos mas diferencias, un lenguaje semántico, sea cual sea, persigue el «de un vistazo», generalmente esta ausente de llaves y basa su estructuración en identación y estructuras muy semánticas como delimitadores de texto. Para este caso tenemos como ejemplo a VB, en el que terminamos un if con un End If, un for con un Next, etc. la identación automática que propone el propio ide de programación o como en el caso de Python, la identación es necesaria para que el interprete de Python entienda el código.

Un lenguaje matemático es en contra de un lenguaje semántico, un lenguaje de formulas y ecuaciones, que sin tener unas nociones de matemáticas y que estas nos gusten se nos pueden atragantar bastante. A diferencia de lo que ocurre en los lenguajes semánticos, este tipo de lenguajes a pesar de que la identación suele ser importante para la claridad y el entendimiento, también nos permite escribir todo nuestro código en una sola línea. Las funciones suelen estar delimitadas por llaves {} así como las clases y namespaces. Las lineas de un lenguaje matemático suelen estar delimitadas por puntos y coma «;», y como mencione antes, al tener delimitadores de linea todo el código puede estar en una única linea, como ocurre en el caso de los frameworks de javascript que comprimen su código hasta que ocupe una única linea.

¿Pero qué es mejor? Pues depende de la persona, igual que hay zapatillas para los corredores según su tipo de pisada, hay lenguajes según como programes. Hay programadores que son mas de letras, les gusta ver su código y creer que están leyendo un libro. Para ellos, un lenguaje semántico es ideal, un python o un visual basic. Para aquellos programadores que como me ocurre a mi, nos gusta ver una cierta simetría en nuestro código y que al ver el código parezca una libreta de un matemático, lleno de formulas, lenguajes como c# o java, son para mi.

¿Y cual es mejor? Pues ninguno. Lo mas importante es sentirse a gusto con el entorno con el que se trabaja. Si por ejemplo, eres un matemático puro, python es horrible, pero no quiere decir que no lo puedas utilizar. Por contra, si eres muy semántico, c# sería incomprensible. A la hora de trabajar, hay que tener en cuenta 3 factores básicos. En primer lugar en que lenguaje nos sentimos mas cómodos. Evidentemente no vamos a programar como no nos gusta (salvo que nuestro jefe nos lo diga). En segundo lugar hay que saber elegir bien el lenguaje con sus herramientas. En Lenguajes como PHP tenemos multitud de librerías y aplicaciones ya desarrolladas, en python django tenemos muchos módulos, etc. en c# el deploy es muy sencillo, pero no se nos ocurriría hacer una web en shell script por ejemplo, ya que no tenemos el mismo potencial de librerías. Por último hay que elegir sabiamente según lo que vayamos a hacer. Si por ejemplo vamos a desarrollar una pequeña aplicación, con un PHP vamos sobrados, si queremos generar una página sencilla, podemos utilizar django, pero si queremos hacer una aplicación grande y escalable, quizás c# nos convenga mas. Hay que saber equilibrar todo estos puntos para elegir siempre la mejor opción según lo que vayamos a desarrollar.

Yo programo las aplicaciones prefabricadas (wordpress, prestashop, etc) o páginas muy muy sencillas en PHP, otros proyectos a medida de mayor envergadura pero pequeños en python con django o pylons y los grandes proyectos en c# con mono aspnet mvc y AltairStudios.Core. Y tu, ¿En qué programas?

Por qué usar StringBuilder en lugar de concatenar Strings

.Net (C#), Java, Mono (C#), Programación, Visual Basic .Net / 3 comentarios / Por juan

Ando un poco liado y llevo una temporada sin escribir. Hay un apunte, que es común para varios lenguajes que son Java y por ejemplo .Net, tanto Visual Basic .Net y C#, así como el resto de lenguajes de la plataforma .Net que es la clase StringBuilder. Hay gente que no sabe por que o cuando utilizar la clase StringBuilder y realmente es uno de esos pequeños detalles de buenas prácticas, que a simple vista en un proyecto pequeño no se aprecian, pero cuando entre manos tenemos un gran proyecto que recibe millones de peticiones diarias, estas pequeñas nuevas practicas pueden suponer un gran referente de ahorro en el consumo de memoria y procesador de un servidor.

Tanto en Java como en .Net, cuando creamos un nuevo String, instanciamos un objeto String en una variable, cuando con la sentencia «+=» vamos concatenando mas texto, lo que hacen estas plataformas es crear una nueva instancia del objeto con la concatenación de las dos variables de texto. Por otro lado, cuando tenemos un StringBuilder instanciamos una clase StrringBuilder, llamando al método «append» en Java y «Append» en .Net, lo que hacemos es realizar una concatenación real de texto en el buffer de texto para luego instanciar un nuevo objeto String cuando llamemos al método «toString» en Java y «ToString» en .Net. A simple vista parece una tontería, cuando tenemos un texto que concatenamos 2 o 3 veces, realmente no merece la pena generar un StringBuilder, pero cuando concatenamos repetidamente texto varias veces el rendimiento es mayor si utilizamos StringBuilder, ya que si tenemos 20 concatenaciones seguidas, utilizando Strings normales concatenados, tendríamos 20 instancias de objetos, mientras que con StringBuilder solo 2. Como he dicho antes, en un pequeño proyecto, esto es prácticamente inapreciable, pero cuando tenemos un proyecto que recibe millones de peticiones diarias, algo tan tonto como utilizar concatenaciones de texto o StringBuilder puede suponer tener que añadir mas memoria al servidor para soportar tantas instancias de objetos e incluso un procesador mas potente para soportar el paso del recolector de basura para tantos objetos instanciados, esto en el mejor de los casos, si no llegamos al caso de tener que añadir un servidor al cluster para soportar todo esto.

Un cumulo de buenas practicas pueden suponer un gran ahorro de recursos, que se traducen en ahorro de dinero, cuando se trata de grandes proyectos.

Publicada la version 0.1.1 de puntoengine

PHP, Proyectos / 2 comentarios / Por juan

Ayer publiqué la versión 0.1.1 de puntoengine. Puntoengine o Punto Engine PHP acortado PEP, es un framework en fase alfa para PHP del tipo MVC o Modelo Vista Controlador. Este framework basa su funcionalidad en una mezcla de diferentes frameworks web como son ASP.Net, Java Servlets y PHP en un antiguo framework propio llamado RLM Engine. Actualmente, pese a estar en una fase de desarrollo muy verde, pero ya es completamente operativo y se pueden construir webs con un sistema de Servlets como se haría una web en Java. La versión 0.1.1 en su revisión 7 de puntoengine se trata de la versión ya publicada 0.1.1 de puntoengine pero con la documentación completa del código, lo que facilita a quien quiera ver y estudiar el código y su funcionamiento, que sea mas fácil de seguir. Para la versión 0.2 de puntoengine se espera la creación de un administrador, actualmente en fase de desarrollo para poder gestionar entre otras cosas los Servlets instalados y la preparación para futuros plugins como puede ser el sistema de CMS.

Este es un proyecto a largo plazo y muy ambicioso que espero llegue lejos y pueda utilizarlo para construir diversas webs que tengo en mente. Según un calculo realizado siguiendo el sistema COCOMO, actualmente el proyecto con casi 1500 lineas de código, tendría un coste privado de unos 6.000€. Para el que quiera echar un vistazo e incluso colaborar con el desarrollo, documentación o aportando incidencias, puede hacerlo en la web del proyecto puntoengine.

No se puede viajar al pasado con Java

Java / Deja un comentario / Por juan

Por esas casualidades de la vida y probando un sistema de aplicación de Java que usaba la hora del servidor, hicimos pruebas cambiando la hora del sistema para probar que todo funcionaba correctamente. Mientras modificábamos la hora para comprobar el buen funcionamiento, encontrábamos algún que otro bug, que corregíamos recompilando sobre la marcha.

Después de 30 minutos de constantes pruebas, y cuando nos disponíamos a realizar la compilación definitiva para realizar un pequeño parche en nuestra aplicación, nos encontramos con un problema, ¡No podemos compilar! Tenemos un problema, Java nos dice al intentar compilar que tenemos una versión más reciente ya compilada. Con las prisas y las pruebas y arreglos sobre la marcha, compilamos sin querer en el año 2008 y claro, ahora en el año 2007, Java no nos permite compilar ya que una compilación posterior ya se encuentra en el sistema.

La solución, aunque un poco drástica, se nos ocurrió en cuanto se nos paso la cara de tontos, ya que realizamos un backup y borramos todas las clases compiladas para volver a generarlas.

Es un poco curioso que Java no nos permita compilar, o mejor dicho, recompilar una clase que ya se compilo en el futuro. Si alguien os dice que sois vosotros mismos que viene del futuro para daros una versión superior de alguna clase vuestra, no se la toméis, porque no os dejara compilarla.