Lenguaje de programación ideal

[mamcx]

Osea, excepto delphi

Quisiera saber que les gustaría ver en un lenguaje de programación o que problemas piensan que se deberían de resolver desde allí? Como seria su lenguaje ideal? Preferiblemente con un ejemplo concreto (porque sino todos diríamos: rapido, portable, facil de usar, etc... pero como eso en concreto?).

Tengo muchas ideas al respecto, pero me interesa escuchar opiniones. En especial, de problemas que son demasiado repetitivos y que se deberían de resolver de fondo (por ejemplo, en mi caso el que se pueda dar a una variable de forma indiscriminada el valor NULL es una aberración).

[[newtron]]

Hola.

Yo, sin entrar en debates técnicos, estaría feliz si Delphi compilara para el mayor número de plataformas posibles.

[avmm2004]

Yo, si tuviera una buena herramienta para paginas web .......... me podría morir en paz.

[[nlsgarcia]]

mamcx,

Empezado por mamcx

...¿que les gustaría ver en un lenguaje de programación o que problemas piensan que se deberían de resolver desde allí? ...

En términos generales pienso que un lenguaje de programación que combine las capacidades de C#, Delphi y Erlang, sea Multiplataforma, Multiparadigma y Multipropósito sería realmente interesante y útil en un sentido práctico. C# y Delphi ya tienen características de lo anteriormente señalado, Erlang es más especializado (Programación concurrente y paradigma funcional).

Quizás si revisas lo que Google esta haciendo con Go, te de alguna orientación de lo que una compañia con su alcance espera de un lenguaje.

Espero sea útil

Nelson.

[mamcx]

Empezado por avmm2004

Yo, si tuviera una buena herramienta para paginas web .......... me podría morir en paz.

Y eso como seria? Que le hace falta a lo que ya hay?

[mamcx]

Empezado por nlsgarcia

En términos generales pienso que un lenguaje de programación que combine las capacidades de C#, Delphi y Erlang, sea Multiplataforma, Multiparadigma y Multipropósito sería realmente interesante y útil en un sentido práctico. C# y Delphi ya tienen características de lo anteriormente señalado, Erlang es más especializado (Programación concurrente y paradigma funcional).

Conozco ya a GO. De hecho le he dado la vuelta a muchos lenguajes investigando para mi proyecto.

Pero que es lo que combinarias? Como se veria ese animal? Como seria su sintaxis? Eso es lo que pregunto. Porque es facil decir que "tenga de todo". El problema es como integrarlo en una interfaz que sea amigable?

Por ejemplo, GO hace el lanzar funciones asincronicas/paralelas muy facil con su comando

go hacerbusqueda()

.

[avmm2004]

Empezado por mamcx

Y eso como seria? Que le hace falta a lo que ya hay?

Pues no se lo que hay al cien por cien pero intraweb no es ninguna maravilla.
Raudus no se sabe de el hace algún tiempo.
Unigui sigue en fase beta y muy retrasado respecto a entregas.
y el resto ..... ¿?

[[nlsgarcia]]

mamcx,

Empezado por mamcx

...¿Pero que es lo que combinarías?, ¿Como se vería ese animal?, ¿Como seria su sintaxis?...

Nunca me he planteado el desarrollo de un nuevo lenguaje de programación, hasta la fecha solo he utilizado lo mejor que puedo los lenguajes que he tenido la oportunidad de usar en el ambiente universitario y empresarial, por ello no te puedo dar guías específicas sobre el desarrollo de un lenguaje, solo te puedo sugerir algo que siempre me ha parecido lógico en la vida y por ende en la computación : Hacer todo de la forma más simple posible sin que esto afecte la efectividad o calidad de la solución.

En su época existió el S/36 y el S/38, ambos minicomputadores de IBM. El software del S/38 era muy avanzado para su momento y por ello se creo el S/36, una versión simplificada del S/38, con el tiempo ambos sirvieron de base para el desarrollo del AS400 hoy en día conocido como iSeries, el cual es un sistema de computo que puede rivalizar con el poder de un Mainframe dependiendo de su configuración pero con la facilidad de un Minicomputador.

En el caso de Microsoft algo similar ocurrió con Visual C++ y Visual Basic, lo cual dio las bases para el nacimiento años mas tarde de C#. Hay muchas historias similares y el punto en común de todas ellas es que hicieron que todo sea más simple y potente, la clave: Simplicidad.

En el caso de Microsoft, el Framework de .NET (VM) permite la integración entre lenguajes, tipos de datos e independencia de la máquina física, sin perder la posibilidad de generar código nativo, de allí una segunda idea: Interoperabilidad a nivel de lenguajes, no tiene sentido crear un lenguaje aislado por más potente que este sea. En lo que a los tipos de datos se refiere seguiría lo planteado en C# y Delphi, fuertemente tipeado, incluyendo los modificadores de C#.

En términos prácticos (cantidad de usuarios existentes) cualquier nuevo lenguaje debe basar su sintaxis en C, sin embargo la sintaxis de Pascal es muy intuitiva, directa y fácil de leer, habría que sopesar si se quiere una sintaxis accesible a una gran base instalada de desarrolladores (C, C++, C#, Java, Python, Objective-C) o una sintaxis basada en Pascal fácil de aprender y utilizar, de allí otra punto: Sintaxis simple.

Hoy en día todo ambiente de desarrollo que sea productivo requiere un IDE y un potente compilador, luego cualquier nuevo lenguaje debe tener un IDE que permita desarrollar, compilar y probar el código realizado, esto realmente es un Plus para cualquier lenguaje, como es el caso de C# y Delphi, en el caso de Java el mejor IDE que probé fue NetBeans, por lo tanto: Un IDE flexible, potente y amigable al programador es indispensable.

Un punto crucial son los paradigmas que soporte el lenguaje, siempre me gusto la visión de Delphi de combinar los paradigmas Orientado a Objetos, Orientado a Componentes e Imperativo, en el caso de C# se cumple la misma formula con la adición del paradigma funcional, luego: Si un lenguaje es Multiparadigma y Multipropósito con una concepción flexible de los mismos (Java y C# son Orientados a Objetos Puros mas o menos, C++ y Delphi son más flexibles en su implementación de paradigmas), se puede lograr mayor adaptabilidad del lenguaje a diversos problemas: Científicos, Financieros, Económicos, Administrativos, de Ingeniería, Técnicos, etc.

El lenguaje debe ser Multiplataforma, esto se ha resuelto en la practica en mayor o menor medida con el empleo de las VM (No así en Delphi), como es el caso de Java y C#, sin embargo es necesario que se pueda compilar en Nativo ya sea por que el sistema es en tiempo real o por que su naturaleza exige altos niveles de performance. En lo personal he visto programas bancarios corriendo en .NET (Winforms) y es imperceptible el hecho de que este siendo ejecutado por una VM, lo cual indica la robustez de la tecnología de las VM en la actualidad.

Un punto importante es la concurrencia, es por ello que el caso de Erlang me parece destacable como modelo, sin embargo es necesario señalar que este es un lenguaje muy especializado en procesos asíncronos bajo paradigma funcional, lo cual lo hace por si solo todo un reto.

Creo que todo nuevo lenguaje se basa en mejoras y/o combinación de características de lenguajes anteriores, sumado a los intereses y gustos personales de su desarrollador(es), en mi caso consideraría los lenguajes mencionados (Delphi, C# y Erlang), sin embargo es una tarea realmente gigantesca crear un nuevo lenguaje de programación, quizás propia de grandes equipos o genios informáticos. En lo personal creo que sería interesante desarrollar la plataforma .NET para Linux, Android y Mac (Actualmente existe el proyecto Mono) para lo cual están disponible sus especificaciones (Standard ECMA-335) y de esa forma poder reutilizar todos los recursos actualmente disponibles en .NET en las distintas plataformas mencionadas (No reinventar la rueda), algo que no entiendo por que Microsoft no lo ha hecho aun por cuenta propia , teniendo todos los recursos disponibles para ello.

Espero sea útil

Nelson.

[Ñ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.

[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.

[[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.

[Ñuño Martínez]

Esto es lo que yo quería: Debate. Es que me parecía a mi que esto iba a derivar en que cada uno diera una lista de características, y eso no me mola. Si en realidad a mi me entanta la idea de crear lenguajes nuevos. Incluso yo también he creado alguno.

Empezado por mamcx

De donde sacas esto?

De la propia definición de objeto. Se supone que un objeto es una entidad completamente independiente, en la que los datos y el código que los manejan están íntimamente relacionados y separados del entorno. La comunicación entre objetos se realiza (por definición) mediante mensajes y estos (por definición) no revelan los detalles de su implementación, de hecho no tienen por qué ser respondidos de forma síncrona. En un lenguaje que cumpla a rajatabla esta definición (y muy pocos lo hacen; yo sólo conozco Small Talk y Objective C, y dependiendo de qué compilador/intérprete se use) la multitarea sería algo natural y no precisaría procedimientos u objetos especiales para implementarla. Más bien al contrario, necesitaría algún mecanismo para asegurarse de que una secuencia de mensajes no se respondieran de forma concurrente.

Si habéis programado para algún entorno de ventanas a bajo nivel (por ejemplo, Windows 3.1 o XWindow), sabréis que están diseñados mediante objetos y que la comunicación entre componentes se hace a través de mensajes y que pocas veces estos mensajes se responden en el momento de enviarlos. Los entornos de ventanas son de las pocas aplicaciones realmente orientadas a objetos que he visto.

Pues eso, a mi me gustaría un lenguaje que funcionara de esa forma.

Empezado por mamcx

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.

(...)

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?".

Completamente de acuerdo.

Empezado por mamcx

(...)Python es sobrado en claridad de código. (...)

Discrepo, y mucho. Personalmente me cuesta horrores hacerme una idea de cómo funcionan los programas Python. Lo he intentado. He leído tutoriales, manuales de introducción, cursos... Pero no me entra. En serio, en cuanto se meten en algo más complicado que obtener un dato y darle salida, me parece incluso más caótico que un mal programa escrito en PHP.

Además, tanto FORTRAN como COBOL desecharon la indentación significativa hace décadas porque dificultaba tanto la escritura como la lectura de programas. Me parece absurdo que un lenguaje que se considera moderno mantenga una característica tan obsoleta, útil sólo cuando se trabajaba con tarjetas perforadas.

Empezado por mamcx

(...) implementar OO en C (...)

Esto me recuerda que tengo pendiente explicar cómo programar OO en C puro y duro*, con herencia y polimorfismo, y sin necesidad de hacer cosas raras (como el horrendo MFC y similares).

Empezado por mamcx

(...) 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.

Mira, si al final no estamos tan en desacuerdo. Aunque C es mi lenguaje favorito para programación en bajo nivel, tanto C++ como sus derivados (C#, PHP**, D, JavaScript...) me parecen auténticas aberraciones. Los dolores de cabeza que me han producido tanto C++ como JavaScript son de antología.

A modo de conclusión diría que me gustaría un lenguaje realmente orientado a objetos, no a clases ni prototipos. También abogo por los lenguajes de propósito específico, y no tanto por los de propósito general.
______________________________________

* Tentado estoy de hacerlo en la sintaxis de K&R, pero creo que al final lo haría en C99 o similar.

** Ojo, a partir de PHP2, cuando autor original lo dejó en manos de unos tipejos emperrados en hacer que se pareciera a C, primero, y C++, después. Por lo que he visto, el PHP original no era tan mala idea.

[[nlsgarcia]]

Ñuño Martínez,

Empezado por Ñuño Martínez

...me encanta la idea de crear lenguajes nuevos. Incluso yo también he creado alguno...

Pregunto: ¿Que lenguaje creastes?, ¿Cual es su sintaxis?, ¿Cual es su paradigma(s)?, ¿Tipos de datos y almacenamiento persistente?, ¿Es de propósito específico o general?, ¿Es algo teórico o ya existe alguna implementación de mismo?, ¿Puedes mostrar algún programa de ejemplo?.

Pienso que crear un lenguaje es algo realmente notable

Nelson.

[mamcx]

Empezado por Ñuño Martínez

De la propia definición de objeto... La comunicación entre objetos se realiza (por definición) mediante mensajes y estos (por definición) no revelan los detalles de su implementación, de hecho no tienen por qué ser respondidos de forma síncrona.

Ah, la definición del que invento la OO!

http://programmers.stackexchange.com...bject-oriented

Un paradigma que cumple mas de cerca esa definición es el modelo de actor:
https://en.wikipedia.org/wiki/Actor_model

Empezado por Ñuño Martínez

Discrepo, y mucho. Personalmente me cuesta horrores hacerme una idea de cómo funcionan los programas Python .... En serio, en cuanto se meten en algo más complicado que obtener un dato y darle salida, me parece incluso más caótico que un mal programa escrito en PHP.

Eso si suena raro! Se que muchos detestan la identacion (significativa) pero decir que python no es legible? Mas cerca del pseudocodigo no hay. Que ejemplo podrías dar? Que es un ejemplo de algo legible?. De mas esta decir que los lenguajes que considero legibles (pascal, python, fox) tienen un aspecto de "bloques" que me parece muy intuitivo (y recuerdo que en el libro Code Complete había un estudio al respecto, de como ese estilo identado era mas claro). Aunque viendo que hay gente que le parece legible los lenguajes basados en LISP....

Lo que no me gusta de python es no poder darle los tipos a las variables. Cuando se ve una funcion read(name) no se puede deducir que pide y que devuelve y el compilador no te ayuda. Creo que el balance ideal es que el lenguaje sea tipado y permita escapar a dinámico, por ejemplo: http://cobra-language.com/. Me imagino que si se hace Customer.Name es tipado pero si se hace Customer..Name es dinámico.


Una de las cosas que le saco a python, es que no importa que código de quien este leyendo, todo parece escrito por la misma persona. Eso es algo que es difícil de encontrar en otros lenguajes.

------

Ultimamente están saliendo muchas cosas interesantes. Por ejemplo están http://julialang.org/ y http://nimrod-lang.org/. También, corriendo sobre erlang, http://elixir-lang.org/. Pero en cuanto a la OO, creo que me inclino mas por el modelo de GO.

Eso porque luego de todo este tiempo, me he dado cuenta que una jerarquía de clases tiende a ser la abstracción equivocada y el rehusó es mas problemático. Aparte, que cuando se entiende el propósito original de la OO de Alan y como se implementa el modelo de Actor se hace evidente (en mi opinión) que un programa se debe hacer mediante composición y se usan objetos para encapsular sub-procesos.

Digo que es equivocada porque es muy difícil de descomponer una jerarquía de clases, y recomponer funcionalidad para crear nuevos objetos. Por ejemplo, si se hace un control visual, digamos un listado para agenda de contactos, de donde derivo todo? Si lo saco de un grid me cargo del grid lo que no quiero (y es la abstracción errónea) y si lo saco de una lista lo mismo, no tengo lo que ya tiene el grid, y no es fácil hacer tipo "virtual", así que toca hacer casi todo desde cero. Con la composición no es así, es igual a hacer programación funcional -pero tipo OO- en donde si quieres algo combinas funciones hasta lograrlo, pero igual puedes obtener el pedacito que necesitas sin cargarte toda una jerarquía detrás...

[[Al González]]

Átomos = funciones
Moléculas = clases
(Como en GHF, para mejor aprovechamiento).

Redefinición de clases o "herencia insertada".

If Result := S <> '' Then

Que todas las funciones y métodos sean virtuales (sustituibles).

Y muchísimas otras cosas...

No al sangrado significativo.
Sí a las variables tipificadas.

Escrito desde mi teléfono (disculpen lo escueto).