Gusete
 
Gusete
 
#61 8 feb 12, 17:37
#61 8 feb 12, 17:37
#1 si te mola C++, videojuegos, etc... seguiria con C++ y me piraria cuanto antes a UK. Una vez alli, si te mola algo con una componente mas cientifica tienes muchas opciones en diferentes industrias (por ejemplo, financiera) con la base de C++ y estudiando arquitectura, algos y mates.

#56 Por lo menos en el mundo que me muevo (videojuegos/cine/fx) lo que dice #54 de que el que disenia tambien programa es valido tanto para dentro como para fuera de Espania. De hecho aun estoy por encontrarme a un analista en los 10 anios que llevo de ingeniero desarrollando software.

Es bastante obvio que la industria del software en general no es lo suficientemente madura como para tener esa separacion entre disenio e implementacion. Es mas, estos ultimos anios estoy pensando que ya no se trata de madurar y esperar a que algun dia podamos tener procedimientos ingenieriles como los que se dan en las fabricas de coches o al construir un puento. Mas bien, la creacion de software por su propia naturaleza es una artesania y nosotros no somos ingenieros sino artesanos.
 
BLZKZ
 
BLZKZ
 
#62 8 feb 12, 18:10
#62 8 feb 12, 18:10
#61 pensar que el desarrollo es un "arte" es un error MUY gordo. De hecho esa era la forma de pensar en los 50, y de la que el sector está intentando librarse, sino todo lo que sea ingeniería del software, estandares y patrones no serviría para nada.
  1
Gusete
 
Gusete
 
#63 8 feb 12, 19:12
#63 8 feb 12, 19:12
#62 alguna fuente de que en los 50 se pensara que era un arte? De hecho, es lo contrario desde por aquel entonces, 50-60, se vienen aplicando modelos ingenieriles (por ejemplo, modelo en cascada) al desarrollo de software. Y fijatete que hemos estado casi 40 anios para darnos cuenta que el modelo en cascada no sirve y estamos con modelos agiles ahora (que viene de otro proceso industrial) que parecen se adaptan mejor al desarrollo de software. El problema es justamente que consideres al desarrollo de software como un proceso industrial o de ingenieria cuando no lo es o por lo menos no aun. No me mal interpretes, todas las herramientas de ingenieria que usamos hasta ahora son muy utiles pero estamos en paniales.

Para una mejor explicacion, con papers y cosas de esas, echale un ojo a esto:
http://www.codinghorror.com/blog/20...eering-dead.html
 
BLZKZ
 
BLZKZ
 
#64 8 feb 12, 19:15
#64 8 feb 12, 19:15
#63 hasta mediados-finales de los 50 no habia siquiera SO's, TODO lo hacia el mismo tio, tanto mantenimiento como programación, se le consideraba un gurú, habia muy poca gente capaz, era un "arte".

Después hemos tendido a la especialización, a la separación de tareas. De ahí nace la ingeniería informática. No es dar fuentes es saber algo de historia de los computadores :/
  1
eisenfaust
 
#65 8 feb 12, 19:45
#65 8 feb 12, 19:45
#62 "sino todo lo que sea ingeniería del software, estandares y patrones no serviría para nada"

¿Y acaso sirven para algo?

Es una industria en bragas y lo único que hacemos es dar palos de ciego.

La ingeniería del software es una pantomima, un invento, una broma. No debería ni de tener cabida en una universidad.
 
BLZKZ
 
BLZKZ
 
#66 8 feb 12, 20:06
#66 8 feb 12, 20:06
#65 pues sirven para que un proyecto no se desmorone y pueda dividirse.

Pero bueno, esto está muy fuera de la temática y paso de discutir, y más para alguien que dice que no sirve para nada
 
Gusete
 
Gusete
 
#67 8 feb 12, 20:07
#67 8 feb 12, 20:07
#64 Cuando afirmas un hecho no esperaras que te creamos porque "no es dar fuentes es saber algo de historia de computadores" no? Y mas cuando con los que hablas se le suponen ciertos conocimientos sobre el tema.

De hecho es todo lo contrario a lo que tu dices, ya por entonces (50-60) se intentaba una aproximacion industrial/ingenieril al desarrollo de software. Un par de fuentes/hechos que lo ratifican:
* el modelo de cascada se empezo a usar alla por 1950 y pico. http://sunset.usc.edu/csse/TECHRPTS...usccse83-501.pdf
* el primer standard que conozco, ASCII, creado en 1960. http://edition.cnn.com/TECH/computi...3.idg/index.html
* En "The mythical man month", por P. Brooks (arquitecto jefe en el IBM OS/360 por 1950 y muchos, 60 y pico) cuenta las diferentes tecnicas de ingenieria aplicadas al desarrollo de ese sistema operativo. Por cierto, la biblia de la ingenieria del software http://en.wikipedia.org/wiki/The_Mythical_Man-Month
  1
CodE07
CodE07
 
#68 8 feb 12, 20:18
#68 8 feb 12, 20:18
Estoy con #61 claramente en esa línea de pensamiento de que programar es un arte. Cuando sueltas la famosa frase entre un grupo de desarrolladores se levantan ampollas enormes. Y, efectivamente, surgen los dos bandos.

No me apetece ahora soltar un tocho de los argumentos que tengo para estar a favor de que se acerca más al arte que a la ciencia. Por supuesto los pasionales/vocacionales no cuentan aquí. Me refiero a argumentos técnicos. Por ejemplo (al final voy a soltar un tocho...):

En 50 años de industria del software desde los 60, no es normal que el único estándar que se haya producido sea el UML. Y hablamos de una herramienta de lenguaje que sirve para comunicar conceptos de una forma común, nada más (que no es poco). Los patrones están muy bien y, de hecho, cuanto más tiempo llevas programando más te das cuenta de que llegas a la misma solución que tiene un patrón de diseño. Pero es sólo eso: un patrón, una forma genérica de abordar una solución a un problema. Pero al final hay que implementarlo.

En otras ingenierías (tengo un cuñado de Industriales especialista en estructuras) la creatividad está sujeta a muchos protocolos predeterminados donde no hay mucha libertad de movimiento. Y aun así la creatividad está ahí (arquitectura, por ejemplo).

Sin embargo, cuando programas tienes mil formas de abordar la solución de un problema desde el aspecto más arquitectónico hasta el algoritmo más concreto que hay dentro de un método. Puedes optar por trabajar de forma modular con funciones o con el paradigma orientado a objetos. Puedes trabajar con n-capas o meterlo todo en un mismo sitio. Es más, puedes usar decenas de lenguajes y decenas de herramientas. Y tener en cuenta la escalabilidad futura del software (un arquitecto de un edificio no tiene que tener en cuenta este hecho de una forma tan importante). Y, por lo general, muchos desarrollos no tienen un inicio y un final, sino que están en constante cambio con lo cual se cometen "errores" de planificación sí o sí porque los acuerdos iniciales varían y afectan a todo el sistema.

En definitiva, es tal la complejidad que hay que manejar que no hay proceso científico que resista esto como para estandarizar el proceso concreto de codificación. Insisto en lo mismo, la prueba de que es un arte es la cantidad de lenguajes, paradigmas, entornos, herramientas en los que se puede desarrollar. Si fuera tan fácil como comprar objetos y unirlos para fabricar software ya sería así y estaríamos todos en la calle o fabricando esas piezas (que las hay, pero para tareas muy concretas).

De todas formas, a veces pasamos por alto lo que significa ser un ingeniero. La wikipedia menciona lo siguiente:

Otra característica que define a la ingeniería es la aplicación de los conocimientos científicos a la invención o perfeccionamiento de nuevas técnicas. Esta aplicación se caracteriza por usar el ingenio principalmente de una manera más pragmática y ágil que el método científico, puesto que la ingeniería, como actividad, está limitada al tiempo y recursos dados por el entorno en que ella se desenvuelve.

Y creo que coincidiréis conmigo en que la resolución de un problema de la vida real y su implementación en miles de líneas de código tiene que ver mas con usar el ingenio que con cualquier otra práctica científica mas estandarizada.

En definitiva, el desarrollo de software es parecido a la arquitectura, tiene ciencia pero también tiene arte. Con la diferencia de que a los informáticos no nos aplauden cuando el resultado es bonito, eficiente, y sin errores (esto es una utopía xD), sino que siempre nos buscan las vueltas para criticar cualquier cosa que no se adapta a lo que el usuario espera.
 
BLZKZ
 
BLZKZ
 
#69 8 feb 12, 20:25
#69 8 feb 12, 20:25
#67 te repito hablas de los 60, yo de los 50 (más concretamente early 50, algo asi como 45-55)

Pero que bueno, como veáis

#64 hay metodologías para resolver TODOS los problemas que puedan surgir, pero no me meteré en que el mundo tiene naturaleza matemática y demás historia.

Asi que como queráis, programar es un arte.
 
CodE07
CodE07
 
#70 8 feb 12, 20:37
#70 8 feb 12, 20:37
No creo que sea cuestión de que sea una cosa u otra. Esta discusión la he tenido en otros sitios más veces y al final llego a la conclusión de que es algo muy subjetivo. En el fondo todos hacemos lo mismo pero unos lo consideran mecánico, aburrido y triste y otros lo consideramos creativo, divertido, enriquecedor.

Creo que es una cuestión de la pasión que le pongas. Entiendo que un tío que ha estudiado Ing. Informática por estudiar algo y que tirar líneas de código le parece un proceso mecánico y que no se recicla porque es algo que no le gusta, le parezca ridículo pensar que es un arte (que no digo que sea tu caso, ojo!).

Pero cuando te apasiona imaginar cómo resolver un problema en concreto, cómo hacer uso de esa capacidad asombrosa del cerebro que es la abstracción y además disfrutas diseñando una IU como un niño con un juguete nuevo... pues lo ver como arte.

Insisto, es una cuestión de pasión. Lo que no quiere decir que alguien que lo ve como ciencia no disfrute también. Pero dudo que lo haga como alguien que lo ve como arte. Pero vamos, que esto le pasa hasta a un cocinero donde, aun estando muy protocolarizado el proceso/cantidades/tiempo/etc. los hay que disfrutan, innovan y hacen lo mismo pero de maneras distintas (y al final eso el usuario lo nota xD).

Tampoco se es mejor y peor programador por tener una u otra visión. Te puede aburrir soberanamente y ser un crack (los he visto) y ser una pasión pero ser un paquete de cojones (también los he visto aunque menos xD).
 
BLZKZ
 
BLZKZ
 
#71 8 feb 12, 20:43
#71 8 feb 12, 20:43
#70 a mi siempre me ha encantado programar, siempre he estado picando código, pero yo veo el arte como algo "caótico" (ya se que muchas veces se basa en matematicas y blablabla). He pasado de programar todo tal cual me venía a usar técnicas que favorecen por ejemplo la reutilización.

Así como tambien estructuran mis ideas sobre como acometer el proyecto y que trazan unas líneas claras para la implementación. Se me abrió un campo enorme al descubrir patrones, algunos ya los usaba "sin querer" (y sin saber lo que eran) y otros me abrieron los ojos a otro mundo.

Está claro que el ingenio forma parte esencial en esto, pero es que eso también forma parte en otras ingenierias, así como la creatividad, pero yo a las teorías más brillantes de física cuántica no las llamo arte.

Edit: odio las GUI's
  2
CodE07
CodE07
 
#72 8 feb 12, 20:53
#72 8 feb 12, 20:53
#71 yo a las teorías más brillantes de física cuántica no las llamo arte.

Ahí es donde radica la diferencia entre algunos de los que pensamos que la programación es más arte que ciencia.

Yo las teorías brillantes de física cuántica sí las considero arte. Y lo hago en tanto en cuanto no había una forma exacta de abordar el problema, sino que fue el ingenio humano el que dando rienda suelta a la imaginación (como un artista) llegó a conclusiones ingeniosas, valga la redundancia.

En cuanto la resolución de un problema aumenta en grados de libertad y, por tanto, no hay manual previo de cómo hacer las cosas sino que hay que tirar de imaginación, intuición y otras capacidades humanas similares: para mí es arte. Aunque las matemáticas estén por medio como herramienta.

Efectivamente, confirmo que es una cuestión del enfoque de cada uno.
 
Gusete
 
Gusete
 
#73 8 feb 12, 21:18
#73 8 feb 12, 21:18
#69 Te estoy hablando de 1950 y pico y tu me estas hablando de 5 años de diferencia... en serio? XD

#69 #71 Ejemplo concreto, estimaciones de tiempo. En una ingenieria o proceso industrial, las estimaciones de tiempo tienen poco margen de error (cuanto tarda un coche por el pipe de produccion, cuanto se tarda en levantar un puente, cuanto tarda el operario de la estacion X del pipe de produccion en hacer la operacion Y, etc...). En software todavia estoy por ver una estimacion de tiempo que no se haya pasado en un porcentaje muy alto de la valoracion inicial. Estoy de acuerdo en que hay tecnicas para paliar esto, pero no estamos al nivel de una ingenieria o proceso industrial. Y como este ejemplo, muchisimos: viabilidad de diseños, calidad, analisis, metricas, etc... Es decir, todas las herramientas de que disponen cualquier ingenieria para poder llevar a cabo su trabajo de manera eficiente y seguro, o bien no las tenemos o si las tenemos estan a años luz.

Realmente, el meollo del asunto no es discutir si actualmente es una ingenieria o no porque todos los hechos indican que no lo es o que esta es aun incipiente, sino investigar si es que nos falta madurar o si directamente es inviable llegar a ser una ingenieria por la propia naturaleza del desarrollo del software.

#75 "De hecho esa era la forma de pensar en los 50[...]". Tu sabras tio.... pero vamos en 5 años ya se estaban usando metodos de ingenieria (con las fuentes que te he enseñado antes).... es que me parece ridiculo que sigas insistiendo cuando es evidente que lo que dices es incorrecto.

Vamos que segun tu las metricas de tiempo no es algo fundamental en cualquier ingenieria o proceso industrial. Acabaramos. Si es que me pasa por intentar tener una discusion razonada por internet! jajaja
Mensaje editado 2 veces. Última edición 8 feb 12, 22:07
 
BLZKZ
 
BLZKZ
 
#74 8 feb 12, 21:53
#74 8 feb 12, 21:53
#73 precisamente en esos 5 años cambió el mundo de la informática de manera drástica, se pasó del uso de válvulas al uso de transistores, además de que empezaron a usarse SO's

Y por cierto cuentale a la gente del CERN sobre estimaciones de tiempo ya verás por donde se las pasan, al igual que los arquitectos y sus obras , ingenieros de caminos... y así un largo etc

#75 <3
Mensaje editado 1 vez. Última edición 9 feb 12, 02:00
 
_oip_
 
_oip_
 
#75 9 feb 12, 01:50
#75 9 feb 12, 01:50
#19 : Con las condiciones no me meto, pero aquí medio país está llorando por no tener trabajo y todos mis conocidos (mejor o peor, y en algunos casos muy buenos) tienen trabajo.

Yo esta semana creo que tengo mi primera entrevista, nervios!

PD: Espero no dejar nunca de programar. Y estoy de acuerdo con que la herramienta de implementación (Java, C, una bici) no debería de tenerse en cuenta al modelar un sistema.

Esto es lo ideal, claro. Yo siempre pienso en objetos.

#73 : Pero como puedes decir que no es una ingeniería por Dios. Otra cosa es que le quede muchísimo por madurar.

#74 : Me caes bien.

PD: ElKaod tu también, pero creo que infravaloras los conocimientos en Java/C/PHP. Eso de que cualquiera puede modelar en Java, los cojones.
Mensaje editado 4 veces. Última edición 9 feb 12, 02:00
 
elkaoD
 
elkaoD
 
#76 9 feb 12, 04:37
#76 9 feb 12, 04:37
#75 ojo, quizá me he expresado mal, no digo que cualquiera pueda modelar POO, pero sí que das una patada a una piedra y te salen 6 expertos en POO. ¿Cuántos pueden hacer un desarrollo usando algún otro paradigma? Y eso que creo que el problema no es de cantidad: un desarrollo que se salga fuera de POO es inherentemente complicado no sólo por la falta de estándares para modelarlos sino por su propia naturaleza, muchos más compleja que simples objetos y relaciones entre ellos (que además son más fáciles de abstraer.)

Repito: cuando te sales de POO y procedimientos estándar como UML y demás estás jodido si pretendes atacar el problema con una metodología de diseño clásica. No sólo eso: lenguajes complejos (cualquier multiparadigma) dan mucha funcionalidad que ni Java ni C++ ni PHP ofrecen (complican mucho "el juego".) Aquí sólo te puede ayudar la experiencia, así que por mucho que "conozcas" un lenguaje sólo te salva el trabajo de campo. De hecho es por lo que creo que Java es tan usado en el entorno empresarial. al ser tan limitado también es más controlable.

Ojo, por otro lado es un engorro y esto si que se infravalora. Java no es lenguaje definitivo ni mucho menos (aunque quizá es más apuesta segura) ni en general la POO. Cierto autor (no recuerdo su nombre) argumentaba que bastantes de los patrones que aparecen en POO (y campan por la "industria" a sus anchas) no son más que limitaciones del propio lenguaje. Por ejemplo, el patrón visitante "desaparece" usando pattern-matching (se podría considerar un caso especial de pattern matching) y el patrón comando no es más que otro caso especial de first-class functions (¿esto se traduce funciones de primera clase?)

Hay que aprovechar las herramientas de las que disponemos y si para desarrollar algo me viene mejor prescindir de POO debo estar preparado. Quizá sólo falta que maduren los procesos relativos a la ingeniería y se siga estandarizando por ese camino, pero como de momento nadie ha andado el camino (se necesitan gurús de paradigmas para estandarizar) creo que no está de más poder sacarte las castañas del fuego (y puede marcar la diferencia para un posible trabajo.)

Aún así, por la propia naturaleza de la informática la ingeniería va a ir varios pasos por detrás. Esto puede ser bueno (para una empresa "monolítica" que necesita de procesos "ingenieriles" ) o un handicap (al abrirse nuevos mercados las empresas que se adaptan más rápido a la tecnología ganan ventaja.)

#61 la verdad C++ no me mola mucho y es un lenguaje que haría desaparecer en el infierno de los lenguajes. Se nota demasiado que la POO estaba en pañales y que no es más que un "hack" sobre C. Por otro lado es un mal necesario Menos mal que con C++11 se han puesto las pilas.
Mensaje editado 4 veces. Última edición 9 feb 12, 04:53
 
_oip_
 
_oip_
 
#77 9 feb 12, 10:33
#77 9 feb 12, 10:33
#76 : Ahí sí que estoy de acuerdo contigo, y es cierto que para otros paradigmas falta esa normalización.

De todas formas se puede aprovechar la potencia de otros lenguajes haciendo un diseño OO (que, efectivamente, tendrá sus limitaciones) y haciendo llamadas a otros lenguajes para hacer cosas más importantes.

Es un punto intermedio, donde se puede modelar OO e implementar de una formada bastante óptima.
 
Gusete
 
Gusete
 
#78 9 feb 12, 11:05
#78 9 feb 12, 11:05
#75 Prueba a comparar cualquier proceso industrial o de ingenieria, ves como lo hacen y las herramientas que usan, lo comparas con como se hace el desarrollo de software y luego decides si ahora mismo la informatica es una ingenieria o no. A poco que investigues descubriras que las diferencias son abismales. Esta tan en paniales comparado con otras que ni si quiera se puede considerar una ingenieria aun. Y lo dicho, lo realmente importante es investigar si es que nos falta tiempo para madurar hacia una ingenieria o si es del todo imposible por la propia naturaleza del desarrollo de software.

Se que choca con todo lo que te han enseniado en la carrera y que sin experiencia es dificil de digerir. Todos nos damos la ostia al pasar del mundo teorico de la universidad al mundo real de hacer proyectos. Te das cuenta que todo lo que has estudiado de ingenieria de software te sirve para poco o nada o lo que es peor, en la mayoria de los casos de gente recien salidos de la universidad, te sirve para influir negativamente al desarrollo del proyecto.

Me da la sensacion que muchos de vosotros hablais desde una nube muy alejados de la realidad del desarrollo de software. Le dais muchisimo peso dentro del concepto de ingenieria a cosas que en realidad no la tienen o son detalles (disenio de patrones o poo, por ejemplo) y no teneis en cuenta otras que son fundamentales (tiempos, calidad, viabilidad, planificacion, etc...) para el concepto de ingenieria.

#76 porque no pruebas a crearte tu propio lenguaje? Ahora con llvm es menos engorroso. Es un proyecto muy bonito y aprenderias un monton. Ideas: un dsl sobre un campo que te guste (fisica, mates, etc...), un lenguaje distribuido, etc...

Para hablar de C++ creo que necesitariamos otro thread! Ademas que ya he superado mi limite de flames al anio... Por cierto C++ es "multiparadigma": poo, generico y procedural.
 
_oip_
 
_oip_
 
#79 9 feb 12, 14:56
#79 9 feb 12, 14:56
#78 : Me da a mí que tu visión está bastante transtornada también. Me imagino que por el paso por varias empresas con métodos de mierda. Yo la única diferencia que veo en los métodos entre ingeniería industrial esp. electrónica y automática e informática es que los primeros son más pijos con los dibujos / diagramas. Por el resto, igual.

Vamos, que no estoy en absoluto de acuerdo con lo que estás diciendo. Si dentro de 10 años cambiaré de opinión solo el tiempo lo dirá.

PD: Y vamos, lo que he estudiado en ingeniería del software (que de hecho no la di aún, pero sé de qué va), sí se utiliza en empresas, me lo han dicho varios conocidos que llevan años currando. No todas las empresas son iguales, ya sé que en la mayoría solo hay chapuzas (y, si puedo elegir, las evitaré; si no, pues no pasa nada).
 
elkaoD
 
elkaoD
 
#80 9 feb 12, 15:31
#80 9 feb 12, 15:31
#77 claro, hay conceptos que se pueden traer (y mucho de ellos son paralelos como la modulariazión, despliegue, etc.) pero como tú mismo dices vas a estar limitado. Puede llegar a ser MUY diferente y cuanto más complejo el lenguaje más te alejas. Yo aún estoy "wrapping my mind around" (no sé cómo traducir esto al castellano xD) de muchas de las estructuras y forma de pensar, y toda la ingeniería del software que he dado no me ayuda ni un poquito. Si acaso me "desayuda" porque me he hecho a ciertas estructuras mentales que son contraproducentes (si no erróneas) si sales de POO.

#78 estoy de acuerdo con lo que comentas de tiempos, calidad, etc. y supongo que el resto de usuarios también, aunque estamos comentando el factor programación por la naturaleza del hilo.

Este año hemos hecho en la uni lo que yo llamaría PascalInterpretado1/2 (un medio) con Lex+CUP. Me apunto lo del DSL, puede ser interesante y además tenía ganas de implementar algún DSL en Scala, aunque ya está prácticamente todo hecho... habrá que darle al coco. Me apunto también LLVM para cuando necesite un backend

Y sí, C++ es multiparadigma pero por ser un "hackeo" sobre C y es una de las razones por las que es tan infernal: no está pensado de raíz sino que es un parche. Es un poco "cajón de sastre" (igual que cuando imeplementaron templates metieron TODO lo que podían.) ¡No me tientes, que abro un hilo! xDDD

Por cierto, procedural en castellano es procedimental

#79 cómo que no has dado aún IS? ¿En qué curso estás? Yo a mitad de 3º ya llevo chupadas 3 asignaturas de IS y una de gestión de proyectos.
Mensaje editado 1 vez. Última edición 9 feb 12, 15:37
 
Gusete
 
Gusete
 
#81 9 feb 12, 15:34
#81 9 feb 12, 15:34
#79 No he dicho que no se usase lo que se da en IS, sino que la vision que teneis de las herramientas que estudiamos en IS tanto en efectividad como en magnitud, no se corresponde con la realidad de los proyectos y no va en la direccion que se mueve la industria ahora mismo.

Tienes razon en que mi vision esta "bastante transtornada" pero no por "el paso por varias empresas con metodos de mierda" sino por el paso de varias empresas con metodos que daras en IS (que los califiques de mierda o no, ya lo haras cuando te toque usarlos).

#80 como abras un hilo de C++ te aseguro que no voy a tener paraguas lo suficientemente grande para la mierda que me metirian! XD

Por cierto, libro sobre la evolucion de C++, que ayuda a comprenderlo mejor: http://www.amazon.co.uk/Design-Evol...up/dp/0201543303
Mensaje editado 1 vez. Última edición 9 feb 12, 15:39
 
_oip_
 
_oip_
 
#82 9 feb 12, 16:41
#82 9 feb 12, 16:41
#81 : Entonces te entendí mal, y en ese caso estoy de totalmente de acuerdo contigo. Lo que quiero decir es que la ciencia de la computación (o como quieras llamarlo, ingeniería o salchicha) es muy joven. Pero hay una metodología (en constante evolución) y una (o varias) formas de hacer las cosas (tanto para bien, como para mal). Que no seamos tan cuadriculados como otros ingenieros, no quiere decir que seamos unos "perroflautas de la ciencia" xD.

PD: Y sobre todo no puede juzgar una rama de conocimiento por cómo se explota en las empresas, claro.

#80 : A ver, yo estoy en 4º (bueno, oficialmente lo estaré para el año que este estuve con el PFC de la técnica) y he dado unas tres también, pero la importante para mí está en 5º, hablaba de esa
 
elkaoD
 
elkaoD
 
#83 9 feb 12, 16:44
#83 9 feb 12, 16:44
#82 ah, eres de plan antiguo. Ya decía yo, me sonaba que ibas algún curso por encima de mí. Yo es que soy Bolonio, nuestro 5º es el máster
 
_oip_
 
_oip_
 
#84 9 feb 12, 16:50
#84 9 feb 12, 16:50
#83 : Pareces tener mucho control del tema, enhorabuena. Mi hermano está en 2º de grado y aunque saca buenas notas no tiene tanta curiosidad.

De hecho ya soy ingeniero técnico! Por eso este año no estoy aún en cuarto, porque no puedo matricularme. Pero voy haciendo prácticas y estudiando a ver si me saco todo 4º + optativas para el año.

PD: Sigue así y saca MH en el PFC. Es la hostia y mucha peña consigue trabajo por ello. En mi convocatoria dieron 2 y yo quedé de 3º ¬¬
 
MTX_Anubis
 
#85 9 feb 12, 22:56
#85 9 feb 12, 22:56
#82 Hay metodologías en constante cambio y las metodologías suelen ser de trabajo como las metodologías ágiles tan de moda ahora y que cada vez más empresas adoptan entre otras cosas porque en ninguna otra rama hay tantos cambios de requisitos a 2 días de las entregas xD.

Si nos centramos en la parte de patrones, estoy de acuerdo con lo dicho más arriba que la mayoría de los usos son por carencias del lenguajes y añado que además es bueno utilizarlas en equipos grandes y en proyectos grandes más que nada para que cuando entre alguien nuevo, sepa por donde van los tiros.

Por lo demás, este trabajo depende tanto de la persona, su creatividad, su valía, aptitudes y la comunicación, que yo no sé que pensar xD
 
eisenfaust
 
#86 9 feb 12, 23:08
#86 9 feb 12, 23:08
#85 Al mencionar lo de las carencias del lenguaje me ha venido a la mente Peter Norvig xD

Lectura obligada: http://www.norvig.com/design-patterns/

El 70% del contenido del gang of four a tpc.
 
_oip_
 
_oip_
 
#87 10 feb 12, 00:14
#87 10 feb 12, 00:14
#85 : Yo creo que este debate es un poco absurdo. Es tan sencillo como que es una ciencia muy joven y hasta dentro de bastantes años supongo que no habrá suficientes estándares.

Anyway, a mi me encanta esto hoyga xD
 
allmy
 
allmy
 
#88 25 feb 13, 21:54
#88 25 feb 13, 21:54
#1 Hacer algo productivo y que de dinero. xD
  1
Sarwaz
 
Sarwaz
 
#89 25 feb 13, 22:50
#89 25 feb 13, 22:50
123
Favoritos
8


Regístrate y participa

Más de 100.000 mentes enfermas no pueden estar equivocadas.

Regístrate ahora! Sólo son 10 segundos!
x