Discussió:Arcilla (L) (es)
De GERMINADOR wiki
|
participar en el Debate
|
Contingut |
[nou][edita][respon] reescribir hasta su base
--David 13 feb, 2006 (CET): Qué bueno, porque justamente había estado pensando en una idea así. Un programa que se pudiese reescribir hasta su base soportado por un CVS. El embrión de la idea era evidentmente lo que tu habías dicho varias veces de hacer un sistema donde el código no fuese algo intocable.Yo pensaba que la propuesta debería tener una parte "pedagógica" importante que permitiese de forma fácil a la gente aprender los rudimentos de la programación (eso recupera algunas ideas de Glocalia). Esta parte "pedagógica" también debería ser reeditable.
- --JaumeFerrer 15:43 14 feb, 2006 (CET): El reto es trabajar a un nivel tan primario que no sea necesario montar una superestructura, que lo que sea necesario aprender sea mínimo. La paradoja es que tradicionalmente las herramientas de autor han buscado la facilidad de programación precisamente simplificando la tarea al autor porque ya se encargaba el sistema de hacerla añadiendo lo que faltaba, es lo que hay detrás de los lenguajes de herramientas de autor, incluido processing. Creo que este camino es erróneo porque lleva a quedar en manos de quien crea el entorno de trabajo. La programación debería ser tan sencilla que no fuese necesario ningún otro sistema trabajando por debajo. Claro, siempre hay alguna cosa por debajo: el navegador, el sistema operativo... pero el objectivo podría estar en trabajar con el mínimo que se requiere para navegar, por ejemplo, con las herramientas estándar mínimas que ya tiene y conoce todo el mundo.
- --David 02:04 26 feb, 2006 (CET) No, creo que no entiendo por donde vas. Si no hay nada "por debajo" estamos en lenguaje máquina. Eso ni es fácil de aprender ni de usar ni permite hacer muchas cosas. Lo que es "poderoso" de la programación es el cambio de niveles, las "capas" que te permiten trabajar con otras capas pero como si no existieran. Si la "programación es tan sencilla" es que tiene alguna cosa "trabajando por debajo". Creo que el problema no está en la simplicidad o "naturalidad" del lenguaje. El problema es si éste es limitador y en qué medida podemos escapar de las limitaciones de algo que es una capa. Otra forma de verlo es preguntarse: Quién dice que el lenguaje máquina trabaja "por debajo"? Hacer algo con él pasa por una deconstrucción de nuestro propio lenguaje, los lenguajes de alto nivel hacen el camino a la inversa.
- --JaumeFerrer 20:03 26 feb, 2006 (CET) Como digo, por debajo siempre encontraremos el sistema operativo y el navegador (si pensamos en una aplicación en Internet). No es una cuestión de "naturalidad" sinó de propósito general y de familiaridad de acceso. El lenguaje siempre es un limitador en tanto que acota lo que es posible hacer y lo que no, pero hay una diferencia entre los lenguajes de propósito general y los que son específicos de un entorno de trabajo concreto. En los de propósito general la limitación pasa al programador, que tiene más margen de libertad pero a costa de trabajar más y de tener que saber más cosas, es una responsabilidad suya basada en conocimientos que no están ligados a una propuesta de trabajo concreta. Los lenguajes que son propios de un entorno concreto facilitan la tarea pero restringen más las cosas que se pueden hacer y acentúan la dependencia respecto a un entorno. En cualquier caso, la principal limitación que impone un lenguaje es que es necesario aprender a usarlo. Lo que propongo es un sistema donde todo el mundo pueda intervenir según sus posibilidades, la cuestión es fijar quien es todo el mundo y qué se entiende por una intervención. Internet sitúa el nivel básico universal en el navegador. Cualquier persona que usa Internet sabe como mínimo usar las funciones básicas de un navegador. Para mi éste es el punto de partida. Además, los navegadores muestran el código fuente de los documentos que cargan, esto pedagógicamente es importante. Una página hecha con HTML y que sea editable permite al usuario modificar su contenido y el formateado. Si esta página contiene código JavaScript además el usuario puede modificar su funcionamiento. Una aplicación donde todo el código estuviese en el propio documento, de manera que editarlo significase cambiar no sólo el contenido o el formateado sinó también la funcionalidad, ciertamente no podría ser demasiado compleja pero permitiría al usuario un elevado control sobre la experiencia. Un sistema así seguiría requiriendo una 'programación por debajo' que asegurase, como mínimo, que la página continuase sienddo reeditable. Esta programación implica en la parte del servidor, el uso de otras tecnologías, y escapa al control del usuario. Esto abre un interesante terreno de discusión sobre hasta dónde debería llegar el impulsor de una propuesta en sus imposiciones tecnológicas.
[nou][edita][respon] dudas taller
--David 13 feb, 2006 (CET): Creo que es una propuesta interesante que por su "radicalidad" se podría trabajar en el taller (aunque tengo dudas en cuanto a que nos situemos en un plano donde los asistentes no conecten).
- --JaumeFerrer 15:43 14 feb, 2006 (CET): Es un tema más cercano a un programador o a alguien que ya haya creado sus propias propuestas de creación colectiva, seguramente, pero en tanto que participantes cualquiera podría entrar en la discusión de los principios, que es tal vez la parte más interesante. De hecho, estaría bien que el TAG se dedicase a impulsar este debate sobre los aspectos básicos del tema y paralelamente lanzase una llamada a la comunidad artística/de desarrollo de software pidiéndole propuestas de entornos no lineales.
[nou][edita][respon] desacuerdo con el análisis de partida
--David 13 feb, 2006 (CET)
No estoy totalmente de acuerdo con el análisis de partida. Los proyectos que hemos visto sólo son "lineales" si los enfocas de cerca. Si abres el campo te das cuenta de que en el contexto de internet forman parte de una dinámica de apropiaciones y reapropiaciones.
- --JaumeFerrer 15:43 14 feb, 2006 (CET): Sí y no. En el contexto de internet y visto de forma general todo forma parte de una dinámica de apropiaciones y reapropiaciones porque Internet és así, esta vía sólo supone diferencias respecto a lo que no está en Internet, pero no ayuda a establecer distinciones dentro de la propia Internet. A la vez la apropiación es sólo relativa, porque hay una 'tradición' que es intocable por la mayoría de usuarios (empezando por el TCP/IP y siguiendo por la arquitectura de la propia red hasta las aplicaciones tipo navegador, servidor www, etc...). Esto no era así en los inicios, porque los usuarios eran los propios desarrolladores, esto es así después y consolida la distinción entre usuarios que pueden/se dedican a crear algunas herramientas y el resto de usuarios que no. Además, dado que ya hay muchas aplicaciones funcionando, la mayoría de creadores de herramientas sólo participan en la creación de alguna de las herramientas que usan, de manera que esencialmente todo el mundo es más usuario que creador de herramientas. Es decir, que a cerca de una aplicación tanto puedes afirmar que "en el contexto de internet forman parte de una dinámica de apropiaciones y reapropiaciones" como puedes decir que en el contexto de Internet la reapropiación es mínima y majoritáriamente somos usuarios bastante pasivos de sistemas creados por otros.
[nou][edita][respon] las "condiciones" son la "propuesta"
--David 13 feb, 2006 (CET): Crear un proyecto de este tipo ya implica en sí mismo plantear unas "condiciones". En realidad las "condiciones" son la "propuesta" en este tipo de proyecto. Si no construyes nada no hay nada y no hay propuesta.
- --JaumeFerrer 15:43 14 feb, 2006 (CET): La diferencia clave es precisamente que la condición inicial sea que esta condición inicial sea cambiada. Esto pasa en los juegos de los niños, que se ponen de acuerdo/se proponen jugar a algo y al cabo de un rato el juego ha evolucionado a base de innovaciones, interrupciones o distracciones hasta ser una actividad que puede que no tenga nada que ver pero que se sigue practicando conjuntamente. A nivel de interacción social está claro que sucede, el reto es que esto suceda cuando en medio hay una interfaz tecnológica que actúa de intermediaria y la otra cuestión es el contexto. Podemos encontrar ejemplos de dinámicas sociales que evolucionan hacia nuevas formas de actividad (dentro de asociaciones, grupos de amistades...) . Ahí no hablaríamos de herramientas sinó de estructuras sociales, pero una herramienta es eso. Para modificar lo que llamamos herramienta tropezamos con la barrera que imponen las habilidades tecnológicas necesarias para alterar un software y los privilegios para hacerlo pero para modificar una estructura social tropezamos con la barrera que supone modificar una tradición y las habilidades sociales y los canales de acceso a la toma de decisiones que también se requieren para hacerlo. Siempre habrá unas condiciones, pero éstas pueden estar planteadas de manera que el control pase a los participantes, control incluso para decidir cómo alterarlas durante el propio uso.
[nou][edita][respon] las condiciones de apropiación
--David 13 feb, 2006 (CET): Creo que en lo que trabaja un proyecto de este tipo es en contemplar las condiciones de apropiación; dando facilidades para que ésta sea posible; haciendo que la apropiación sea enriquecedora en los dos sentidos; proponiendo un modelo de apropiación que busca la toma de conciencia crítica respecto a la tecnologia y que promueve el control de la persona respecto a ésta.
- --JaumeFerrer 15:43 14 feb, 2006 (CET): Exacto.
[nou][edita][respon] prejuicios y modelos
--David 13 feb, 2006 (CET): Me parece que toda propuesta implica prejuicios y modelos por parte de quien la hace. La cuestión está en qué modelos.
- --JaumeFerrer 15:43 14 feb, 2006 (CET): Es necesario plantearse cuestiones muy básicas, entre ellas la propia idea de propuesta de actividad colectiva. ¿Qué prejuicios y modelos resultan más significativos si una propuesta se destina a la participación múltiple? ¿qué modelo hay detrás de una propuesta de cocreación, sobretodo cuando esta cocreación lo es de contenidos y no de la propia propuesta? ¿qué implica hablar de creación colectiva cuando ni la propusta de lo se debe hacer, ni las herramientas para hacerlo, ni el servidor donde van a parar los resultados han sido definidos colectivamente? ¿Los participantes son coautores o son 'curritos' que trabajan conjuntamente? ¿por qué se requiere la existencia de participantes?
[nou][edita][respon] arcilla
--David 02:12 26 feb, 2006 (CET) Me gusta la metáfora de la arcilla. Las metáforas a veces son limitadoras, nos impiden avanzar. Pero también nos "iluminan", nos dejan ver las cosas de otra manera. Sólo se trata de tener claro que son provisionales, forzarlas cuando sea necesario, abandonarlas si se considera conveniente, cambiar a otra metáfora para verlo de otra manera. La arcilla puede ser una buena metáfora para esta semilla que estamos modelando (¡¡ups! ¡¡espero no tener que hacer un molde de yeso!! ¡todavía recuerdo mis fracasos y el yeso desparramándose por el suelo del taller del Parchís con las semillas de Jep, Valera y Arola ! )

