Lenguaje de programación ideal

[Ñuño Martínez]

Buf, buf, buf... Siempre que veo estos debates me dan calores. La mayoría de las peticiones o bien ya están resueltas, o bien no tienen nada que ver con el lenguaje sino con el compilador o el entorno en el que se ejecutan.

Por ejemplo: lo de multiplataforma. ¿Sabíais que FreePascal compila para la JVM? Pues sí, lo hace, y sin cambiar el lenguaje (bueno, cambia un poquito la nomenclatura para el USES, pero lo demás no). Ale, ya tienes resuelto el tema.

¿Y la multitarea? Bueno, los objetos son, por definición, multitarea. Otra cosa es que casi ningún compilador/entorno los implemente así. Objective C es un buen ejemplo. Small Talk es otro. Oberon otro más...

En mi opinión, si no es para algo muy específico (lenguajes de propósito específico, me refiero), no merece la pena hablar de diseñar nuevos lenguajes, porque de propósito general andamos sobrados. Mejor preguntar por cómo sería nuestro compilador o entorno soñado. Ahí sí, oye.

[TiammatMX]

...buscarles chichis a las víboras, como decimos en México? El lenguaje ideal, el que es verdaderamente multiplataforma, simple, fácil, poderoso, VERDADERAMENTE orientado a objetos y tan excelente que el motor de búsqueda de Google está programado en él...: Python.

[[rretamar]]

Empezado por tiammat

...buscarles chichis a las víboras, como decimos en México? El lenguaje ideal, el que es verdaderamente multiplataforma, simple, fácil, poderoso, VERDADERAMENTE orientado a objetos y tan excelente que el motor de búsqueda de Google está programado en él...: Python.

Pero no sirve para varias cosas , y no hablo de superprogramas de simulación con 50000 threads capaces de predecir el universo (?), sino algo mucho más normal como hacer una aplicación de escritorio medianamente sofisticada. O sí, sirve, pero es muchísimo menos productivo que Delphi o Lazarus, además muchas funcionalidades quedarán recortadas o dependeremos de herramientas/lenguajes de terceros.

[TiammatMX]

Empezado por rretamar

Pero no sirve para varias cosas...

...pero es muchísimo menos productivo que Delphi o Lazarus...

Depende, por que yo he visto páginas web completamente realizadas en Python, varios programas en Linux y demás programados en éste lenguaje. OK, es un lenguaje interpretado, pero podría ser peor...

[[nlsgarcia]]

mamcx,

Empezado por mamcx

...En cuanto a manejo de bases de datos, todo esta tan crudo aun...excepto cuando era con Dbase. Incluso Delphi esta por debajo...

Nelson.

[mamcx]

Crudo? Uff! un monton.

Por ejemplo, esto:

Código SQL [-]
SELECT * ;
   FROM tastrade!customer ;
   WHERE customer.country = "Canada" ;
   INTO ARRAY aMyArray

Se hace en foxpro (copia los resultados en un array). No asi:

Código PHP:

cmd.text = "SELECT * ;" +
   "FROM tastrade!customer ;"
   "WHERE customer.country = \"Canada\" ;"
   "INTO ARRAY aMyArray";
cmd.execute()

for row in rows:
//Copiar el array... 


Cuando trabajaba con fox, no sabia que existían problemas con los lenguajes OO y el acceso a bases de datos (el "impedance mismatch"). Tampoco habian injecciones sql, porque el sql se escribia directo, no armando cadenas.

Ahora, lo mas cercano seria algo como LINQ:

Código SQL [-]
from p in db.Purchases
where p.Customer.Address.State == "WA" || p.Customer == null
where p.PurchaseItems.Sum (pi => pi.SaleAmount) > 1000
select p

Lo cual es genial. El compilador te ayuda con errores cuando cambia una tabla o campo (de nombre o tipo). Y automaticamente genera el sql de acuerdo a la BD. O si no es una BD? Pues tambien:

http://code.msdn.microsoft.com/101-L...mples-3fb9811b

Código PHP:

public void Linq6() 
{ 
    int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 }; 
  
    var numsPlusOne = 
        from n in numbers 
        select n + 1; 
  
    Console.WriteLine("Numbers + 1:"); 
    foreach (var i in numsPlusOne) 
    { 
        Console.WriteLine(i); 
    } 
} 


Asi que el como ejecutar consultas es un primer problema. Luego viene el problema de como hacerlo de forma asincronica/paralela. Con canales de GO, el comando await en .NET es un gran avance.

Luego viene otro problema, que mostre levemente con el codigo de fox. El como pasar datos a las estructuras (hacer binding). Con fox era muy facil incluso linkear a variables, copiar a cursores en memoria y cosas por el estilo. Con LINQ es masomenos igual de bueno, pero no identico. Ya que fox tenia el motor integrado, no se pierde ni la abilidad ni la velocidad al procesar localmente los datos.

Lo mas cercano? Creo que python tiene http://pandas.pydata.org/pandas-docs/stable/10min.html (pero diverge mucho...). Asi que este paso es el del procesamiento local.

Cuando mencione que el manejo de Bases de datos es crudo, realmente estaba pensando en "datos" en general.

Asi que corremos la consulta de clientes y obtenemos un conjunto de datos. Esta en un dataset o un diccionario. No es lo mismo a que si estuviera en una tabla de datos local...

Luego esta el problema en si de binding, validacion, procesamiento/transformacion.

Pensemos en el binding. Delphi es genial con su TDataSet, pero eso tambien es una muy pobre opcion (en mi epoca de fox, uno no sabia que el binding era problematico!). La mejor idea actual es la programacion reactiva... porque resuelve el problema de los eventos.

El uso de eventos (los tipicos OnClick) se vuelven muy complicados con el tiempo, y enredados de verificar, testear y entender. Son codigo espaguetti. Y en el momento que se le meten cosas asincronicas? Sin ayuda del lenguaje/librerias es imposible de manejar...

Un ejemplo:
http://swannodette.github.io/2013/07...ial-processes/
https://github.com/ReactiveCocoa/ReactiveCocoa

Y la validacion y definición de campos. Un ejemplo de como podría ser, de cuenta de python/django:

Código PHP:

class Membership(models.Model):
    person = models.ForeignKey(Person)
    group = models.ForeignKey(Group)
    date_joined = models.DateField()
    invite_reason = models.CharField(max_length=64) 


Y un formulario se hace asi:

Código PHP:

class ContactForm(forms.Form):
    subject = forms.CharField(max_length=100)
    message = forms.CharField()
    sender = forms.EmailField()
    cc_myself = forms.BooleanField(required=False) 


Y es de notar: 1) No hay nada de GUI ahi. Y sin embargo, es un formulario funcional. Es 100% testeable, 100% multiplataforma, 100% no visual.

Ahora resumiendo (porque como notan, me toca jalar de multiples lenguajes y entornos) como se veria un lenguaje para que fuera como en foxpro, pero moderno?:

P.D: La sintaxis y todo es un invento, aun no tengo nada en concreto.

Código PHP:

#Asumiendo que sqlite esta integrado
uses:
    db, sqlite3, mysql

Record Invoice:
    ref:Str
    customer:Customer
    subTotal:Money    
    total:Money
    date:Date = Date.now

class Invoices(Table)
    record = Invoice
    indexBy = [record.ref] #Define los indices

#Antes de guardar
def Invoices.willAppend(old, new:Customer):Err
    if new.customer is None:
        return Err('Customer is empty', new)

#Automaticamente se actualiza si cambian los records y procesa la suma
#Una implementacion http://docs.espressologic.com/docs/tutorial
def Invoices.total():Money
    sumTotal = sum(self.items.total)
    
    return react(self.records, sumTotal)

db = MySql('localhost'..)

db.register(Invoices)

i=Invoices()

i.append(ref=1, customer=c, date=Date(2000,02,01), subTotal=10, total=20)

#Como en linq, los query se pueden guardar y componer
query = select x in db.Invoices if customer==c

query = query if total > 0

for x in query:
    print x


#Que consulta tan lenta!

async datos = query.execute()

#No hay callbacks
#A proposito, recuerdan el bind?
#Funcionando sobre el subconjunto de datos
print datos.total().value

#Y como en fox, puedo jalar los datos a un engine local:
dbLocal = sqlite3(':memory')

dbLocal.import(datos)

#ahora consulto los datos locales:

query = select x in dbLocal.Invoices if customer==c 


[[nlsgarcia]]

mamcx,

Empezado por mamcx

...Cuando mencione que el manejo de Bases de datos es crudo, realmente estaba pensando en "datos" en general...lo mas cercano seria algo como LINQ...La mejor idea actual es la programación reactiva...porque resuelve el problema de los eventos...

Entiendo tu punto de vista

Nelson.

[mamcx]

Empezado por Ñuño Martínez

¿Y la multitarea? Bueno, los objetos son, por definición, multitarea. Otra cosa es que casi ningún compilador/entorno los implemente así. Objective C es un buen ejemplo. Small Talk es otro. Oberon otro más...
.

De donde sacas esto?

Empezado por Ñuño Martínez

En mi opinión, si no es para algo muy específico (lenguajes de propósito específico, me refiero), no merece la pena hablar de diseñar nuevos lenguajes, porque de propósito general andamos sobrados. Mejor preguntar por cómo sería nuestro compilador o entorno soñado. Ahí sí, oye.

Eso es como decir que no hay que hacer nuevos programas porque los que hay ya cubren las necesidades.

Un lenguaje de programación (que es algo que esta intrínsecamente ligado a su entorno/runtime/compilador/librerías) es algo que afecta profundamente el como y cuales problemas se resuelven. Y generan un mundo de diferencia.

Por ejemplo, ya que han mencionado erlang: No hay nada que lo toque en multitarea y todo eso. Python es sobrado en claridad de código. Lisp permite metaprogramacion como ninguno y asi por el estilo.

Si uno solo sabe pascal y no sabe nada mas, es muy dificil darse cuenta todo el trabajo idiota que se esta uno cargando. Y eso aplica a todo.

Y cual es la forma de resolver las tareas mundanas (como manejo de memoria) y permitir hacer cosas que en otros entornos es muy dificil (como multitarea)? Pues a nivel del lenguaje. Y es por eso que hay tantos, muchos mas y mas variados de lo que uno se imagina.

Piensen como usuarios. No es la idea "bueno ya que con C se puede hacer de todo, porque no usar C y ya?", sino "como seria un lenguaje que no este amarrado por el status quo? como podria hacerse aun mejor?".

De seguro hay muchas ideas que andan por ahi flotando y que quizas estan enterradas. Apenas esta resurgiendo la programacion funcional, por ejemplo. Me entere hace muy poco, que ADA (un pascal) manejaba multi-hilos de una forma muy simple, casi como en GO/Erlang. En cuanto a manejo de bases de datos, todo esta tan crudo aun...excepto cuando era con dbase. Incluso delphi esta por debajo.

Y todas esas deficiencias no se pueden arreglar parchando lo que ya existe. Primero, porque en el momento que se desvia del proposito inicial del lenguaje la cosa se ve "alienigena" - como implementar OO en C- y cuando ya hay una tonelada de codigo escrito nadie quiere moverse, no importa lo mejor que sea. Asi que si por ejemplo queremos hacer programacion escalable, multihilos y demas estamos fregados con delphi. Nunca tuvo eso en cuenta, asi que lo que se hace es parchar y hackear. Igual esta fregado python, que aun en python 3 tiene el GIL. Y aun cuando le arreglen esas cosas, todo el codigo asume que nada de eso existe y puff... se arruina todo.

LLevo mas de 1 decada programando y en muchos ambientes y lenguajes. Y es precisamente por eso que me parece que aun falta mucho. Es una desgracia que muchas de las mejores ideas estan implementadas en lenguajes con sintaxis y metodologias bizarras (erlang, haskell, racket) y que los mas populares sean un gran ejemplo de como NO hacer las cosas (c, c++, php) que requieren tener experiencia para pelear en contra de lo que los lenguajes/librerias estimulan.