Barrapunto

El problema de mejorar un lenguaje es que las mejoras tienen que estar muy meditadas para que no se pasen unas por encima de otras: una vez el lenguaje en cuestión consigue cuota de mercado, será necesario proporcionar una vía asequible de actualización a las nuevas características del lenguaje, algo que es factible pero rara vez sencillo.

Por su parte, mejorar los entornos de desarrollo desemboca en alguno de los siguientes problemas, creo yo:

1. El entorno de desarrollo se especializa tanto que sólo funciona con una revisión concreta del lenguaje. Cuando se mejora éste último se vuelve necesario revisar todo el intérprete del lenguaje que tiene el entorno de desarrollo (y muchos elementos dependientes).
2. El entorno de desarrollo no se especializa lo suficiente, con lo que alguien hace un parche para que funcione con otro lenguaje... más o menos. Se van añadiendo parches hasta que, al final, se acaba teniendo un entorno de desarrollo que funciona con muchos lenguajes de forma subóptima y probablemente con gran complejidad interna

Es posible evitar estos finales, pero requiere un auténtico acto de equilibrismo que no suele conseguirse.

Esto en lo que respecta a mi opinión personal. Por su parte, Yegge llama al interés por mejorar los lenguajes "envidia de funcionalidad", que hace que los lenguajes cada vez tomen más características del resto. Así lo entiendo yo, al menos.

El mejor lenguaje de programación ya ha sido diseñado: groovy : Java pythoneado xD

...no tiene mucha idea. Ejemplo:

"Cross-platform GUI"

¿Eso es algo que debe tener un lenguaje? Uh... No sé qué decir... Prefiero que eso sea un elemento externo, y usar el que yo necesite (si necesito). Si van a hacer algo genérico tipo EiffelVision, está bien (pero aún así, me da cosilla).

"Destructuring bind (e.g. x, y = returnTwoValues())"

Lo siento, pero eso rompe demasiado con la representación nativa que elijas... ¿Se está planteando este señor un lenguaje de "script" o de verdad?

He estado mirando por arribita a Erlang y Haskell, y al menos por lo que he visto hasta ahora, no me cabe la menor duda de que lo que necesita la Ingeniería Informática(nótese las mayúsculas) es el empleo de un lenguaje, orientado a objetos o funcional o lo que sea, que facilite la programación "correcta", osea, escribir código matemáticamente correcto, que se sepa va a funcionar.
He dicho varias veces que no soy graduado de informática, soy metalúrgico, y en tanto en la metalurgia como en la mecánica se calcula casi todo, se puede saber que una tecnología va a funcionar o no de antemano(y si no se hacen chapucerías).
A la informática le falta esto, que lo tiene, pero nadie lo usa, entonces lo que necesitamos es un lenguaje que no asuste a los "managers" o a los corre-corre del teclado, es una pena tener que complacerlos a ellos, pero son mayoría, que se le va a hacer...

"Nos cuenta": tiempo verbal presente.

Cabecera de la entrada del blog: Saturday, February 10, 2007

$ date
jue feb 12 10:22:25 CET 2009

Nivel de sarcasmo: alto

Una: las herramientas de línea de comando, sin orientación al desarrollo de front-ends y sin orientación a ningún toolkit gráfico en particular. Ejemplo: GCC, Python, Ruby, Perl.

Por otro lado tenemos los IDE "Todo en uno", donde desde la misma herramienta no sólo se soporta al lenguaje sino también a la construcción del Front End. En esta categoría entrarían cosas como Visual Studio, Delphi, C++ Builder, Gambas, RealBasic.

Personalmente me parece mucho más productivo el segundo enfoque, de cara al desarrollo de aplicaciones "de escritorio". Eso es lo que esperan los desarrolladores que vienen desde Windows y lamentablemente es lo que escasea en Linux y los xBSD.

php sin $

de solicitantes recien egresados el lenguaje de programación mas popular y por tanto el siguiente 'gran lenguaje' es...
HTML.
Por cierto, ¡necesito un basurero mas grande!

Del texto "la aplasstante realidad":

La prueba del fracaso del software libre también se ve en el mundo de los profesionales, ya sea en áreas como diseño electrónico (no existe nada similar a Protel), arquitectura (el CAD estándar -ya sabemos cuál es- solo funciona en Windows), diseño web (¿ alguna herramienta similar a Fireworks o Dreamweaver ? -y no, no me vengan con el NVU, que además de estar lleno de bugs, no tiene ni el 5 % de las prestaciones de Dreamweaver. Tampoco con Bluefish o similares...nadie en su sano juicio encararía un proyecto muy complejo con esas herramientas tan primitivas. ¿ Composición de páginas ? Scribus es un buen intento (muy verde) pero al lado del software como Quark no le llega ni a la suela de las playeras. ¿ Creación de contenido Flash (un estándar, con 99 % de instalacion en los navegadores) ? Tampoco se puede en Linux.

En el ámbito del desarrollo de software no existe una sola herramienta RAD que esté madura Gambas promete pero está en pañales, Eclipse es un monstruo devorador de RAM (Bendito seas, Java) que sólo puede usarse en un equipo con 1 Gb de memoria, Kylix prometía acercar la potencia de Delphi a Linux, pero fue discontinuado por Borland, ya que la comunidad de desarrolladores no acepta que se tenga que pagar por un software (que bien lo valía) y en cambio prefirió seguir con herramientas que no están a su altura, como Kdevelop.
Y ya que hablamos de herramientas de Borland, no es casualidad que gurús de la programación como Ian Marteens hayan abandonado Delphi y C++ Builder para adoptar el más potente sistema de desarrollo que existe actualmente: Visual Studio .NET de Microsoft.

Ninguna empresa desarrolladora de juegos en su sano juicio crearía juegos libres, porque tienen que comer y no existe un modelo de negocios que sea compatible con el software libre.
Los usuarios de Linux no quieren juegos libres. Quieren jugar a juegos de calidad comercial pero sin soltar un duro.

¿ Gestión administrativo contable ? ¿ En linux ? No hay prácticamente software en esta área.
El empresario o comerciante quiere tener algo estandar, algo que sea amigable y que funcione, algo que esté maduro. No quiere tener que estar lidiando con algo que no es lo suyo,teniendo que estar compilando desde las fuentes para al final (si es que lo logra) tener una aplicación a medio terminar.