Avances, Diario de...

[SplinterGU]

con respecto a la herencia, no es que te haya ignorado, es que quizas es un poco complejo implementar eso desde C, y meteria demasiada carga.

igual, si tenes el link donde lo propusiste, por favor, compartilo nuevamente

[JaViS]

con respecto a la herencia, no es que te haya ignorado, es que quizas es un poco complejo implementar eso desde C, y meteria demasiada carga.

igual, si tenes el link donde lo propusiste, por favor, compartilo nuevamente

acabo de ponerlo un post atras: http://javis.calepin.co/propuesta-de-sintaxis-para-oop-en-bennugd.html


Yo creo que como esta bennu, implementar lo que propongo no es mucho mas. No estoy hablando de implementar objetos a nivel C, si no de implementar un par de features a los procesos de siempre, que estan haciendo falta de OOP.


Si lo pensas bien, los procesos ya son objetos, tienen un scope de codigo y variables propios, solo hay que implementar herencia y metodos.

[SplinterGU]

si, lo vi, disculpa que postee mientras escribias.

no se si es tan simple, lo vere.

[Drumpi]

Sin leerme el código, no sé qué tan complicado sería de implementar.
Si hay que implementarlo, habría que hacerlo con todas las consecuencias, es decir, pasaríamos de un lenguaje procedural a un lenguaje procedural orientado a objetos, y es un cambio bastante fuerte. Es un cambio de paradigma.

Es que a mi se me ocurre no ser tan extremista. No le he dado tantas vueltas como Javis, y no debería decir nada sin haberlo hecho, pero creo que sería más útil tener unos procesos determinados como si fueran clases (en lugar de ser process una superclase), con sus propias variables/propiedades/atributos que serían sus variables públicas, y unas funciones exclusivamente que funcionen con ese proceso.
A ver si logro explicarme:

Code Select Expand

process string_class ()
local
    string_node pointer lista_strings;
begin
    lista_strings = null;
    loop frame; end
onexit
    id.vaciar_lista();
end

function string_class.add (string cadena)
begin
    if (lista_string == null)
        string_node nueva = alloc(sizeof string_node);
        nueva.cadena = cadena;
        nueva.sig = null;
        lista_string = nueva;
    else
        (...)
    end
end

function string_class.vaciar_lista ()
(...)
end



No sé si se entiende: creamos un proceso, donde su BEGIN es su constructor (coincido con Javis) pero hay que seguir manteniendo el proceso vivo mediante un bucle; y el onexit es el destructor.
Luego tenemos las funciones que pertenecen a ese "objeto" string_class, que pueden hacer uso de sus variables privadas y publicas (las privadas no se pueden ver desde otros procesos, las públicas sí), y que se podrían llamar mediante el ID del proceso, punto, y la función que le pertenece.
Seguiría siendo más o menos lo que se tiene, pero no llega al extremo de tener un lenguaje orientado a objetos (process no sería un superobjeto, son los propios procesos los objetos). Incluso ayudaría a entender el concepto actual de variables públicas, y probablemente ayudaría a su implementación y uso interno.

Pero eso es lo malo, que es una orientación a objetos "a medias", y eso significa que hay que aprender cómo funciona y las diferencias con otros lenguajes... y que tampoco le he dado tantas vueltas como Javis :D

Lo mismo terminamos con BennuGD2 y BennuGD2++ :D :D :D

[JaViS]

Drumpi, lo que propones es exactamento lo mismo que yo propongo, yo voy un paso mas y además agrego herencia. Pero esa es mi idea de como funcionarian los procesos con metodos.

[SplinterGU]

no es tan simple implementar todo esto, y toda orientacion a objetos representa overhead.

ni hablar de la propuesta de TYPE, podriamos tener extends sobre extends sobre extends, infinitas veces, lo que complicaria el TYPE e implicaria no solo mantener datos extra, sino que cada vez que se usa TYPE hacer un barrido terrible en la lista de procesos, navegando por cada tipo hasta llegar al tipo BASE o SEMI-BASE, incluso se podrian mantener tablas para optimizar esto, pero a costo de consumo de memoria y performance.

clases con herencia con diferentes parametros, tambien es bastante complejo.

yo creo que si lo que quieres es ahorrar escribir private, publico o local repitiendo codigo, te conviene usar #define

el cambio propuesto no es tan simple como 1 solo paso, romperia compatibilidad con el sistema actual.

podria llegar a implementar poder poner punto en el nombre de la funcion o proceso, aunque pueda dar conflicto con las variables locales o privadas o publicas de un proceso. tambien podria intentar implementar sobrecarga de funciones, aunque la autoconversion de parametros podria generar severos conflictos.

la pregunta es, todo esto es realmente necesario?

esto es interesante, http://crypto.stanford.edu/~blynn/c/object.html

JaViS, para hacer lo que planteas, creo que seria mejor rehacer el compilador completamente, no en C sino en algun pseudo-lenguaje para hacer compiladores. Y creo que seria mucho trabajo, aun tengo muchas cosas criticas por resolver en el runtime, como ser el tema de las colisiones y/o fisica. no es que te haya ignorado completamente, porque esto mismo ya lo habia leido tiempo atras, pero me parece que son mas los problemas que un OOP traeria al lenguaje que las ventajas. incluso meter overhead al motor cuando muchas veces estamos devanandonos los sesos intentando rascar un par de frames.

quizas algo se me ocurra para acercar un poco a lo que vos queres.

[JaViS]

Yo creo que hoy en dia el problema de Bennu en performance no esta en el procesamiento, si no en el renderizado, no me imagino una implementacion de Type restando frames, realmente, pero bueno todo es relativo.


Por otro lado, si no nos ponemos de acuerdo en las ventajas del OOP medio que no hay lugar para una discusion.  Habiando usado lenguajes orientados y no orientados a objetos, creo que puedo opinar que es algo que ni se deberia discutir a esta altura, todos los lenguajes evolucionan naturalmente a la orientacion a objetos y las implementaciones son cada vez mas elegantes. Bennu es lenguaje muy interesante, porque de entrada tiene una estructura de codigo muy parecida a los objetos y que queda a medio camino, por lo cual seria hasta muy apropiado llevarlo al siguiente nivel.

Ademas, estamos discutiendo si mejorar la performance de Bennu o si aprovechar para actualizarlo y volverlo competente frente a las alternativas.

Por ahi te cuesta reconocerlo, yo se que tu opinion personal es que OOP no es necesario, -esta bien-, estrictamente hablando, se puede hacer lo mismo con o sin OOP, pero no puedo evitar pensar que pensas asi por falta de experiencia trabajando con lenguajes modernos, OOP tiene muchas ventajas practicas.


Edit: independientemente de mi opinion, sos vos el que lo esta haciendo, no hay lugar para ningun tipo de reclamo, y no quiero que te lo tomes asi, yo insisto porque creo que vale la pena, pero bueno, no creas que lo hago desde una posicion de comodo pidiendo huevadas, entiendo perfectamente el trabajo que requiere y no espero que hagas todo lo que te piden. Con que lo hayas considerado me basta, se que la sugerencia la di.

[Drumpi]

Hombre, yo entiendo la postura de Splinter, y también es verdad que hay MUCHÍSIMA gente que opina que la OOP es el peor cáncer que asola los lenguajes de programación :D
Tiene sus ventajas y sus inconvenientes, y a estas alturas podría tener más inconvenientes que ventajas, más que nada, por lo dicho: estamos cambiando el paradigma de programación, y además a algo totalmente nuevo, porque creo que no hay ningún lenguaje procedural orientado a objetos (al menos, que yo sepa, tampoco soy un experto), y menos si hablamos de la pseudoconcurrencia de los DIV-like.
Y cambiar el paradigma es cambiar el compilador y parte del intérprete, y aquí volvemos a la idea de BennuGD2 y BennuGD2++.

A mi me gusta la OOP, me parece ordenada y elegante, aunque no uso todas sus cualidades.
Pero en bennu no sé si es buena idea. Se supone que es un lenguaje sencillo para novatos, y siempre hemos tratado de mantenerlo simple. Aun me cuesta entender lo de las variables públicas, porque parecen puestas como un parche (con eso de que el tipo de variable debe declararse con el nombre del proceso y demás) y quizás sea lo más parecido a una OO del código (por eso decía lo de usarlas como objetos, pero nunca hablé de usar herencia, es en lo que no coincido con Javis).

Y hay más cosas que se deben acelerar en Bennu, aparte del renderizado, y es poder aprovechar el paralelismo de ejecución en las CPU multicore, eso le daría al menos un empujón del 25% de velocidad.

Realmente no puedo ponerme de lado de ninguno, en parte por mi cerebro simétrico, en parte porque no soy un erudito de los lenguajes, ni conozco la estructura interna de Bennu. Quizás me incline más en intentar mantener lo que tenemos y que funcione, que en darle un giro radical. Como mucho implementar objetos sólo para usar las variables privadas y públicas de los procesos, o más bien, funciones que "hereden" sólo las variables privadas y públicas de un determinado tipo de proceso, nada más (que no hereden ni código, ni tipo, ni constructores, ni destructores...).

Y oye, que si la sobrecarga es un problema, seguiré llamando a mis procesos mi_proceso1(a), mi_proceso2(a,b,c), etc, etc :D

[JaViS]

es verdad que hay MUCHÍSIMA gente que opina que la OOP es el peor cáncer que asola los lenguajes de programación :D

Quizas con C++ y Java, pero se evolucionó mucho desde entonces

pero nunca hablé de usar herencia, es en lo que no coincido con Javis).
[/size]

Para mi es la parte mas interesante, porque es donde mas ahorras codigo.

[SplinterGU]

Yo creo que hoy en dia el problema de Bennu en performance no esta en el procesamiento, si no en el renderizado, no me imagino una implementacion de Type restando frames, realmente, pero bueno todo es relativo.


Por otro lado, si no nos ponemos de acuerdo en las ventajas del OOP medio que no hay lugar para una discusion.  Habiando usado lenguajes orientados y no orientados a objetos, creo que puedo opinar que es algo que ni se deberia discutir a esta altura, todos los lenguajes evolucionan naturalmente a la orientacion a objetos y las implementaciones son cada vez mas elegantes. Bennu es lenguaje muy interesante, porque de entrada tiene una estructura de codigo muy parecida a los objetos y que queda a medio camino, por lo cual seria hasta muy apropiado llevarlo al siguiente nivel.

Ademas, estamos discutiendo si mejorar la performance de Bennu o si aprovechar para actualizarlo y volverlo competente frente a las alternativas.

Por ahi te cuesta reconocerlo, yo se que tu opinion personal es que OOP no es necesario, -esta bien-, estrictamente hablando, se puede hacer lo mismo con o sin OOP, pero no puedo evitar pensar que pensas asi por falta de experiencia trabajando con lenguajes modernos, OOP tiene muchas ventajas practicas.


Edit: independientemente de mi opinion, sos vos el que lo esta haciendo, no hay lugar para ningun tipo de reclamo, y no quiero que te lo tomes asi, yo insisto porque creo que vale la pena, pero bueno, no creas que lo hago desde una posicion de comodo pidiendo huevadas, entiendo perfectamente el trabajo que requiere y no espero que hagas todo lo que te piden. Con que lo hayas considerado me basta, se que la sugerencia la di.

por favor, no me malinterpretes, es claro que no me gusta la OOP, puedo argumentar muchas cosas por las que no me gustan, y en cuanto a experiencia en OOP, actualmente es lo que uso laboralmente, uso varios lenguajes OOP, que me desagradan totalmente, pero en fin... no queda otra.

por otro lado es cierto que no le veo ahora mismo la ventaja, porque se pueden hacer cosas similares pero con mas control, el tema principal es que cambia bastante el paradigma, como bien dijo drumpi, y yo creo que necesita un cambio importante en el compilador, y para meter esfuerzo en tal cambio, creo que seria mejor hacer un compilador completamente nuevo, y ahi es donde caigo en un EXTASIS PAJAL, si tengo que iniciar de cero, sin dudas debere hibernar un buen tiempo para tomar energias y ganas para iniciar algo de cero.

ahora estoy un poco entusiasmado con bennugd2, repasando todo, mejorando muchas cosas, cambiando otras e incorporando nuevas.

quizas con el motor version 2 completo, me pueda poner a experimentar estas cosas para no aburrirme.

pero quiero que no interpretes como que te ignoro o como un NO rotundo, quizas algo de lo que se plantea se pueda implementar, quizas poder implementar algo con DECLARE o algo asi, donde se pueda definir una funcion modelo con sus variables privadas y argumentos, evitando esa complejidad del TYPE (evitando ese TYPE <base> y que traiga todos los derivados), evitar los constructores y destructores, como el cambio de parametros.
lo que digo es:

DECLARE INT A(INT X)
BEGIN
   PRIVATE
        P;
   LOCAL
        N;
   PUBLIC
        M;
END

PROCESS B CLONE A
BEGIN
  ...code..
END

donde TYPE A no retornaria nada, pero TYPE B retornaria todos los procesos creados B

quizas algo de eso si se podria llegar a implementar.
PROTOTYPE
e incluso tal vez un codigo inicial en el declare, pero esto no estoy 100% que tan simple pueda resultar.

[SplinterGU]

Hombre, yo entiendo la postura de Splinter, y también es verdad que hay MUCHÍSIMA gente que opina que la OOP es el peor cáncer que asola los lenguajes de programación :D
Tiene sus ventajas y sus inconvenientes, y a estas alturas podría tener más inconvenientes que ventajas, más que nada, por lo dicho: estamos cambiando el paradigma de programación, y además a algo totalmente nuevo, porque creo que no hay ningún lenguaje procedural orientado a objetos (al menos, que yo sepa, tampoco soy un experto), y menos si hablamos de la pseudoconcurrencia de los DIV-like.
Y cambiar el paradigma es cambiar el compilador y parte del intérprete, y aquí volvemos a la idea de BennuGD2 y BennuGD2++.

A mi me gusta la OOP, me parece ordenada y elegante, aunque no uso todas sus cualidades.
Pero en bennu no sé si es buena idea. Se supone que es un lenguaje sencillo para novatos, y siempre hemos tratado de mantenerlo simple. Aun me cuesta entender lo de las variables públicas, porque parecen puestas como un parche (con eso de que el tipo de variable debe declararse con el nombre del proceso y demás) y quizás sea lo más parecido a una OO del código (por eso decía lo de usarlas como objetos, pero nunca hablé de usar herencia, es en lo que no coincido con Javis).

Y hay más cosas que se deben acelerar en Bennu, aparte del renderizado, y es poder aprovechar el paralelismo de ejecución en las CPU multicore, eso le daría al menos un empujón del 25% de velocidad.

Realmente no puedo ponerme de lado de ninguno, en parte por mi cerebro simétrico, en parte porque no soy un erudito de los lenguajes, ni conozco la estructura interna de Bennu. Quizás me incline más en intentar mantener lo que tenemos y que funcione, que en darle un giro radical. Como mucho implementar objetos sólo para usar las variables privadas y públicas de los procesos, o más bien, funciones que "hereden" sólo las variables privadas y públicas de un determinado tipo de proceso, nada más (que no hereden ni código, ni tipo, ni constructores, ni destructores...).

Y oye, que si la sobrecarga es un problema, seguiré llamando a mis procesos mi_proceso1(a), mi_proceso2(a,b,c), etc, etc :D

estoy repensando el tema de las publicas, para hacerlo mas simple, incluso la sintaxis del declare no me agrada mucho.
tambien por momentos tengo una terrible tentacion del lenguaje un like C, pero luego pienso que si hago eso, en lugar de programar en bennugd2 es mejor programar en C, que seria lo atractivo que me haria programar en bennu en lugar de C?
con respecto a ese 25% creo que lo alcance con pasar el motor a 64bits, probe con el motor en 64bits ese sample que se habia puesto de performance de unos 1000 cuadrados rebotando en pantalla, y en la prueba de 32bits me daba unos ~140fps, ahora en 64bits me da ~187fps.

[JaViS]

con respecto a ese 25% creo que lo alcance con pasar el motor a 64bits, probe con el motor en 64bits ese sample que se habia puesto de performance de unos 1000 cuadrados rebotando en pantalla, y en la prueba de 32bits me daba unos ~140fps, ahora en 64bits me da ~187fps.

Que buenas noticias :D

[Drumpi]

Anda ¿Y eso? ¿Sólo con pasarlo a 64bits? ¿Cómo es posible? ¿El compilador hace uso de instrucciones de ejecución simultánea o algo así? :D

Javis: No sé qué evoluciones ha habido. Desde luego yo programo muy cómodo en Java, no me importa su OOP (lo que no me gusta del lenguaje son las 40 capas que hay debajo, más el intérprete, mas el SO, más... o que no se tenga control alguno del uso de memoria y al final siempre se depende del recolector de basura).
Y he usado herencia y he ahorrado código, pero es algo que rara vez he necesitado programando en DIV, Fenix o Bennu, y si va a dar tantos problemas de implementación, pues no es algo que me quite el sueño, se repite código y ya está: el código de ejecución no es lo que más memoria consume.

Pero son opiniones mías, no os dejeis influir por ellas, vosotros sabeis más que yo de programación.

Javis, ¿Y por qué esa manía de escribir cosas que no se pueden leer? :D :D :D

[SplinterGU]

en procesadores 64 bits el acceso a direcciones alineas a 64bits es mucho mas rapido que a 32bits, y segun esta prueba, parece ser bastante mas rapido...

[Drumpi]

Eso díselo a los de RARE, que usaron la N64 en modo 32 bits para ganar velocidad en algunos de sus juegos :D :D :D (verídico).