C vs Python

[jonym...@gmail.com]

Esto ya lo publiqué con otro título que creo no se entendió.

Sí sí, obviamente cada lenguaje de programación tiene su campo de aplicación y el de Python es muy amplio y ventajoso en distintos contextos, poseedor de un "sintax sugar" del que C no puede gozar.

Pero yo creo que C está siendo subvalorado y no lo estamos utilizando donde sí deberíamos hacerlo. 

Tiene C mayores ventajas de las que somos conscientes?

Yo creo que sí, sobre todo para las "comunidades C" como ésta.

Para trabajar en embebidos todos sabemos C y si formamos un grupo de desarrollo es el lenguaje en común de todos los programadores actuales y futuros que habrá en la empresa (por lo menos en los próximos años).

Entonces que trabajemos todos en lo que conocemos realmente tiene su ventaja y no hay que pagar por capacitaciones costosas.

El asunto es que C parece un lenguaje muy poco conveniente para un montón de aplicaciones fuera del microcontrolador y los sistemas...

Para eso existen DYNACE (https://github.com/blakemcbride/Dynace) y COS (https://github.com/CObjectSystem/COS). Los dos son extensiones o librerías de C para orientación a objetos. Dynace tiene un garbage collector y en COS es bastante simple usar el Bohem's garbage collector.

DYNACE es super fácil de aprender (mucho más que C++) para un programador C y un muy buen punto de entrada para la programación a objetos para el mismo. Soporta duck-typing como python que me parece el punto principal de la productividad de ese lenguaje (http://docs.google.com/View?id=dcsvntt2_25wpjvbbhk). Menos simple pero con una capacidad poderosísima (los multimétodos) es COS desarrollado por un gurú del CERN.

DYNACE tiene un preprocesador propio. COS usa C puro pero genera desde el código objeto un array de C con las clases y métodos definidos.

POR QUÉ NO ESTAMOS USANDO TODOS ESTÁS TECNOLOGÍAS?

El punto esencial me parece que está en que no hay mucho desarrollado sobre eso (librerías (aunque Dynace tiene varias ( base de datos, GUI, etc. ) ) , frameworks, etc.) ni muchos ejemplos (0 entradas en stackoverflow).

Eso me parece que podría cambiar si las "comunidades C" como ésta las elijen. Las ventajas en costos corporativos (capacitaciones y necesidades de más personal ) y personales (estar concentrado más en los problemas y menos en aprender nuevas tecnologías asociadas a otros lenguajes, sobre esta obviedad tengo una cita de Gillermo Panteleo en el libro "Calidad en el desarrollo de software") me parece que hacen valer la pena su adopción.

A VOS?

[Ing. Mirko Serra]

Es ir a contramano del mundo.

No solo por la cantidad de usuarios. Por lo que se ve de los ejemplos, fomenta todas las malas prácticas que C++ moderno abandonó para mejor y que desgraciadamente persisten y tanto nos cuestan abandonar a los que aprendimos C++ viniendo desde C.

Saludos.

Ing. Mirko Serra.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[martin ribelotta]

Bueno... va por partes.... ya Mirko hablo de lo obvio... que no lo usa
nadie y que, cualquier problema que tengas vas a estar solo o con dos
persona mas al lado... y que, obviamente, no están testeados en
entornos de producción (no el argumento que lo hizo alguien del CERN
es liza y llanamente falacia de autoridad)

El mié., 24 abr. 2019 a las 17:36, <jonym...@gmail.com> escribió:
>

> Esto ya lo publiqué con otro título que creo no se entendió.
>
> Sí sí, obviamente cada lenguaje de programación tiene su campo de aplicación y el de Python es muy amplio y ventajoso en distintos contextos, poseedor de un "sintax sugar" del que C no puede gozar.
> Pero yo creo que C está siendo subvalorado y no lo estamos utilizando donde sí deberíamos hacerlo.
>

Aparte de en kernels, guis, herramientas de sistemas, editores,
compiladores, servidores web, servidores de aplicaciones, sistemas de
misión critica, bases de datos, inteligencia artificial, redes
neuronales, aprendizaje profundo, procesamiento gráfico, y vaya uno a
saber la cantidad de cosas que me dejo afuera???
No veo que se este siendo "subvalorado", todo lo contrario, C es un
lenguaje activamente usado que viene evolucionando continuamente
(ultima versión del estándar C18 que tiene implementaciones en gcc,
clang y visual c)
Python es un lenguaje con muchas ventajas al igual que C, no es
cuestión de campos sino de evaluar la situación con visión
ingenieril... si programar fuera elegir el lenguaje adecuado
dependiendo de una receta dada por las circunstancias el mundo seria
hermoso y fácil... y no lo es.

> Tiene C mayores ventajas de las que somos conscientes?
>
> Yo creo que sí, sobre todo para las "comunidades C" como ésta.
> Para trabajar en embebidos todos sabemos C y si formamos un grupo de desarrollo es el lenguaje en común de todos los programadores actuales y futuros que habrá en la empresa (por lo menos en los próximos años).
> Entonces que trabajemos todos en lo que conocemos realmente tiene su ventaja y no hay que pagar por capacitaciones costosas.
>
> El asunto es que C parece un lenguaje muy poco conveniente para un montón de aplicaciones fuera del microcontrolador y los sistemas...
>

Creo que ya dije las aplicaciones en las que me toco usar activamente
C... no veo que este restringido a embebidos ni a software de base
(incluso he visto apps webs hechas con C por cuestiones de performance
y escalabilidad)

> Para eso existen DYNACE (https://github.com/blakemcbride/Dynace) y COS (https://github.com/CObjectSystem/COS). Los dos son extensiones o librerías de C para orientación a objetos. Dynace tiene un garbage collector y en COS es bastante simple usar el Bohem's garbage collector.
>
>
> DYNACE es super fácil de aprender (mucho más que C++) para un programador C y un muy buen punto de entrada para la programación a objetos para el mismo. Soporta duck-typing como python que me parece el punto principal de la productividad de ese lenguaje (http://docs.google.com/View?id=dcsvntt2_25wpjvbbhk). Menos simple pero con una capacidad poderosísima (los multimétodos) es COS desarrollado por un gurú del CERN.
> DYNACE tiene un preprocesador propio. COS usa C puro pero genera desde el código objeto un array de C con las clases y métodos definidos.
>
> POR QUÉ NO ESTAMOS USANDO TODOS ESTÁS TECNOLOGÍAS?
>

Acá viene la parte poco amigable mía:

Porque son todo lo que no hay que hacer:

DYNACE:
- Usa un fucking preprocesador (aparte del propio de c) para generar
código C... o sea, no es C ni por un segundo, es mas... es un
CWithClass pero sin Bjarne Stroustrup
- Usa ACTIVAMENTE memoria dinámica que se podría evitar si supieran
generar código con el preprocesador...
- Usan extensión "D"!!! Para sus archivos!!!! WTF!!!! Eso esta tomado
por, justamente, el lenguaje D... si esto salio antes, como mínimo no
ha tenido NADA de aceptación...
- Estoy viendo una carpeta win32 y otra win16... De que época es
esto??? El soporte de linux lo hacen con winegcc???!!!! Esto esta mal
en todos los sentidos...
- Estoy viendo que la metaprogramación ni se menciona en todo el
repo... el sistema de tipos es terriblemente frágil a un memory
corruption y es totalmente lo contrario de lo que se busca hoy.
- Vuelvo al punto uno.... es totalmente dinámico!!!!! Es un overhead
gigante para el sistema si tenemos que resolver todo en tiempo de
ejecución... para eso uso python... Si estoy usando C es para tener
control absoluto de que y como hago las cosas...

COS:
No tengo grandes quejas de COS, pero hay algo fundamental... usa y
ABUSA del preprocesador... en especial para generar código sensible...
eso es una invitación a no encontrar JAMAS el error cuando escribis
algo mal... prácticamente no hay forma saber que lo genero sin saber
COMO ESTA HECHO el mecanismo de las macros... lo que le quita todo el
atractivo que pudiera tener...

El problema de hacer OOP en C con estas herramientas, es que te quitan
lo único bueno que tiene la POO en C: Que podes decidir como
implementar objetos, métodos virtuales, tablas de llamadas, herencias,
etc etc... esto decide por vos como y te quita exactamente el control
que buscabas de C... y tampoco de da el dinamismo de Python porque,
simplemente no es un lenguaje interpretado (con el dinamismo que eso
trae... obviamente, a costa de una perdida de rendimiento)

Ya ni hablemos de que C++ es mucho mas que POO... que es lo único que
veo que intenta emular estas herramientas...
- Donde esta la deducción de tipos automática?
- Donde esta las funciones lambda?
- Donde esta la sobrecarga de operadores?
- Donde están los templates y el procesamiento en tiempo de compilación?

Bueno, no están por el simple hecho de que solo intentan hacer una
extensión de objetos sobre C... y eso, no es C++... de hecho los
objetos en C++ son casi un caso anecdotico, el problema es que muchos
se empeñan en presentar a C++ con un lenguaje "orientado a objetos"
porque queda cool o porque no tienen ni puta idea de lo que son los
objetos... bueno, tengo algo para decirles a esa gente: Assembler es
orientado a objetos si queremos... el codigo de maquina es orientado a
objetos. si queremos... y las suficientes piedras en la arena son
orientadas a objetos si queremos...

> El punto esencial me parece que está en que no hay mucho desarrollado sobre eso (librerías (aunque Dynace tiene varias ( base de datos, GUI, etc. ) ) , frameworks, etc.) ni muchos ejemplos (0 entradas en stackoverflow).
> Eso me parece que podría cambiar si las "comunidades C" como ésta las elijen. Las ventajas en costos corporativos (capacitaciones y necesidades de más personal ) y personales (estar concentrado más en los problemas y menos en aprender nuevas tecnologías asociadas a otros lenguajes, sobre esta obviedad tengo una cita de Gillermo Panteleo en el libro "Calidad en el desarrollo de software") me parece que hacen valer la pena su adopción.

Estas subestimando lo difícil que es ser PRODUCTIVO en una tecnología
dada, sumándole que a mas profunda la tecnología (como C++), mas
difícil es especializarse... el problema de que nadie esta adoptando
esto es simple: Llegaron 30 años tarde... no ofrecen nada que otros
lenguajes no ofrezcan (C++, python, js, java, etc etc) y son algo
nuevo a aprender con ganancia CERO.

Si me estoy equivocando en lo de ganancia cero, me gustaría ver un
ejemplo de estas cosas que tengan alguna ventaja sobre C++

[jonym...@gmail.com]

Hola Mirko,

Muchas gracias por la respuesta.

Algunas acotaciones:

El miércoles, 24 de abril de 2019, 18:19:06 (UTC-3), Mirko escribió:

Es ir a contramano del mundo.

Si lo que te referís a que el mundo no está usando estos frameworks, claro, por eso es que esto es una propuesta, al igual que todas las cosas cuando comienzan no tienen muchos adherentes. 

No solo por la cantidad de usuarios.

Claro que ese es un problema, pero eso puede cambiar si vemos las ventajas de usarlos.

Por lo que se ve de los ejemplos, fomenta todas las malas prácticas que C++ moderno abandonó para mejor y que desgraciadamente persisten y tanto nos cuestan abandonar a los que aprendimos C++ viniendo desde C.

La verdad en estos dos frameworks que comento no veo lo que decís. No sé a qué estándar de C++ te referís yo aprendí C++ en 2006 y lo que puedo decir es que estos modelos de objetos superan a C++ EN CIERTOS aspectos. El mejor de estos dos es COS con un modelo de objetos abierto lo que permite una mejor separación de concerns y la combinación de multiple dispatch como en CLOS con reenvío de mensajes como en Objective-C lo hace muy poderoso, podés ver los patrones de diseño en la documentación. Por otro lado, los modelos de objeto de lenguajes fuertemente tipados como C++ actualmente no están muy bien vistos. El punto a favor de estar basado en C es la simpleza del lenguaje, la popularidad y la portabilidad.

Te invito a darle una mirada más a la documentación de Dynace que incluye una crítica a C++ y a la documentación de COS, quizás cambies de opinión es esto último.

Saludos,

Jonathan 

Saludos.

Ing. Mirko Serra.

El mié., 24 abr. 2019 a las 17:36, <jonym...@gmail.com> escribió:

Esto ya lo publiqué con otro título que creo no se entendió.

Sí sí, obviamente cada lenguaje de programación tiene su campo de aplicación y el de Python es muy amplio y ventajoso en distintos contextos, poseedor de un "sintax sugar" del que C no puede gozar.

Pero yo creo que C está siendo subvalorado y no lo estamos utilizando donde sí deberíamos hacerlo. 

Tiene C mayores ventajas de las que somos conscientes?

Yo creo que sí, sobre todo para las "comunidades C" como ésta.

Para trabajar en embebidos todos sabemos C y si formamos un grupo de desarrollo es el lenguaje en común de todos los programadores actuales y futuros que habrá en la empresa (por lo menos en los próximos años).

Entonces que trabajemos todos en lo que conocemos realmente tiene su ventaja y no hay que pagar por capacitaciones costosas.

El asunto es que C parece un lenguaje muy poco conveniente para un montón de aplicaciones fuera del microcontrolador y los sistemas...

Para eso existen DYNACE (https://github.com/blakemcbride/Dynace) y COS (https://github.com/CObjectSystem/COS). Los dos son extensiones o librerías de C para orientación a objetos. Dynace tiene un garbage collector y en COS es bastante simple usar el Bohem's garbage collector.

DYNACE es super fácil de aprender (mucho más que C++) para un programador C y un muy buen punto de entrada para la programación a objetos para el mismo. Soporta duck-typing como python que me parece el punto principal de la productividad de ese lenguaje (http://docs.google.com/View?id=dcsvntt2_25wpjvbbhk). Menos simple pero con una capacidad poderosísima (los multimétodos) es COS desarrollado por un gurú del CERN.

DYNACE tiene un preprocesador propio. COS usa C puro pero genera desde el código objeto un array de C con las clases y métodos definidos.

POR QUÉ NO ESTAMOS USANDO TODOS ESTÁS TECNOLOGÍAS?

El punto esencial me parece que está en que no hay mucho desarrollado sobre eso (librerías (aunque Dynace tiene varias ( base de datos, GUI, etc. ) ) , frameworks, etc.) ni muchos ejemplos (0 entradas en stackoverflow).

Eso me parece que podría cambiar si las "comunidades C" como ésta las elijen. Las ventajas en costos corporativos (capacitaciones y necesidades de más personal ) y personales (estar concentrado más en los problemas y menos en aprender nuevas tecnologías asociadas a otros lenguajes, sobre esta obviedad tengo una cita de Gillermo Panteleo en el libro "Calidad en el desarrollo de software") me parece que hacen valer la pena su adopción.

A VOS?

--

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embeb...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embeb...@googlegroups.com.

[jonym...@gmail.com]

Muchas Gracias Ruso por tu respuesta,

Algunas acotaciones:

El jueves, 25 de abril de 2019, 23:39:40 (UTC-3), El Ruso escribió:

Bueno... va por partes.... ya Mirko hablo de lo obvio... que no lo usa
nadie y que, cualquier problema que tengas vas a estar solo o con dos
persona mas al lado...

Te cuento mi experiencia con el soporte de estos dos frameworks: El autor de Dynace es muy copado y todo lo que le he pedido me lo ha resuelto en el momento. El autor de COS está con otras cosas, pero hay gente involucrada por el buen trabajo que hizo en el CERN, tiene una mini-comunidad.

Claro que esto es chico, por eso veo que el punto de apalancamiento está en que se interese una compañía grande en esto o que una comunidad como la nuestra u otras parecidas se interesen. 

y que, obviamente, no están testeados en
entornos de producción (no el argumento que lo hizo alguien del CERN
es liza y llanamente falacia de autoridad)

Aca estás haciendo una presumpción posiblemente errónea para los dos frameworks. Dynace está siendo utilizado por una compañía de telecomunicaciones desde hace 20 años! y cuando le pŕegunte a Laurent Deniau del nivel de desarrollo de COS me dijo que el kernel (no la librería estandar) tiene calidad de producción, no sé si algo del CERN quedó implementado con ese framework, posiblemente sí.     

 

El mié., 24 abr. 2019 a las 17:36, <jonym...@gmail.com> escribió:
>
> Esto ya lo publiqué con otro título que creo no se entendió.
>
> Sí sí, obviamente cada lenguaje de programación tiene su campo de aplicación y el de Python es muy amplio y ventajoso en distintos contextos, poseedor de un "sintax sugar" del que C no puede gozar.
> Pero yo creo que C está siendo subvalorado y no lo estamos utilizando donde sí deberíamos hacerlo.
>
Aparte de en kernels, guis, herramientas de sistemas, editores,
compiladores, servidores web, servidores de aplicaciones, sistemas de
misión critica, bases de datos, inteligencia artificial, redes
neuronales, aprendizaje profundo, procesamiento gráfico, y vaya uno a
saber la cantidad de cosas que me dejo afuera???
No veo que se este siendo "subvalorado", todo lo contrario, C es un
lenguaje activamente usado que viene evolucionando continuamente
(ultima versión del estándar C18 que tiene implementaciones en gcc,
clang y visual c)
Python es un lenguaje con muchas ventajas al igual que C, no es
cuestión de campos sino de evaluar la situación con visión
ingenieril... si programar fuera elegir el lenguaje adecuado
dependiendo de una receta dada por las circunstancias el mundo seria
hermoso y fácil... y no lo es.

La verdad no discuto con vos en este punto. Lo que quería decir es que muchas veces entendemos como lenguaje apropiado para resolver cierto problema a otro fuera de C (por ejemplo Python)  y yo veo que incluso ahí la situación se podría revertir y que se elija C, esta elección por otro lenguajes es lo que llame una subvaloración y para nada me he fijado en el tamaño de esto. Hay algunos contextos donde parece claro que C queda afuera indiscutiblemente: desarrollo web de alto nivel, aplicaciones enterprise, etc. 

> Tiene C mayores ventajas de las que somos conscientes?
>
> Yo creo que sí, sobre todo para las "comunidades C" como ésta.
> Para trabajar en embebidos todos sabemos C y si formamos un grupo de desarrollo es el lenguaje en común de todos los programadores actuales y futuros que habrá en la empresa (por lo menos en los próximos años).
> Entonces que trabajemos todos en lo que conocemos realmente tiene su ventaja y no hay que pagar por capacitaciones costosas.
>
> El asunto es que C parece un lenguaje muy poco conveniente para un montón de aplicaciones fuera del microcontrolador y los sistemas...
>
Creo que ya dije las aplicaciones en las que me toco usar activamente
C... no veo que este restringido a embebidos ni a software de base
(incluso he visto apps webs hechas con C por cuestiones de performance
y escalabilidad)

> Para eso existen DYNACE (https://github.com/blakemcbride/Dynace) y COS (https://github.com/CObjectSystem/COS). Los dos son extensiones o librerías de C para orientación a objetos. Dynace tiene un garbage collector y en COS es bastante simple usar el Bohem's garbage collector.
>
>
> DYNACE es super fácil de aprender (mucho más que C++) para un programador C y un muy buen punto de entrada para la programación a objetos para el mismo. Soporta duck-typing como python que me parece el punto principal de la productividad de ese lenguaje (http://docs.google.com/View?id=dcsvntt2_25wpjvbbhk). Menos simple pero con una capacidad poderosísima (los multimétodos) es COS desarrollado por un gurú del CERN.
> DYNACE tiene un preprocesador propio. COS usa C puro pero genera desde el código objeto un array de C con las clases y métodos definidos.
>
> POR QUÉ NO ESTAMOS USANDO TODOS ESTÁS TECNOLOGÍAS?
>
Acá viene la parte poco amigable mía:

Porque son todo lo que no hay que hacer:

DYNACE:
 - Usa un fucking preprocesador (aparte del propio de c) para generar
código C... o sea, no es C ni por un segundo, es mas... es un
CWithClass pero sin Bjarne Stroustrup

Admito que eso no es muy lindo, pero a favor logra una sintaxis muy simple agregando 5 palabras a C lo que lo hace muy fácil de aprender, por este lado me parece la mayor ventaja, además de las librerías. 

 - Usa ACTIVAMENTE memoria dinámica que se podría evitar si supieran
generar código con el preprocesador...

 

Si llegas a investigar otros frameworks que utilizan C89 se ven muy limitados en lo que logran (siguen precisando mucho boilerplate code). Lo de memoria dinámica no me molesta mucho si estás en un contexto dónde te sobra. 

 - Usan extensión "D"!!! Para sus archivos!!!! WTF!!!! Eso esta tomado
por, justamente, el lenguaje D... si esto salio antes, como mínimo no
ha tenido NADA de aceptación...

No sé bien a qué te referís... al igual que java, python y otros Dynace utiliza un único archivo para definir sus clases y en vez de ser .java es .d de dynace

 

 - Estoy viendo una carpeta win32 y otra win16... De que época es
esto??? El soporte de linux lo hacen con winegcc???!!!! Esto esta mal
en todos los sentidos...

La librería precisa de winegcc, no el kernel. Esto tiene más de 20 años en producción. Obviamente que hay lo que desarrollar, esto es para mostrar el potencial

 

 - Estoy viendo que la metaprogramación ni se menciona en todo el
repo...

te referis a la documentación de cómo procesa su DSL? 

el sistema de tipos es terriblemente frágil a un memory
corruption y es totalmente lo contrario de lo que se busca hoy.

Que interesante, qué ves de eso? no crees que se puede mejorar?

 

 - Vuelvo al punto uno.... es totalmente dinámico!!!!! Es un overhead
gigante para el sistema si tenemos que resolver todo en tiempo de
ejecución... para eso uso python... Si estoy usando C es para tener
control absoluto de que y como hago las cosas...

Es que estamos difiriendo aca en las situaciones en que lo usaría. La gran ventaja que le veo a python son las metaclases con ducktyping, esto lo tiene dynace y abandonar C (llamo abandono por ejemplo en una compañía en que todos saben C bien pero no quizás otros lenguajes) por un poco de sintax sugar me parece que no vale la pena.

COS:
No tengo grandes quejas de COS,

Vamos!!! 

pero hay algo fundamental... usa y
ABUSA del preprocesador... en especial para generar código sensible...
eso es una invitación a no encontrar JAMAS el error cuando escribis
algo mal...

Sí, experimenté ese problema, los errores que te tira gcc no son muy inteligibles 

prácticamente no hay forma saber que lo genero sin saber
COMO ESTA HECHO el mecanismo de las macros... lo que le quita todo el
atractivo que pudiera tener...

 

El código es abierto y podés expandir las macros, si conoces el framework te acostumbras a ver los errores en la expansión.

Igualmente no creo que no haya solución a esto, si agregas una herramienta de análisis anterior a gcc podés obtener los errores en forma legible para el programador. Las herramientas text to text de eclipse tienen varias facilidades para crear algo así, pueden buscar Xtext.

 

El problema de hacer OOP en C con estas herramientas, es que te quitan
lo único bueno que tiene la POO en C: Que podes decidir como
implementar objetos, métodos virtuales, tablas de llamadas, herencias,
etc etc... esto decide por vos como y te quita exactamente el control
que buscabas de C...

 

de nuevo en ciertas aplicaciones, no deseas tanto control a costa de productividad. 

 

y tampoco de da el dinamismo de Python porque,
simplemente no es un lenguaje interpretado (con el dinamismo que eso
trae... obviamente, a costa de una perdida de rendimiento)

Hay que evaluar cuánto suma el interprete de python en la productividad vs otra metodología de desarrollo. 

Igualmente existen intérpretes de C, aunque para que funcionen con COS entiendo que se precisa desarrollo.

Ya ni hablemos de que C++ es mucho mas que POO... que es lo único que
veo que intenta emular estas herramientas...

Un Lenguaje POO consiste de un modelo de objetos y ciertas facilidades para utilizarlas. Estos dos frameworks poseen también eso y en última instancia no hay por qué cargar solo al lenguaje con esa responsabilidad, dentro de poco les voy a pasar mi tesis donde hablo de eso.

Fijate que la gente de C++ también vió la ventaja del multiple dispatch y así surgió una librería llamada YOMM muy performante, pero en cuanto a facilidad te digo que prefiero COS!

 

 - Donde esta la deducción de tipos automática?

Eso pertenece a otra filosofía que genera alto acoplamiento entre módulos. 

 - Donde esta las funciones lambda?

En COS lo logras con Functor_t 

 - Donde esta la sobrecarga de operadores?

Eso es dicutido, java no tiene. Igualmente como dije la desventaja final de quedarse en C es el sintax sugar. 

 - Donde están los templates y el procesamiento en tiempo de compilación?

 

Esto está basado en otro tipo de genericidad más poderosa (menos eficiente pero más genérica), busca un poco sobre CLOS y funciones genéricas 

 

Bueno, no están por el simple hecho de que solo intentan hacer una
extensión de objetos sobre C... y eso, no es C++... de hecho los
objetos en C++ son casi un caso anecdotico, el problema es que muchos
se empeñan en presentar a C++ con un lenguaje "orientado a objetos"
porque queda cool o porque no tienen ni puta idea de lo que son los
objetos...

 

Cómo lo presentó Stroustrup? 

bueno, tengo algo para decirles a esa gente: Assembler es
orientado a objetos si queremos... el codigo de maquina es orientado a
objetos. si queremos... y las suficientes piedras en la arena son
orientadas a objetos si queremos...

claro, es un paradigma, el tema es la conveniencia de hacerlo. 

 

> El punto esencial me parece que está en que no hay mucho desarrollado sobre eso (librerías (aunque Dynace tiene varias ( base de datos, GUI, etc. ) ) , frameworks, etc.) ni muchos ejemplos (0 entradas en stackoverflow).
> Eso me parece que podría cambiar si las "comunidades C" como ésta las elijen. Las ventajas en costos corporativos (capacitaciones y necesidades de más personal ) y personales (estar concentrado más en los problemas y menos en aprender nuevas tecnologías asociadas a otros lenguajes, sobre esta obviedad tengo una cita de Gillermo Panteleo en el libro "Calidad en el desarrollo de software") me parece que hacen valer la pena su adopción.

Estas subestimando lo difícil que es ser PRODUCTIVO en una tecnología
dada, sumándole que a mas profunda la tecnología (como C++), mas
difícil es especializarse... el problema de que nadie esta adoptando
esto es simple: Llegaron 30 años tarde... no ofrecen nada que otros
lenguajes no ofrezcan (C++, python, js, java, etc etc) y son algo
nuevo a aprender con ganancia CERO.

Claro que ofrecen: en portabilidad, sencillez y disponibilidad de programadores: C89 (preprocesador C99 en el caso de COS). En el caso de COS tenés en forma eficiente multiple dispatch con message forwarding y un modelo de objetos abierto y te contesto en la siguiente.  

Si me estoy equivocando en lo de ganancia cero, me gustaría ver un
ejemplo de estas cosas que tengan alguna ventaja sobre C++

Fijate en la documentación de COS lo que permite ese modelo de objetos. Y de nuevo por qué salió un paper en el que estuvo involucrado Stroustrup de cómo tener multiple dispatch en C++, lo que llevó a la librería YOMM que no la exploré demasiado pero no me gusta en principio, me parece complicada y COS me parece sencillo.

Lo que propongo es un poco utópico, tiene que haber interés, pero podríamos vivir con C incluso donde no estamos acostumbrados a usarlo y podrías estar desarrollando por ejemplo en un framework web MVC sin tener que aprender un nuevo lenguaje sino una librería con las ventajas que ya comenté. En esto le veo una gran ventaja, si todos la vemos en el futuro algo nuevo podría surgir.

de nuevo muchas gracias por la respuesta y espero una reevaluación como con Mirko.

Saludos!

> A VOS?
>
> --
> -- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embeb...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

> ---
> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

> Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embeb...@googlegroups.com.

[Ing. Mirko Serra]

>> La verdad en estos dos frameworks que comento no veo lo que decís.

Los ejemplos de DYNACE sin ir más lejos, tienen prácticas que hoy se consideran malas prácticas de programación. No es porque la gente de DYNACE sea necesariamente mala programando, es lo que haríamos normalmente si estuviéramos programando en C. En C era considerada buena práctica declarar todas las variables al inicio (era la única forma en las primeras versiones del lenguaje). Porque era la más cercana al hardware. Hoy dejamos ese trabajo al compilador. Y se aconseja declarar las variables donde las vas a usar.

Se hace:

object myObj;

InitDynace(&argc);

Acá ya hay algo mal: estás llamando a la inicialización de Dynace luego de declarar el objeto. No sé si es un error o no, pero la lógica diría que primero inicialices la librería y luego la uses. Por ahí anda. Segundo, dice object y no queda claro si está inicializado o no. ¿Es usable o no el objeto myObj? ¿Está en un estado inconsistente? El compilador lo conoce pero todavía no inicialicé Dynace. El Constructor es la herramienta de C++ para conservar como invariante la inicialización de un objeto. En C el objeto se alloca y luego se inicializa, en C++ esto es un solo paso. Por supuesto, programando en C++ podés hacer una función init() y que sea obligatorio usarla. Pero eso es programar C, no C++, aunque pongas la palabra class en algún lado. Una de las prácticas de programación que fomenta C++ de toda la vida, pero que C++ moderno hace énfasis es: no tener objetos sin inicializar.

myObj = gNewWithInt(ShortInteger, 6);

gDispose(myObj);

Ahora, esto está mal en tantos niveles... Primero, ¿me vas a decir que eso es más sencillo que myObj= new ShortInteger(6);? Parte del problema es querer meter con un framework cosas que son competencia del compilador. Segunto, en C++ moderno está desaconsejado el uso de delete y C++14 ya se desaconseja el uso de new. ¿Por qué? Porque hay mejores formas de hacer las cosas, en particular, usando RAII, una técnica que asegura código más limpio, más legible y con menos bugs. Tercero, ¿qué pasa si reasigno a myObj otro gNewWithInt? Estoy imaginando que lo más probable es un memory leak. ¿Y si hubiera puesto object myObj= gNewWithInt(ShortInteger, 6); estaba bien? ¿Y si lo hacía antes del InitDynace?

Siguiendo las buenas prácticas, en C++ moderno es difícil tener un memory leak (estoy tentado a poner no existen los memory leaks en código C++ moderno bien escrito, a riesgo de caer en una falacia de ningún escocés verdadero).

En vez de:

gPrint(myObj, stdoutStream);

Haríamos
std::cout << myObj;

Que no solo es más lindo a la vista. Es parte de un estándard. Y es typesafe. Y uno lo puede implementar como quiera.

En vez de:

gChangeShortValue(myObj, 77);

Podría ser:

myObj.set(77);

myObj= 77;

Y el nombre gChangeShortValue me indica que tengo que saber el nombre de la función para cada cosa que quiero usar... Entonces, además de tener un tipado en la variable, también lo tengo en la función. Si yo mañana cambio myObj por un LongInteger, en C++ ese es código que si es correcto no se toca... pero el gChangeShortValue deja de ser válido, y no parece haber muchos hints para que el compilador lo vea (porque no es parte del lenguaje). ¿Y cómo sé que tengo que usar  gChangeShortValue o gChangeLongValue si solo recibo un object?

Ni hablemos del garbage collector... Para usar algo así, que puede tener penalidades de performance, mejor usar Java. La ideología de C++ es zero overhead.

>> No sé a qué estándar de C++ te referís yo aprendí C++ en 2006  

Justamente ese es el problema. Hay C++ pre-11 y lo que se llama C++ moderno. C++ ha pasado a un esquema de releases frecuentes del lenguaje, planificados, como es en el caso de cualquier software bien manejado. Léase: C++11, C++14, C++17 y próximamente C++20, del que el último compilador que te bajes (clang o gcc; a veces incluso los de Microsoft) ya tiene soporte experimental. En el 2019, cualquier cosa anterior a C++11 casi que no es C++... así como casi nadie usa un C anterior a C99.

Encima, la gran parte de la gente que sabe programar C++ viniendo de C tiene malos hábitos de programación (me incluyo, tratando de corregirlos) y C++ está en general enseñado por gente que viene de C. Básicamente, si enseñándote C++ te enseñaron printf, por ejemplo, o lo primero que se pusieron a hacer es declarar char*, están haciendo mal las cosas. Pero es lógico, porque así es como lo aprendió el que te lo va a enseñar: C y luego C++.

>> Por otro lado, los modelos de objeto de lenguajes fuertemente tipados como C++ actualmente no están muy bien vistos.

No me parece (¿muy bien vistos por quién?). Más vale todo lo contrario, se usa fuertemente tipado pero a la vez utilizando templates (y los templates están de toda la vida en C++) que te abstraen de esos tipos. Se produce código genérico, que funciona independientemente del tipo, pero que se instancia en un tipo de datos particular, lo que es rápido y eficiente. Por ejemplo, usando auto.

>> El punto a favor de estar basado en C es la simpleza del lenguaje, la popularidad y la portabilidad.

C es simple, popular y portable. C a secas. Cuando le ponés un framework, queda limitado en simpleza, popularidad y portabilidad por el framework. Ya establecimos que no es popular. Y en el código de arriba, C++ es más simple. La simpleza, por otro lado, es relativa: un PIC12F te va a decir que tiene "solo 35 instrucciones", el juego de instrucciones de Intel x86 son dos libros.

Tal vez el C++ es más completo que C, por lo tanto hay más que aprender. Pero no diría más, diría diferente. En C necesitás saber cómo armar una lista enlazada. Entonces todos tenemos que escribir y debuggear una variedad de listas enlazadas (reinventar la rueda). Por supuesto, no es parte del lenguaje, pero es necesario para trabajar. Entonces decir que C es simple me parece un engaña pichanga mayúsculo, y es rebajar a los que consiguen hacer buen código de C, cosa que es compleja. 

C++ incluye en sus librerías código que funciona excelentemente bien y es más performante que el que vos o yo vamos a escribir en una tarde... y es parte del estándard. ¿De qué sirve tener un lenguaje performante para luego usar código sin optimizar? (no te quita la posibilidad de escribir tu lista enlazada si tenés ganas... solo hay cosas mejores para hacer).

Y la portabilidad y la popularidad son en realidad solo dos aristas de algo más grande: el soporte. La portabilidad es el soporte en cuanto a arquitecturas. La popularidad te da soporte en cuanto a foros, contenido, probabilidades de que el proyecto no muera. Tanto C como C++ tienen detrás un estándard ISO. Excelente soporte.

Pero como la librería de C++ forma parte del estándard, eso amplía el soporte. Y los compiladores y las herramientas disponibles son parte del soporte. Un clang de hoy ya soporta features del año que viene de C++... mejor soporte no sé si haya.

>> Te invito a darle una mirada más a la documentación de Dynace

Gracias, pero no, gracias. Me siento tentado, por la curiosidad, pero el tiempo es tirano. Habiendo leído los ejemplos ya decidí que no es algo en lo que gastaría más tiempo. Me parece mejor inversión de tiempo aprender C++.

Saludos.

Ing. Mirko Serra.

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

[Jonathan Marino]

Hola Mirko,

disculpa la tardanza.

No creo que tenga tiempo para explayarme mucho más que lo que lo hice con el Ruso.

Las críticas que haces respecto a la codificación tienen que ver con C (y a veces C89) vs C++, no con respecto al framework, y por lo visto defendes la sobrecarga de operadores pero por ejemplo JAVA decidió no hacerlo.

Voy a dejar de hablar de Dynace porque nadie tocó el tener que pensar bajo un modelo de objeto muy distinto que era la ventaja de Dynace (ya que duck typing es algo muy conocido).

COS sólo depende del compilador C, por lo que es casi tan portable como C mismo, salvo que agrega uso de recursos.

Hay algo que me parece esencial aclarar: la orientación orientada a objetos no tiene una solo forma y C++ eligió una. Hay quienes vemos ventajoso el uso de open-methods y por eso, por ejemplo en C++, hay una librería para programar bajo ese "paradigma" : yomm11 (para C++11, el moderno), COS logra que programar así parezca mucho más nativo y además posee reenvío de mensajes (entre otras cosas como: un sistema de ownership y contratos), esto va más allá de como queda expresado (que en C es mediante llamadas a función que para los openmethods va muy bien y no le tengo tanto disgusto como parecería que le tenés).

Respecto a lo que escribía de los lenguajes fuertemente tipados había puesto una cita: http://docs.google.com/View?id=dcsvntt2_25wpjvbbhk.

Recomiendo fuertemente analizar las ventajas de CLOS para comprender las ventajas de la filosofía con la que fue concebido COS.

Obviamente no pretendo que vos (solo) dejes C++ por COS, lo que aca presenté fue un argumento de que en el contexto de un equipo de desarrollo en C si hubiese suficiente desarrollo hecho con COS, pudiera ser muy ventajoso utilizarlo. Si otros se suman a esa visión podría ser que un día se realice.

Saludos y gracias!

PD.: Para el que le interese, una forma simplificada de COS podría ser un buen framework para programar en embebidos. Al que le interese desarrollar algo así le puedo compartir mis ideas.