Blockly es un lenguaje de programación gráfico experimental en línea. Los usuarios pueden arrastrar los bloques juntos para construir una aplicación. No es necesario usar el teclado.
#3:
Pronostico que algún friki en poco tiempo utilizará esta aplicación para programar un coprocesador matemático de 64 bits con una interfaz de conexión con el Duke Nukem 3D y el Halo.
De forma que desde esos motores de render se pueda calcular una raíz cuadrada desde una calculadora que se encuentra en un rincón oculto del mapa 3.
Youtube ya ha reservado el espacio para cuando suban el vídeo al respecto.
#29:
¿Lo he hecho bien, sr. profesor de Fundamentos de Programación I?
#7:
Estas cosas están guapísimas. Son las cosas que yo enseñaría a mis alumnos de la ESO si me dejaran dar informática (y no word-excel-tuenti-messenger)
#9:
Seguramente no sea la solución óptima, pero ahí va
#4:
#3 No lo dirás por aquel que se hizo un decodificador BCD con el minecraft, no?
#30:
#9#21 Aqui la mía, sin llegar con la cara amoratada de golpear paredes...
#14:
Y también está Snap (http://byob.berkeley.edu/#snap4.0), que es Scratch (en realidad una versión aumentada, llamada BYOB, http://byob.berkeley.edu/, que se usa en primero de Informática en Berkeley) re-implementado en JavaScript. Por cierto, #8, lo único que exige plugins Java en Scratch es su ejecución en navegadores. Scratch es una aplicación de escritorio que no requiere Java para nada. Está implementado en Smalltalk.
#10:
#7 A nosotros nos intentaron enseñar Logo en la ESO, pero la mayoría de la gente no lo entendía y le costaba (y eso que solo era mover a la tortuguita con ordenes precisas, nada más de programación). La gente no está preparada para estas cosas de programación, al no ser que le guste la informática
(yo fui de los pocos que entendí bien el Logo, y luego acabé estudiando Informática...)
Pronostico que algún friki en poco tiempo utilizará esta aplicación para programar un coprocesador matemático de 64 bits con una interfaz de conexión con el Duke Nukem 3D y el Halo.
De forma que desde esos motores de render se pueda calcular una raíz cuadrada desde una calculadora que se encuentra en un rincón oculto del mapa 3.
Youtube ya ha reservado el espacio para cuando suban el vídeo al respecto.
#60 Sí, sí, pero el mío no necesita andar chocando con las paredes, y el camino es siempre el óptimo, el más corto y rápido.
Fuera de clase, en el mundo real, a veces la solución óptima a sumar dos y dos no es "return a + b" sino "return 4". Sólo la experiencia te enseña a encontrar el balance entre eficiencia y mantenibilidad adecuado para cada caso.
#63 Depende. A veces la solución óptima es la más eficiente, a veces es la más mantenible. Generalmente la extensión del código tiene poco o nada que ver.
#64Fuera de clase, en el mundo real, a veces la solución óptima a sumar dos y dos no es "return a + b" sino "return 4". Sólo la experiencia te enseña a encontrar el balance entre eficiencia y mantenibilidad adecuado para cada caso.
En un lenguaje referencialmente transparente esa decisión es totalmente innecesaria. Por desgracia, hoy en día la mayoría de las empresas siguen usando lenguajes imperativos.
#95 Lo cual no tiene nada que ver con mi comentario, pero en fin.
Ya me dirás cómo ves tú la decisión innecesaria dependiendo de la transparencia referencial, cuando la decisión depende ÚNICAMENTE de requerimientos de eficiencia y mantenibilidad, y no de la expresividad y estructuración del lenguaje usado. Es que ni remotamente tiene nada que ver una cosa con la otra, vamos.
De hecho yo hablaba de eficiencia y mantenibilidad y tú hablas llanamente de purismo de programador "pijeras". Vamos, churras y merinas. Pero nada, oye, imagino que la cuestión es meter cucharada aparentando que sabes mazo, aunque ni te dés cuenta de que lo que dices no tiene nada que ver con lo que respondes.
Y en numerosas ocasiones el purismo también te lo has de pasar por el forro en aras de la eficiencia. Pero ésa ya es otra película.
Cuando quieras, de paso, me dices un solo lenguaje funcional puro (o sea, referencialmente transparente al 100%) que sirva para algo más que para hacer cálculos, o hacer "scripting" sencillote, o simplemente para hacer "reporting". Porque PARA IMPLEMENTAR PROCESOS Y ESTADOS NO SIRVEN, listillo, PARA ESO SE NECESITAN VARIABLES Y ESTRUCTURAS. A ver si te crees que es por capricho que no se usan.
Mucho purismo y ni idea tienes de qué hablas, macho. Pero nada, tú suéltalo, que lo has dado en clase y a los legos les suena supermegachachitecnificado. A lo mejor hasta quedas bien ante alguien que no tenga ni puñetera idea (lástima que vas a quedar como un cromo ante todos los que sí).
A los que no habéis salido del huevo se os nota cosa mala, "jomío".
#99 ¿Lo cualo? En un lenguaje referencialmente transparente, si a + b = 4, entonces return (a + b) = return 4. Luego no hay ninguna decisión que tomar. Hasta un niño de 5 años lo entendería. Pero por tu forma de hablar y tus conocimientos, parece que todavía no eres tan mayor.
¿Un lenguaje puro que sirva para algo? Por ejemplo, Haskell.
#96 Anda, yo creía que el algoritmo consistía en ir siempre a la derecha.
Ya en serio, te remito a mi comentario #64. Es posible que en algunos casos la solución más eficiente sea la óptima, en detrimento de la más mantenible.
#75 nope! no es igual! Ya lo estaba haciendo antes de ver la tuya que conste... La diferencia de orden en el caminar y girar, provoca que el mío de al menos un paso menos que el tuyo!
en este tipo de cosas se puede aplicar el principio de solución básico de laberintos, siempre ir a la izquierda para llegar al otro lado del laberinto.
#96 Técnicamente es la solución óptima para el laberinto que se plantea, ya que lo resuelve en un número mínimo de pasos. Cualquier otro algoritmo llegará a la casilla de finalización del laberinto en un número de pasos sub-óptimo.
Otra cosa es que esa solución sea versátil, y funcione adecuadamente en un laberinto distinto por eso puse el icono del troleo en el post
Y también está Snap (http://byob.berkeley.edu/#snap4.0), que es Scratch (en realidad una versión aumentada, llamada BYOB, http://byob.berkeley.edu/, que se usa en primero de Informática en Berkeley) re-implementado en JavaScript. Por cierto, #8, lo único que exige plugins Java en Scratch es su ejecución en navegadores. Scratch es una aplicación de escritorio que no requiere Java para nada. Está implementado en Smalltalk.
#9 Me retracto con mi comentario #49, no se puede comparar tu solución general con backtracking a una solución específica que solo sirve para este problema.
#7 A nosotros nos intentaron enseñar Logo en la ESO, pero la mayoría de la gente no lo entendía y le costaba (y eso que solo era mover a la tortuguita con ordenes precisas, nada más de programación). La gente no está preparada para estas cosas de programación, al no ser que le guste la informática
(yo fui de los pocos que entendí bien el Logo, y luego acabé estudiando Informática...)
#10 El logo me encantaba pero vamos en mis tiempos (y supongo que en los tuyos, porque ya creo que apenas se usa en la enseñanza) era algo aun un poco árido, eso si, como lenguaje es genial para aprendizaje pero este lo veo aún mas visual y bonito, he estado trasteando también con el maze y es divertido
#10 que recuerdos con el LOGO... me lo pasaba bomba con la tortuga y para aprender conceptos como recursividad estaba muy bien. Ademas se podia traducir a diferentes idiomas (lo usabamos en euskera)
#10 ¿En la ESO? Nosotros dimos LOGO en primaria, con cacharros bajo MS-DOS. Por cierto, la solución más optima es la que menos instrucciones tiene que manejar, que es la que manda al cacharro directamente en 5 líneas.
Al que le guste esta idea, recomiendo IMPURE (http://www.flickr.com/photos/53824152@N08/) producto patrio con el que se pueden realizar auténticas virguerías gráficas en el estudio de datos. Otra recomendación, aunque no sea un lenguaje gráfico como tal y se trate de una forma de programación visual, es SIKULI(http://sikuli.org/) con el que se pueden hacer scripts para automatizar tareas del PC.
#47 Pues sí, hasta las narices del supuesto "invento" de la programación visual. No es ningún concepto nuevo, hace muchos años que se habla de herramientas así, y de hecho ha habido varias en el mercado (el XI/PI de SAP, por ejemplo, se programa con cosas parecidas). Al final, sólo sirven para hacer demos o pequeños programas de ejemplo. En el mundo real sirven más bien de poco, y apenas aportan nada. Eso sí, cuando las ves por primera vez te quedas muy sorprendido.
Así es como se crean las aplicaciones en el app inventor http://beta.appinventor.mit.edu Hay que reconocer que es bastante intuitivo y si te pones a ello en unas horas aprendes los comandos mas básicos. También hay bastantes tutoriales en línea.
Los entornos de programación y en especial los Rapid application development (RAD) animan a cualquier "tuercebotas" a definirse como programador.
Aunque por otro lado alivian bastante la tediosa labor de picar código.
#86 Gracias por el enlace, parece que está hecho por un empleado de Google, pero no por el propio Google. No hay ningún anuncio oficial por parte de Google, o al menos no lo encuentro, por lo que no sé si se trata de un proyecto personal u oficial de Google. Los miembros del proyecto en Google Code tienen como email "gmail", mientras en los proyectos oficiales de Google los programadores suelen usar su cuenta de "google.com".
De momento me quedo a la espera de alguna confirmación en uno u otro sentido.
Joder, Menéame está lleno de informáticos. Ya que estamos: ¿alguien me dice cómo puedo aprender a programar por mi cuenta? ¿Un librito o un enlace a algún recurso? Es que me parece que lo que estoy estudiando no tiene futuro...
Aparte de una vistosa prueba de concepto (como gran parte de los juguetes inútiles que de tanto en tanto publica Google), me parece un invento genial para que los niños aprendan los fundamentos de la programación estructurada.
A mi que sea visual me da igual. Lo importante es que agrupe en bloques operaciones de bajo nivel
A mi me parece buena idea para determinados dispositivos.
Si mi móvil tuviese un lenguaje de programación basado en bloques con instrucciones "bloquear [usuario]", "reenviar [usuario]" , etc etc , no tendría que aprender Android, ni Objective C ni nada
En mi opinión, el problema de estos lenguajes es que siguen orientando el flujo de aplicación en vertical (de arriba a abajo), cuando este tipo de sistemas ofrecen muchas más posibilidades: flujos basados en grafos (como en muchos de los editores de shaders actuales[1]), diferentes niveles de complejidad (como en los gráficos de burbujas que veíamos en Ingeniería del Software), comentarios separados del código, etc.
Comentarios
Pronostico que algún friki en poco tiempo utilizará esta aplicación para programar un coprocesador matemático de 64 bits con una interfaz de conexión con el Duke Nukem 3D y el Halo.
De forma que desde esos motores de render se pueda calcular una raíz cuadrada desde una calculadora que se encuentra en un rincón oculto del mapa 3.
Youtube ya ha reservado el espacio para cuando suban el vídeo al respecto.
#3 No lo dirás por aquel que se hizo un decodificador BCD con el minecraft, no?
#3 Ostrás... qué buena idea. Me pongo a ello.
#3 Me quito el sombrero ante tus habilidades clarividentes.
¿Lo he hecho bien, sr. profesor de Fundamentos de Programación I?
#29
#9 #21 #28 #29 #30 #41 #49 #55 #58
#59 Horrible.
#60 Sí, sí, pero el mío no necesita andar chocando con las paredes, y el camino es siempre el óptimo, el más corto y rápido.
Fuera de clase, en el mundo real, a veces la solución óptima a sumar dos y dos no es "return a + b" sino "return 4". Sólo la experiencia te enseña a encontrar el balance entre eficiencia y mantenibilidad adecuado para cada caso.
#63 Depende. A veces la solución óptima es la más eficiente, a veces es la más mantenible. Generalmente la extensión del código tiene poco o nada que ver.
#64 Fuera de clase, en el mundo real, a veces la solución óptima a sumar dos y dos no es "return a + b" sino "return 4". Sólo la experiencia te enseña a encontrar el balance entre eficiencia y mantenibilidad adecuado para cada caso.
En un lenguaje referencialmente transparente esa decisión es totalmente innecesaria. Por desgracia, hoy en día la mayoría de las empresas siguen usando lenguajes imperativos.
#95 Lo cual no tiene nada que ver con mi comentario, pero en fin.
Ya me dirás cómo ves tú la decisión innecesaria dependiendo de la transparencia referencial, cuando la decisión depende ÚNICAMENTE de requerimientos de eficiencia y mantenibilidad, y no de la expresividad y estructuración del lenguaje usado. Es que ni remotamente tiene nada que ver una cosa con la otra, vamos.
De hecho yo hablaba de eficiencia y mantenibilidad y tú hablas llanamente de purismo de programador "pijeras". Vamos, churras y merinas. Pero nada, oye, imagino que la cuestión es meter cucharada aparentando que sabes mazo, aunque ni te dés cuenta de que lo que dices no tiene nada que ver con lo que respondes.
Y en numerosas ocasiones el purismo también te lo has de pasar por el forro en aras de la eficiencia. Pero ésa ya es otra película.
Cuando quieras, de paso, me dices un solo lenguaje funcional puro (o sea, referencialmente transparente al 100%) que sirva para algo más que para hacer cálculos, o hacer "scripting" sencillote, o simplemente para hacer "reporting". Porque PARA IMPLEMENTAR PROCESOS Y ESTADOS NO SIRVEN, listillo, PARA ESO SE NECESITAN VARIABLES Y ESTRUCTURAS. A ver si te crees que es por capricho que no se usan.
Mucho purismo y ni idea tienes de qué hablas, macho. Pero nada, tú suéltalo, que lo has dado en clase y a los legos les suena supermegachachitecnificado. A lo mejor hasta quedas bien ante alguien que no tenga ni puñetera idea (lástima que vas a quedar como un cromo ante todos los que sí).
A los que no habéis salido del huevo se os nota cosa mala, "jomío".
#99 ¿Lo cualo? En un lenguaje referencialmente transparente, si a + b = 4, entonces return (a + b) = return 4. Luego no hay ninguna decisión que tomar. Hasta un niño de 5 años lo entendería. Pero por tu forma de hablar y tus conocimientos, parece que todavía no eres tan mayor.
¿Un lenguaje puro que sirva para algo? Por ejemplo, Haskell.
PARA IMPLEMENTAR PROCESOS Y ESTADOS NO SIRVEN
Dios, cuánta incultura
#96 Anda, yo creía que el algoritmo consistía en ir siempre a la derecha.
Ya en serio, te remito a mi comentario #64. Es posible que en algunos casos la solución más eficiente sea la óptima, en detrimento de la más mantenible.
#29 y #59 epic win
#59 #9 #21 #28 #29 #30 #41 #49 #55 #58 et Al...
Aquí va el mio! Un poco tonto, pero menos lineas!
#70 bandarra, es el mismo que había hecho yo!
#75 nope! no es igual! Ya lo estaba haciendo antes de ver la tuya que conste... La diferencia de orden en el caminar y girar, provoca que el mío de al menos un paso menos que el tuyo!
#76 eso es cierto, maldito
#59 Fue lo primero que hice y luego lo simplifique
#92 GOTO #29,#59
Broma vieja. Llegas tarde.
#29 If it works, don't fix it.
#29 técnicamente lo hiciste mal, es código duro.
en este tipo de cosas se puede aplicar el principio de solución básico de laberintos, siempre ir a la izquierda para llegar al otro lado del laberinto.
#96 Técnicamente es la solución óptima para el laberinto que se plantea, ya que lo resuelve en un número mínimo de pasos. Cualquier otro algoritmo llegará a la casilla de finalización del laberinto en un número de pasos sub-óptimo.
Otra cosa es que esa solución sea versátil, y funcione adecuadamente en un laberinto distinto por eso puse el icono del troleo en el post
Novedad, novedad, no es. Tenemos scratch http://scratch.mit.edu/
#6 No, pero Scratch exige un anacrónico plugin de java que da más fallos que una escopeta de feria.
Y también está Snap (http://byob.berkeley.edu/#snap4.0), que es Scratch (en realidad una versión aumentada, llamada BYOB, http://byob.berkeley.edu/, que se usa en primero de Informática en Berkeley) re-implementado en JavaScript. Por cierto, #8, lo único que exige plugins Java en Scratch es su ejecución en navegadores. Scratch es una aplicación de escritorio que no requiere Java para nada. Está implementado en Smalltalk.
Seguramente no sea la solución óptima, pero ahí va
#9 A mi me salió esta que es mas cutre y fea aún.
#9 #21 Aqui la mía, sin llegar con la cara amoratada de golpear paredes...
#9 A mi piloto no le gusta darse con las paredes así que ha decidido tirar por la vía rápida.
#9 Creo que esta versión es más sencilla, y por tanto de más fácil mantenimiento
#9 Me retracto con mi comentario #49, no se puede comparar tu solución general con backtracking a una solución específica que solo sirve para este problema.
Estas cosas están guapísimas. Son las cosas que yo enseñaría a mis alumnos de la ESO si me dejaran dar informática (y no
word-excel-tuenti-messenger)#7 A nosotros nos intentaron enseñar Logo en la ESO, pero la mayoría de la gente no lo entendía y le costaba (y eso que solo era mover a la tortuguita con ordenes precisas, nada más de programación). La gente no está preparada para estas cosas de programación, al no ser que le guste la informática
(yo fui de los pocos que entendí bien el Logo, y luego acabé estudiando Informática...)
#10 El logo me encantaba pero vamos en mis tiempos (y supongo que en los tuyos, porque ya creo que apenas se usa en la enseñanza) era algo aun un poco árido, eso si, como lenguaje es genial para aprendizaje pero este lo veo aún mas visual y bonito, he estado trasteando también con el maze y es divertido
#10 que recuerdos con el LOGO... me lo pasaba bomba con la tortuga y para aprender conceptos como recursividad estaba muy bien. Ademas se podia traducir a diferentes idiomas (lo usabamos en euskera)
#10 Qué recuerdos.
A mí me lo enseñó de pequeño mi padre (era profesor en una universidad) y siempre me decía que lo entendía yo mejor y más rápido que sus alumnos.
#10 ¿En la ESO? Nosotros dimos LOGO en primaria, con cacharros bajo MS-DOS. Por cierto, la solución más optima es la que menos instrucciones tiene que manejar, que es la que manda al cacharro directamente en 5 líneas.
#7 Yo he tenido suerte con mi profe de la ESO de informática, jeje, que bien me lo pasé con el Gambas 2!!!
Una demo muy chula: http://blockly-demo.appspot.com/blockly/demos/maze/index.html
Llevo un ratito trasteando
#2 resuelto en tres minutos
#2 Pues a mí no me sale, no encuentro el comando "destroy_walls_with_kamehame"
Ya vale
Raúl selección.
Está bien, pero no es muy original. Scratch (http://scratch.mit.edu) hace cinco años que existe. En él se basó el appinventor para Android.
Al que le guste esta idea, recomiendo IMPURE (http://www.flickr.com/photos/53824152@N08/) producto patrio con el que se pueden realizar auténticas virguerías gráficas en el estudio de datos. Otra recomendación, aunque no sea un lenguaje gráfico como tal y se trate de una forma de programación visual, es SIKULI(http://sikuli.org/) con el que se pueden hacer scripts para automatizar tareas del PC.
Está bien logrado y la demo es divertida. Ahí va mi solución (un poco más compacta que algunas que habeis colgado, creo).
#79 repetido de #58 ... DESPEDIDO!
#80 relacionada El juez del pleito de Oracle contra Google es un programador [ENG]
El juez del pleito de Oracle contra Google es un p...
i-programmer.infoOdio la puta programación visual ¡Qué arda en la hoguera!
Y si os gusta es que nunca habeis hecho un taskflow de ADF.
#47 Pues sí, hasta las narices del supuesto "invento" de la programación visual. No es ningún concepto nuevo, hace muchos años que se habla de herramientas así, y de hecho ha habido varias en el mercado (el XI/PI de SAP, por ejemplo, se programa con cosas parecidas). Al final, sólo sirven para hacer demos o pequeños programas de ejemplo. En el mundo real sirven más bien de poco, y apenas aportan nada. Eso sí, cuando las ves por primera vez te quedas muy sorprendido.
#66 Montar código haciéndolo visualmente es sólo un juguete (y además un coñazo). La programación visual es otra cosa.
#67 Montar código visualmente es sólo un tipo más de la programación visual, el más cutre e inútil de todos.
Así es como se crean las aplicaciones en el app inventor http://beta.appinventor.mit.edu Hay que reconocer que es bastante intuitivo y si te pones a ello en unas horas aprendes los comandos mas básicos. También hay bastantes tutoriales en línea.
Se puede usar en emacs?
#45 Vamos, vamos, vamos....
#86 No es de Google, es de un tipo que trabaja en Google que lo ha subido al repositorio de la compañía.
Los entornos de programación y en especial los Rapid application development (RAD) animan a cualquier "tuercebotas" a definirse como programador.
Aunque por otro lado alivian bastante la tediosa labor de picar código.
#25 Todo el que no programe directamente en ensamblador es un tuercebotas.
#25 Positivo por lo de "tuercebotas"
Qué guapo, he desactivado el modo de control remoto de marines:
#0, No es necesario usar el teclado.
acabo de hacer el michael Jackson...
(cómo me aburro, no?)
Una implementación:
La mia es mas grande
#0 Hay una errata en el título de la noticia: es "Blockly", no "Blocky".
Haber quien es el primero que hace un A*
#86 Gracias por el enlace, parece que está hecho por un empleado de Google, pero no por el propio Google. No hay ningún anuncio oficial por parte de Google, o al menos no lo encuentro, por lo que no sé si se trata de un proyecto personal u oficial de Google. Los miembros del proyecto en Google Code tienen como email "gmail", mientras en los proyectos oficiales de Google los programadores suelen usar su cuenta de "google.com".
De momento me quedo a la espera de alguna confirmación en uno u otro sentido.
#0 ¿Dónde pone que sea de Google? Google Code es un servicio de almacenamiento de software libre donde cualquiera puede almacenar ahí sus proyectos.
#85 http://www.wired.com/wiredenterprise/2012/06/google-blockly/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+wired%2Ftechbiz+%28Wired%3A+Tech+Biz%29
http://i.imgur.com/fbg53.jpg
La versión clásica de salir de un laberinto llevando la mano derecha pegada al muro (y por supuesto sin darse cabezazos):
Uf! No sé si me parece algo de mareo... Igual me animo a probarlo
Me ha recordado al software que te viene con Mindstorms de Lego:
http://www.edu365.cat/imagina/robots/lego_nxt/images_unitat5/image008.jpg
Pero es tan coñazo como parece, mejor utilizar Robotc:
http://4.bp.blogspot.com/_OuxwmaCATHk/TSrN2D6QKSI/AAAAAAAADV4/aHR3nupdq-0/s1600/1.png
Joder, Menéame está lleno de informáticos. Ya que estamos: ¿alguien me dice cómo puedo aprender a programar por mi cuenta? ¿Un librito o un enlace a algún recurso? Es que me parece que lo que estoy estudiando no tiene futuro...
Aparte de una vistosa prueba de concepto (como gran parte de los juguetes inútiles que de tanto en tanto publica Google), me parece un invento genial para que los niños aprendan los fundamentos de la programación estructurada.
Pues yo también subo mi versión, que manifiesta mi incapacidad para descubrir que se podía usar el 'else'
While es tu amigo! EL nesting es divertido!
A mi que sea visual me da igual. Lo importante es que agrupe en bloques operaciones de bajo nivel
A mi me parece buena idea para determinados dispositivos.
Si mi móvil tuviese un lenguaje de programación basado en bloques con instrucciones "bloquear [usuario]", "reenviar [usuario]" , etc etc , no tendría que aprender Android, ni Objective C ni nada
EL método de la mano izquierda funciona bastante bien.
Otra opción:
ainsss...
Yo me se de una compañía que va hacer el Agosto denunciando a Google por copiar-le la idea y el diseño.
http://thestencylblog.com/wp-content/uploads/2012/01/Stencyl-example-code-blocks.png
http://stencyl.com/
Ese lenguaje de programación es a la computación lo que los lego a la arquitectura.
Igual que App Inventor del MIT para hacer aplicaciones para Android
Han descubierto la pólvora... eso sí, en entorno Web...
http://www.techsupportalert.com/content/best-free-ways-learn-programming.htm
¿Conocéis LabView? Es genial =)
En mi opinión, el problema de estos lenguajes es que siguen orientando el flujo de aplicación en vertical (de arriba a abajo), cuando este tipo de sistemas ofrecen muchas más posibilidades: flujos basados en grafos (como en muchos de los editores de shaders actuales[1]), diferentes niveles de complejidad (como en los gráficos de burbujas que veíamos en Ingeniería del Software), comentarios separados del código, etc.
[1] http://idflood.github.com/ThreeNodes.js/public/index.html#example/postprocessing1.json
Yo lo he hecho a lo moonwalker!
Por cierto, ¿hay manera de que se agarre el paquete al final?
ya claro, pero si el laberinto tuviese bucles cerrados, no se podría resolver así
mmm....
¿Alguien juega al SpaceChem?
AS SEEN ON Idiocracia
No hay más demos???
Aquí el mío...va fino fino Catalino
pd: ahora no sé adjuntar una imagen
A ver: http://i.imgur.com/FMzyY.jpg
#33 Dale la vuelta y verás que bien
En esta, si es 'de izquierdas' llega a la meta, pero si es 'de derechas' acaba dando vueltas y jamás llega a la meta. Por algo será.
#28 si, por el bucle que hay arriba. Los bucles en los laberintos están para evitar usar las reglas de "mano derecha" o "mano izquierda"
#42 ya lo sé, era por tocar los huevos
Ahí va el mío
Hoygan que ya se programar!!