Los protestos de letras, cheques y pagarés se pueden aclarar directamente en el Boletin Comercial, una vez pagada la deuda, y normalmente se aclaran a la semana siguiente.

cuanto tiempo se demora en sacarte del boletin por un protesto judicial, es verdad que demora seis menos o puede demorar un poco menos si uno va a la camara de comercio a aclarar la deuda

hola mi consulta es la siguiente que pasa CON LA GENTE QUE A TENIDO UN PROTESTO CUANTO TIEMPO SE demora en sacarte del sistema ,es verdad si se demora sesis meses o tengo quie ir a la camara de comercio para aclararla gracias.

Ahora Tama plantea que el arte es un vínculo al sentido de lo estético, el arte trasciende, va más allá y una de las dimensiones es lo estético. Pero lo estético no es la esencia del arte.
De hecho el artículo pretende ir en la línea que la naturaleza del software es un arte en el sentido de trascender en las posibilidades del hombre: Conciencia, Medios, Posibilidades, Desarrollo, Capacidades, etc.
y el artículo va en la línea de darle otro sentido a la programación como arte, de sacar la visión del creador y ponerse en la posición de trascender.

En ese trascender me parece que si es clave lo que señala el pepe, las abstracciones válidas hoy, no lo serán mañana, o las que en definitiva creo que son la realidad presente, ni siquiera lo son.

Lo de controlar la complejidad coincido en que se debe comprender, pero esa comprensión es controlada en el sentido que para comprenderla creamos abstracciones. En definitiva acotamos la realidad, le quitamos complejidad. Pero coincido en que el controlar puede ser visto como una comprensión.

La definición que más me gusta de "software" es "comprensión congelada/solidificada de los actuares sobre un problema" (mejor en inglés, "frozen understanding of the actions upon a problem"). La comprensión es siempre relativa al programador/diseñador/ingeniero. Casi siempre es posible una mejor comprensión de un problema. Los problemas complejos nunca tienen una única solución (a veces ninguna).

No me parece que OO sea "la peor tragedia". Es un lente, una herramienta. Te puede hacer ciego a algunas cosas, pero es el precio que pagas por poder observar más lejos, más rápido o más cosas (o la misma cantidad de cosas por menos plata). Como todas las herramientas, tiene una curva de aprendizaje peculiar, y si no sabes cómo ocuparla hará tu trabajo más difícil que sin ella. Pero no por eso deberíamos desecharla definitivamente para buscar otras herramientas.

Supongo que con los años me he vuelto más mañoso con las definiciones de libro, pero no me gusta pensar en el software como un arte (imitación de la naturaleza, búsqueda de la belleza, etc., y por tanto fuertemente vinculada al sentido estético). Sí es una artesanía ("craft"). Se aprende en el taller transmitida de maestro a discípulo. Es un actuar esencialmente práctico. Es como andar en bicicleta: la sola idea de tener una clase teórica sobre aprender a andar en bicicleta suena absurda. Mejoras con la práctica y mirando hacer a otros.

¿Controlar la complejidad...? Para mí, más bien "comprender suficientemente la complejidad".

Lo que pasa que la OOP tradicional hace mapas estáticos de las entidades que analiza.
Los modelos dinámicos (en UML o en modelamiento de procesos) asumen una estructura estatica del modelo, son orquestaciones y coreografias sobre actores que se asumen se quedan quietos.

La idea de Pepe es que los objetos/entidades tambien deben modelarse asumiendo que cambiarán, que sólo hemos modelado una visión inicial.
Las clases y su mapeo a tablas son rígidas.

En eso estoy de acuerdo con Pepe, la OOP y el modelo relacional son los grandes causantes de la complejidad del software.
Donde no estoy convencido es si el EIDOX es la solución (puede que el problema sea la implementación).

Solo agregaría que los verdaderos programadores no modelan la realidad, solo modelan las abstracciones ligadas a sus propias observaciones ...

La Orientación a Objetos es la peor tragedia del programador, ese que se autoengaña con distinciones que le hacen creer que su mapa es el territorio. Si las distinciones que establece son inadecuadas el software, que se genera a si mismo en cada momento, en un instante se hará insotenible y muere: ¡¡horror, es mejor partir de cero nuevamente!!!.

Solo un programador que entiende que modela su propia entelequia, descubrirá que detrás de las formas que devela, solo hay formas develadas y que por tanto las nuevas formas develadas necesariamente estarán contenidas en las formas anteriores.

IMHO el Eidox acuñado por ciempíricos chilenos a principios de este siglo, del griego Eidos: forma o idea, X: XML = formas en XML, es la única forma inmortal: se limita a registrar las observaciones de cualquier de observador sin pretender que estas formas representan la realidad: solo representan el registro de la reflexión de un observador de observadores, el programador, buen o mal observador como cualquier otro ;-).

Esta buena la pelicula es muy interesante como estos genios en hardware y software logran sus metas.
Yataco

y vive con cristo en un mundo mejor que este ¡¡¡¡¡

Pero yo no veo nada de malo en limpiar el texto de sus traducciones tendenciosas o antojadizas. Me parece notable que se ponga en cuestionamiento el lenguaje moderno utilizado para presentar los textos. Lo que sí me parece un tema para discutir ignorancia es la emocion que causa esta moda que hay con respecto a la Biblia. Mucha gente siente una desesperada necesidad de que alguien "pruebe" que todo el texto no se trata más que de una farsa. Pero para plantear eso se necesita mucho más que una lectura dominguera.

Los textos que tanto parecen molestarle a algunos no sufren mucho cuestionamiento real de parte de la historiografía, aunque le cambien un sinónimo por otro que pueda sonar mas amigable a un partido politico o grupo social. Para algo existe una ciencia totalmente apolitica y a-religiosa llamada Exégesis. Las cosas, discutidas en ese terreno, son de interés universal y no va a ser una payasada norteamericana más la que ponga en crisis el conocimiento de toda una raza.

Es algo impresionante, habría que saber si la iglesia de norteamerica tiene conocimiento de esto, pero de que los norteamericanos (no hago referencia a todos, aclaro) cada vez están mas locos, parece que lo están... y no es que uno lo diga, dan pauta para decirlo.

La Conservapedia es un gran chiste. En serio, es muy chistosa. Sólo podría haber salido de Estados Unidos.

Gracias Germán vamos a leerlo, Paul Graham tiene varios apuntes muy interesantes.

Quizás te guste el libro "Hackers and Painters"
Y aquí un enlace a un artículo relacionado.
http://www.paulgraham.com/hp.html

Saludos

Muchos de los problemas que tu mencionas exhiben un comportamiento de paralelismo escalable. Es la base de mucho de los computos en grilla, o el fundamento de procesamiento en granjas.
De hecho hay problemas muy complejos que son vergonzosamente paralelizables: http://en.wikipedia.org/wiki/Embarrassingly_parallel.

En estos casos la paralelización puede automatizarse, o es sencilla implementarla.
Los problemas más interesante vienen cuando tenemos lo que los expertos llaman mayores o menores grados de granularidad paralela. De eso pretendo hablar en la tercera parte.

Gracias por tu aporte (cuyo valor es mucho mayor a los 2 centavos de dolar).

Como te comentaba en tu post anterior, existen muchísimos casos en que la paralelización más básica es un tremendo avance. Tomemos el caso de las matrices

"Estos problemas se dan mucho en la física, o en cálculos matemáticos sobre matrices y vectores."

Lo anterior es cierto, mas no completamente: Existen una miríada de problemas de matrices u otras estructuras que son perfectamente paralelizables: desde PageRank, pasando por clustering de redes sociales, redes neuronales para aprendizaje, algoritmos genéticos y muchos otros... En general cuando tienes que computar algo "para todos los valores de 1 a N" en muchos casos paralelizar si mejora sustancialmente los tiempos de respuesta.

Mis 0,02 USD

Etienne.
Actualmente en mi trabajo trabajo sobre arquitectura java, aunque estoy explorando el lenguaje Scala y su framework lift, que funcionan sobre la misma jvm.
Es un lenguaje muy poderoso e interesante.
De hecho el creador de groovy ha dicho que de haber conocido antes a Scala no habría hecho nada.
Grails se ve muy interesante, pero no lo he probado, vamos a hecharle un vistazo.
Gracias por el comentario

Estoy totalmente de acuerdo con lo que indicas y to depende del contexto.

hoy en dia se nos pide ser mas prodcutivos y a la vez con calidad (estabilidad , rapides y capacidad). Y lenguajes como JAVA o .NET agregan un overhead a la productividad, lo cual te puede jugar en contra.

Al contratio de tu preferencia, a mi por un tema de gusto, prefiero JAVA y hace poco encontre un framework que apunta mucho a lo que se refiere tu articulo.

El framework es www.grails.org (Groovy and Grails), que trabaja con el lenguaje Groovy y por debajo el compilado es un bytecode de java. Trabaja sobre la filosofía de convención sobre la configuración y un patron MVC, pero lo más destacable es su ORM llamado GORM es una delicia crear las clases de dominio.

Lo has probado ??? yo lo he usado en un par de proyectos y me ha resultado muy agil y productivo.

Es totalmente recomendable para la gente que viene principalmente del mundo JAVA

Saludos