#30 si sales de lenguajes troncales como Java, PHP y demás entenderás que sí.
De nuevo pongo como ejemplo Scala porque es perfecto: con el lenguaje en sí defines la arquitectura (el lenguaje es auto-ampliable por decirlo de alguna forma), así que SÍ.
#31 Pero por qué sacas escala? hablo de casos generales por supuesto, del 90% de desarrollos no del 0.01%
Y sí, te equivocas 
. Hablas como si fueras el experto y la repanocha macho, te queda mucha ingenieria del software por aprender ^^
Edit: por supuesto a mi también, pero parece que menos.
Por cierto, por ejemplo, para decidir la manera de acceder a una base de datos me la marcan los requisitos y no el lenguaje. De hecho la arquitectura debe ser más dependiente de los requisitos que del lenguaje, y a partir de ahí elegir el lenguaje que se acople a tus necesidades.
Es una locura decir "voy a usar este lenguaje" y hacer girar todo el proyecto en torno a ello.
#32 pues saco Scala porque es lo que estoy mirando ahora mismo y porque es el ejemplo perfecto de todo lo que digo, pero vamos, sustituye Scala por cualquier cosa que no sea C/Java/PHP y estamos en las mismas. Precisamente donde está el dinero es en ese 0.01% de desarrollos. Repito: arquitectar Java puede todo el mundo. Arquitectar Scala sin que salga una masa deforme de código a la larga viene siendo más complicado.
Tú también hablas como si fueras el experto y la repanocha y creo que ninguno de los dos lo somos. Y en efecto me queda mucha ingeniería del software por delante, pero ya he arquitectado varios proyectos (motores de videojuegos, un par de frameworks Java sobre OpenGL) y se va aprendiendo hombre 
El framework de OpenGL además pienso liberarlo en GPL así que me estoy tomando el diseño bastante en serio (y creo que de momento acertadamente, porque lo estoy usando y me está viniendo genial.)
Te falta un poquito de humildad con ese "parece que menos". ¿Tú que sabràs lo que sé y lo que no? Tendrás tu opinión y será discordante con la mía, pero eso no hace la mía menos válida. Ya van varias veces en el foro que opino y me tachas de creerme "experto" sólo por defender mi opinión (cuando obviamente ambos defendemos nuestras posiciones.) Sin embargo no he visto por tu parte ningún argumento aparte de "es un 0.01% de desarrollos" y "te crees experto y no lo eres". Que probablemente sepas más que yo y tengas más experiencia pero ARGUMENTA y así aprendo.
Joder, es que es como decir que sabes usar BD NoSQL porque has oído hablar de BD no-relacionales y alguien te ha comentado su uso. NADA sustituye el trabajo de campo porque NADA te hace comprender qué está pasando en realidad y sus ventajas/inconvenientes como trabajar con ello. Si crees de otra forma estás engañado o te crees que la orientación a objetos lo es todo. Si la gente piensa como tú, así salen los desarrollos en España xD
Es una locura decir "voy a usar este lenguaje" y hacer girar todo el proyecto en torno a ello
¿Y quién ha dicho lo contrario? Repito: son herramientas y cuantas más conozcas mejor porque más soluciones podrás usar llegado el momento. No estoy hablando sólo del lenguaje si no por ejemplo, ¿escojo un framework? ¿Cuál y por qué? Y esto... ¿cómo pretendes saberlo sin haber trabajado con los frameworks candidatos? ¿Leyendo su página principal donde te listan lo guay que es? ¿Mirando Wikipedia? ¿Googleando los nombres de varios frameworks a ver cuál tiene más resultados?
#33 ??? sin sentido, interpretas mis palabras como quieres.
Para ser experto o gurú en un lenguaje es dedicarte decadas a un lenguaje, y eso no hace que sepas diseñar una aplicación, ni que sepas que arquitectura software es la adecuada.
Deberías informarte de lo que significa cada cosa que digo, antes de poner en tela de juicio mis respuestas.
Por cierto ya que lo comentas, has "arquitectado"? joder como se deforma el lenguaje. Yo me he tenido que comer 2 proyectos ultimamente uno de escritorio y otro web, y para mediados de febrero presumiblemente empiece con otro a revisar requisitos y demás, pero no hombre, tu eres más que nadie ^^
#33 Es una locura decir "voy a usar este lenguaje" y hacer girar todo el proyecto en torno a ello
¿Y quién ha dicho lo contrario? Repito: son herramientas y cuantas más conozcas mejor porque más soluciones podrás usar llegado el momento. No estoy hablando sólo del lenguaje si no por ejemplo, ¿escojo un framework? ¿Cuál y por qué? Y esto... ¿cómo pretendes saberlo sin haber trabajado con los frameworks candidatos? ¿Leyendo su página principal donde te listan lo guay que es? ¿Mirando Wikipedia? ¿Googleando los nombres de varios frameworks a ver cuál tiene más resultados?
Claro, porque yo he dicho que desconoces las herramientas que vas a usar. Así me gusta, inventando. Tienes buena imaginación conservala.
#34 y tú deberías leer las 8 veces que he dicho que gurú era una hipérbole, pero mínimamente tienes que ser bueno.
Y sigues sin argumentar, sólo diciendo que lo que digo no tiene sentido o que soy tal o cual. ¿Qué es lo que digo que no tiene sentido?
Por cierto, ¿dónde puedo echar un vistazo a tus diseños? Por aprender y tal, ya que me llevas ventaja 
#35 puedes verlos en megaupload
PD: estás que enseño esa documentación publicamente, no gracias, además de que no solo no son proyectos 100% mios, puesto que interviene más gente.
#34 creo que estamos discutiendo por una cuestión semántica.
¿Qué es para ti "conocer"? Porque para mí conocer es que me llegue un tío y me diga "hey, existe este lenguaje y hace esto, esto y esto" y como mucho haberlo toqueteado un poco. Eso es conocer y con esos conocimientos no puedes arquitectar (o como le quieras llamar, me la suda la semántica/léxico, el lenguaje está para hablar y me has entendido de sobra )
PD: eres la puta hostia macho, no sabes discutir argumentando. Tiras mucho del ataque en plan Así me gusta, inventando y creo que ni siquiera te estás parando a leer qué quiero decir. Por mi parte zanjo el tema y evitaré discutir contigo porque nunca saco nada en claro 
Si "discuto" es porque pretendo aprender de la discusión (o al menos ver otro punto de vista) pero es que siempre vas tan rápido al ataque personal y al no tienes ni idea que da asquito.
#38 Para mi conocer es saber usarlo, no haber leído cuatro lineas en una wiki.
¿Cómo vas a recomendar usar algo en un proyecto que no sabes si va a funcionar?
De hecho en la mayoría de proyectos la dirección del mismo va a tomar la dirección en base a sus conocimientos (la mejor opción conocida) y no en base a la mejor elección posible, puesto que no puedes conocer todas las opciones.
En los proyectos serios no te la puedes jugar a "pues voy a probar con esto", eso lo dejas para tu casa cuando vuelvas.
Como digo conocer es saber usarlo, de ahí venía, no de ser experto ni especialista (gurú) en ello.
#41 sacas las cosas de quicio
#40 +1
Yo creo que no es necesario conocer al 100% un lenguaje para diseñar un plan de desarrollo, tan solo las limitaciones que tiene el mismo. Que esté más o menos optimizado a nivel de código es tarea del desarrollador.
#39 pues en efecto tenemos un concepto diferente de la palabra conocer. Si a mi me presentan a Juan, le conozco pero no sé nada sobre él. En #39 básicamente has dicho lo que yo quería decir en el resto de posts así que creo que discutíamos por nada.
#40 hombre, tienes razón, pero a veces no está tan clara la diferencia. No estoy hablando a nível de código ni nada de eso, pero por ejemplo conocer la implementación concreta de las colecciones puede ahorrar algún que otro disgusto y ahí el diseñador sí entra.
Por no hablar de que muchas veces los propios constructos del lenguaje entremezclan arquitectura y programación. Está claro que con OO+UML es sota, caballo y rey, pero a veces las cosas son más complicadas.
De nuevo pongo de ejemplo Scala. Imagina que quiero diseñar un sistema de Entidades para un videojuego. Imaginemos que ya tengo diseñado el sistema abstracto (entidades con propiedades, orientado a componentes+mensajes.) Ahora, ¿cómo lo implemento en Scala? En Java es sencillo, tienes cuatro cosas: clases, interfaces, atributos, métodos, paquetes y poco más.
En Scala las posibilidades se disparan: se puede usar el sistema de concurrencia+actores, puedes implementarlo al estilo clásico OO, puedes usar traits, puedes implementarlo como un constructo del lenguaje (usando currying), puedes implementar un sistema con callbacks a los mensajes... Hay MIL opciones soportadas por el propio lenguaje y todas "interactúan" con el diseño. ¡A eso me refiero! No puedes diseñar eficientemente si no conoces cómo funcionan todas las posibilidades y sus ventajas/inconvenientes. ¿Cómo llegar a conocer las posibilidades? Leyendo libros seguro que no.
Quizá no necesites conocer un 100% del lenguaje, pero... ¿un 70% quizá? (tomando el aprendizaje como una curva logarítimica )
añadiendo a lo que ha dicho #40 imagino #41 que sabrás que las elecciones en un proyecto se comparan con otras opciones y se defienden frente a esas, por lo que se hace un estudio de viabilidad con cada una, hasta llegar a una conclusión.
Ese estudio depende de quien esté al cargo obviamente, y en España se suele omitir ¬¬" y se tira por la via facil, java/c++ escritorio y java/php/asp en web
De verdad que iba a subir este hilo a las noticias porque parecía interesante, but then I took an arrow in the knee :-/, ¿por qué pasa esto en todos los hilos?, como el pifostio que se montó en el otro hilo porque unos dicen que javascript es un lenguaje de programación y otros que no.
#45 ya no hay por donde cogerlo, sigan por donde lo dejaron xD
#44 así somos xD A mí me gustan estas discusiones porque siempre algo se aprende, pero supongo que es fácil que deraileen en "tú eres un cacas", "lo eres tú" :/ IMHO la discusión es interesante de hecho, aunque se ha ido un poco de madre.
Por mi guay si limpias el hilo, pero supongo que salen los "mensaje ocultado por no cumplir las normas", una pena
los que se pelean se deseeeaaaan
pd: y encima son dos de los users que mejor me caen y son mis referentes
pd2: goku sabe hacer scripts que facilitan el aprendizaje de kamehamehas.
No es que tenga experiencia dirigiendo equipos de desarrollo, pero por el PFC, por IS1/IS2 y por algunos proyectos a nivel amateur, puedo decir (en mi opinión, ya digo que no tengo experiencia suficiente para hablar sentando cátedra) que el lenguaje de programación es tan solo una consideración que se tiene en cuenta en un momento concreto del plan de proyecto.
Tú tienes en mente lo que quieres desarrollar, tienes cómo quieres hacerlo, tienes el esquema de cómo quieres que funcione, sus flujos de información, sus posibles diagramas de clases, los módulos que lo forman, los sistemas de información, etc.
En base a todo eso, eliges un lenguaje de programación que se ajuste a tus necesidades teniendo en cuenta diferentes consideraciones. Eliges el lenguaje en base al proyecto, y no viceversa.
Para eso, no hace falta ser un gurú del lenguaje de programación que elijas.
Ejemplo personal: un proyecto web, de envergadura. Empiezo a diseñar un plan. Llego al punto de tener que elegir con qué lo voy a hacer. Me informo, veo diferentes posibilidades, benchmarks, opiniones, etc. Elijo Python.
Python lo había usado 3 veces en mi vida, pero sabía que era la opción correcta para ese proyecto (tras todo el proceso de recogida de información). A partir de ahí, el desarrollador gurú sólo deberá seguir el plan e implementar lo que yo le he puesto ahí de la forma que mejor sepa.
Creo que nadie ha dicho de elegir un lenguaje antes del proyecto xD
#1 simplemente está cansado de hacer siempre lo mismo y busca un lenguaje que le permita abrir un poco las miras. Tan simple como eso. Y en lugar de aportar le ponéis pegas xD
#49 ¿Insinúas entonces que el background en lenguajes y paradigmas de cada uno no influye en el diseño de un producto?
#49 ufff, eso de me informo-elijo es un arma de doble filo. Sigo pensando que conocer un lenguaje/tecnología/loquesea al dedillo facilita hacer diseños mejores, y cuanto más conozcas lo que uses más eficiencia podrás sacar (no eficiencia en el código si no en el diseño.)
Repito, todo esto en POO parece muy fácil y sistemático por UML, pero es que no todo son objetos. ¿Cómo modelas características de un lenguaje sin clases? ¿Cómo modelas algo en LUA/Lisp/JS sin conocer el lenguaje al dedillo y que el programador acabe haciendo un churro inmantenible? Y no me vale usar ideas de POO, para eso usas Java.
Os recuerdo que Java/C/PHP etc. son cuatro tonterías y sistemáticamente modelables. Lenguajes más libres permiten hacer muchas más cosas que SÍ importan en el diseño (en #41 pongo un ejemplo con Scala.)
#51 No no, no me malinterpretes. Lo que estoy diciendo es que el diseño puede empezar a hacerse sin tener claro el lenguaje a usar, no así el paradigma. Tienes claro que necesitarás POO, pero sabes que dentro de POO hay varios lenguajes que podrán ir mejor o peor, según las necesidades o requisitos de tu proyecto.
Creo que antes de la elección del lenguaje, hay que tener claro muchas otras cosas. Y en base a ello elegir. No digo realizar un diseño terminado sin ni siquiera haber escogido un lenguaje, sino empezar a plantear otras muchas cuestiones que puede determinar la elección de uno u otro.
#52 Sí, es cierto que cuanto más conozcas el lenguaje, quizá salga mejor un diseño. Pero el plan de proyectos es algo vivo también, el diseño puede modificarse e ir evolucionando.
#14, en mi opinión esa idea que expresas pertenece al pasado. Es algo obsoleto.
La informática es un negocio muy particular. Es relativamente joven y, por tanto, todos aquellos nacidos en los 60 que se dedicaron a ella ahora están en puestos de Director de Dpto. de I+D, etc. o bien emprendieron con éxito en el sector.
Los nacidos en los 70 como yo (y mediados de los 80 a lo más), somos la generación de analistas-programadores que sufrieron el crack del 2000 pero que sobrevivieron a él y ahora están valorados en el mercado porque tenemos amplia experiencia y buena formación (los que hayan seguido reciclándose).
A medida que pasa el tiempo cada vez más gente se dedica a esto y, si bien más gente hace falta, ya no queda tanto hueco para ascender en este negocio. Esa frase del informático veinteañero de: "no voy a estar toda la vida programando" me suena a esa de: "los pisos siempre suben".
Hasta hace poco había opción de ascender porque tenían que formarse equipos de desarrollo y había que liderarlos. Pero últimamente esa famosa jerarquía de: jefe de proyecto -> analista -> analista programador -> programador, se ha difuminado bastante y ahora incluso jefes de proyecto tienen que programar la arquitectura base de ciertos componentes y luego dejar trazado el camino para que otros programadores de calidad continúen la tarea. Pero programar hay que programar.
En mis 11 años de experiencia laboral he pasado por pocas empresas, la verdad. Han sido sólo 3 y todas con un equipo de desarrollo de 10-20 personas. Bien, la experiencia me ha demostrado que los puestos de analista puro y duro duran dos días. Al final la empresa lo que busca es alguien con esa capacidad, pero que a su vez tire código de buena calidad. He visto a un "analista" de esos que no programan tirarse una mañana entera para decidir si sacaba los datos de dirección de una tabla de clientes a una tabla con entidad propia o si los dejaba dentro de la tabla de clientes. Eso no es rentable para una empresa. Al final lo que hace falta es tirar líneas de código con coherencia y esa coherencia la tiene que tener en un % importante el propio programador.
Recapitulando que me voy por los cerros de Úbeda:
En este sector se acabaron las jerarquías donde 5 piensan y 1 programa. Ahora 5 piensan y 5 programan aunque algunos programen más que otros. O, mejor dicho, unos crearan clases (los inteligentes y experimentados) y otros consumiran esas clases (los "picoypala" y juniors). Y se acabaron por una cuestión de ciclo. Es un negocio ya maduro y ya no sobran puestos de dirección. Por eso, aquello de: "no me voy a pasar la vida programando" ya no existe. Y si no al tiempo: veremos hordas de programadores con 60 tacos dentro de 20 años (yo ya he empezado a ver gente con 40 y 45 palos tirando código...).
¿Alternativa?: Emprender!
Yo por mi lado tengo mil ideas que estoy convencido (y algunos que las saben con experiencia) que triunfarían. Pero como no tengo los huevos suficientes para montarme por mi cuenta y dejar mi actual curro... seguiré programando. Por otro lado es algo que me encanta. Empecé con 9 años y ahora con 33 me sigue apasionando (excepto cuando hay fechas de entrega imposibles y proyectos poco creativos xD). Pero me veo jubilado y... PROGRAMANDO!
Hasta que llegue ese momento (y viviendo una crisis como esta), prefiero ser un buen programador senior a un arquitecto de esos que las empresas se calzan a la mínima.
Es mi humilde opinión.
#50, lo de "residencia en Alcantarilla (demostrable)" suena a fake, no? ...
#5 Para programar para móviles no te hace falta ningún móvil de última generación, en Android por ejemplo el propio Eclipse lleva un emulador muy simpático, eso sí, guarda RAM para ello x'DD
Supongo que con los iDevices será igual.
A mi la semana pasada me dieron un cursillo de SpringRoo muy interesante, es java, sí, pero lo que mola escribir una linea en la consola y que te genere hasta la capa web... Si te mola el tema de hacer appsweb privado y te paso documentación del cursillo.
#3 Lisp y el divertido mundo de los parentesis
Mi opinion es que como los lenguajes varian de un año a otro, lo mejor es especializarse en una doctrina concreta (ya sea comercio electrónico, seguridad, moviles, usabilidad,..) Realmente nuestra profesión es algo es lo que tienes que ir aprendiendo lo nuevo que sale toda tu vida.
gracias #58, aun no terminé el otro libro (no tengo tanto tiempo como elkaod xD), llevo más o menos la mitad y aun sin haberme ensuciado las manos, me gusta bastante lo que estoy leyendo.
De hecho cuando lo termine tengo pensado empezar un proyecto personal para ir metiendome en el lenguaje así que ese link viene de perlas.
De nuevo, gracias!
#58 me uno al agradecimiento.
Este tipo de documentación se echa de menos. A veces me leo un libro, acabo y pienso "vale, esto lo podría haber aprendido leyendo la documentación". Echo mucho de menos libros que se mojen y plasmen la experiencia real de haber usado el lenguaje. Ahorra mucho tiempo de peleas.
