« first day (2701 days earlier)      last day (490 days later) » 

12:52 AM
@CandidMoe sabes cómo usar Android IDE 2 en Ubuntu? No me detecta los puertos com
 
6 hours later…
7:08 AM
A las güenas :-)
Asco de jueves :-(
 
2 hours later…
9:36 AM
@Mateo Ni idea.
10:14 AM
Termine la construcción de la CPU J1. Ejecuta programas. Tiene un BIOS básico de E/S, y un Assembler para programarlo.
La hice usando un diseño *gate level*, es decir, a partir de componentes básicos como registros, sumadores, multiplexores, en lugar de un lenguaje especializado de alto nivel como Verilog.
Con este ejercicio práctico pude finalmente entender como funciona el hardware y sus limitaciones físicas reales. Ahora comprendo porque nada me resultaba con Verilog.
Finalmente baje la implementación Verilog de J1, para compararla con la mía. Antes no la entendía; ahora, si. Fue como un
@CandidMoe ¡ Otia ! Eres un máquina :-O
Fue un trabajo de chinos. Imaginate tener que depurar paso a paso cada instrucción, viendo que señales levanta, que combinaciones se activan. Esa era toda la herramienta de "debugging". Me sentí de vuelta al PDP-8.
jejeje ... recordando viejos tiempos :-)
Al final, lo de cualquier tiempo pasado fue mejor va a ser mentira
Ah, pero la sensación de poder es fenomenal. Tengo una CPU que es mía y hace lo que yo quiero. El hardware se acomoda a mi, no al reves.
Tiene que ser una sensación muy agradable :-)
10:27 AM
Por ejemplo, el diseño oficial tiene sólo un salto condicional ("saltar si tope_stack == 0") que siempre elimina el valor examinado. Sería mejor que lo conserve cuando no salta, pues así puedo utilizarlo para otra cosa.
Bueno, eso lo puedes simular con un dup
No se si te interesará meter mas complejidad física si lo puedes simular mediante software
@Trauma Se puede simular con un dup, pero del modo propuesto no lo necesitas. En realidad lo implemente así finalmente y me acortó el código.
jejeje ... CISC vs RISC xDD
jejeje ... eso si que es legacy code y lo demás son tonterías
Programando a nivel de puertas lógicas
10:33 AM
Ahi está la implementación a nivel de puertas. Si el opcode == 1, entonces es un salto condicional según el comparador, pero le hacemos AND con la línea T_cero. Eso chequea que el tope del stack sea 0. En caso contrario, no se activa la señal jmp_cond y se pasa a la siguiente instrucción, conservando el stack.
Vieras los días que me pase inventando cosas así.
joé, pero es emocionante
Dándole vueltas hasta dar-con-la-tecla
Lo entretenido es que esas cosas son imposibles con micro-código. En realidad hay que combinar ambas cosas.
Espero que al jubilarme me queden suficientes neuronas para poder hacer cosas guapas de esas :-)
 
10 hours later…
8:26 PM
Hoy parece domingo.
8:58 PM
Sep
9:47 PM
@gbianchi Lo del contrato en interfaces lo habia visto (es decir la forma de explicarlo),pero por ejemplo yo me pongo a organizar un UML, tengo mi clase abstracta de la cual heredan unas cuantas clases y tengo mis otras clases por ahi en el UML, yo no digo por ejemplo "metamos una interface por aca, no se... por q asi aplico las buenas practicas o por q me haga falta" osea por mi puedo hacerlo sin interface
y poder se puede... la cosa es capaz diferenciar y saber cuando tengo q usarlo,
segun las buenas practicas tengo q usar interface para q el proyecto pueda ser expansible en el tiempo y que puede hacer q otras clases apliquen el contrato sin tocar nada de codigo, AHORA tambien podria hacerlo quizas con una clase abstracta.Me cuesta ver eso de decir aca una interface o aca solo necesito una clase abstracta, la clases abstractas creo q son mas intuitivas por los atributos y la jerarquia q podrian llegar a tener, ahi es un poco mas facil, pero la interface lo veo como algo parecido...PERO difer
10:09 PM
@Shiki Pero entiendes la diferencia entra una y otra?
@Yussef en lo teorico diria que si, pero en lo practico diria q no, por que nunca me digo" hey aca va una interface".
@Shiki Es que se usan para muchas cosas y todo depende del proyecto. Por ejemplo tu tienes Factura y Boleta, ambos son tipos de documentos que comparten elementos comunes. Tu puedes decidir crear una clase padre "Documento" y que ambas hereden de él
Pero pasa que Documento no es algo del negocio, no existe como tal. Es algo abstracto, entonces la conviertes en clase abstracta, porque en tu modelo no necesita una instancia sola del padre
te leo
El punto es que tu podrías crear una clase normal y decidir no instanciarla nunca y funcionaria igual. Por eso para mi la clase abstracta es un impedimento hacia el equipo de trabajo, igual que cuando haces una propiedad privada
impides que otro compañero de trabajo haga mal uso de tus componentes
Por otro lado las interfaces son otra cosa, es un contrato. Provee una forma de tratar objetos de distintos tipos como si fueran lo mismo
y transcienden la POO
La POO y en específico la herencia es criticada no por pocos, no así la interfaces
Y la respuesta a tu pregunta, de sobre cuando ocupar lo uno u lo otro, es como casi todo en programación, depende del caso. No existe libro de receta
aver
te digo un ejemplo y me decis si va va masomenos asi
10:23 PM
ok
tengo la clase abstracta auto y tengo muchos autos, pero tambien tengo la clase abstracta bote y tengo muchos botes que heredan, tanto auto como boto tienen un unico metodo llamado "combustible" q lo unico que hace es decirme el combustible que queda. Entonces me un nuevo
tipo de bote, digamos... una lancha, por la semantica tendria q hacerla heredar de bote, para
q me pueda decir el combustible o bien podria quitar auto y bote para implementar una interface que les de el contrato de combustible, asi si despues llega otro medio de transporte como ser un avion solo aplica la interface sin importar la semantica.
@Yussef ahi?
mmm es que depende, porque en la práctica nunca es tan simple. Por ejemplo un motor también tiene combustible y no es medio de transporte. Y una bicicleta es un medio de transporte pero no una combustible
entonces en estos casos es mejor usar una interface
para que abarque cualquier posible elemento q pueda llegar?
osea mas "generico" decis?
claro
ok creo q entendi
entonces algo q este por encima de la semantica que les de un contrato q necesiten.
gracias eh fue bueno tu ejemplo
10:34 PM
Es que debes entender que la herencia soluciona problemas y crea otros, en general hay que usarla con cuidado (las abstractas y las normales), porque te atan a un modelo que luego es difícil cambiar
no así las interfaces
ok
Entonces cuando existe una clara e innegable vinculación entre padre-hijo usas herencia y solo ahí
el ejemploq di no estaba tan mal orientado no?
si era bueno
mira yo una vez hice un juego RPG, la herencia era una maravilla, una clase abstracta Item, luego tenias Armas, Armadura, etc que heredaban
y todo perfecto
Pero nunca he sido capaz de replicar ese modelo en un sistema empresarial. Porque la vida real es mas compleja, requerimiento tontos, flujos extraños y al final muchas cosas que carecen de una lógica
Ahi lo mejor no es ocupar herencia, porque da más problemas
hasta con una familia de enemigos?
10:40 PM
@Shiki Como?? no etendí
claro como dijiste que habias aplicado herencia en un RPG pense en el ejemplo de la herencia de enemigos
donde tenes nose... Enemigo que tiene el atributo nose.. HP
y de ahi heredan todos
hasta eso esta mal?
@Shiki No es que esté mal, lo que trato de decirte es que tu modelas tu software y por ejemplo en un juego hecho por ti está todo muy claro, es fácil de modelar y llevar todo a POO
Pero cuando haces una aplicacion para otro, por ejemplo en el ambito empresarial, los requerimientos no son tan claros, y siempre sale algo que rompe el modelo que habias creado en el inicio
ahhhh
Al usar herencia, cualquier cambio impacta mucho, no así con las interfaces
ahi entendi
10:46 PM
Bueno esa es la principal diferencia PRACTICA con que yo me he encontrado
Si me sirvio el ejemplo gracias!!

« first day (2701 days earlier)      last day (490 days later) »