¿Qué lenguaje de programación me recomendáis para empezar?

Hola a todos, me gustaría preguntaros eso: que qué lenguaje de programación me recomendais como principiante.
Solo se un poco de BASIC, y me gustaria pasar a otro en cuanto mejor un poco, ¿cuál me recomendais?

BASIC? Esta pregunta me ha hecho retroceder 25 años

Pues así, sin más (es decir, si no sabes para qué lo quieres aprender y qué vas a hacer con él, y solo quieres aprender por placer), un buen lenguaje para comezar a programar es... HTML! Sí, porque es muy fácil y con poco consigues resultados muy vistosos. Como extensión, puedes aprender Javascript (también bastante fácil) para complementar el HTML y luego Java, pero eso ya es otro cantar

Una vez movido el tema, yo no empezaría por HTML... ¡porque no es un lenguaje de programación! No tiene ninguna similitud con los lenguajes de programación y no te va a servir para entender "cómo se programa".

Yo te diría que empezaras por algo de programación estructurada: empieza por C, por FORTRAN o cosas así. Si quieres algo más vistoso, entonces empieza por POO y, no sé, Visual Basic (la versión que sea que es la que se usa ahora) te permitirá hacer programas y pillar de qué va el tinglado.

Creo que C# o Java son algunos de los mejores para comenzar, aunque sinceramente yo recomiendo comenzar con la metodología de la programación antes de hincarle el diente a cualquier lenguaje.

Pues yo creo que ninguno de los que habéis mencionado son buenos lenguajes para aprender a programar. No son nada deductivos. En mi blog ya puse una idea de por donde emprezar (lo pongo oculto por si es SPAM)
...http://www.viciojuegos.com/aportacion.js...

Para aprender es mejor usar Pascal o Component Pascal que es muy sencillo y lógico, aunque si bien es cierto que de C o Java hay mucha más documentación si quieres aprender por tus propios medios. Pero todo es comprarse un libro y darle.

Precisamente, iba a abrir un tema relacionado, pero ya lo pongo aquí. Últimamente estoy llevando a cabo desarrollos de software más grandes (en volumen, complejidad, interacción (equipo de desarrolladores), etc.) y me gustaría poder leer algo relacionado con dos aspectos que considero clave para poder llevar estos temas mejor:
- Primero, sobre cómo programar bien. El término es difuso, pero vendría a ser algo así como "guías de estilo", "guías de buenos hábitos" o similar, relacionadas con comentarios, indentación, estructuración de código fuente, subrutinas, etc. Supongo que entendeis a qué me refiero.
- Y la segunda (creo que menos prioritaria) está más relcionada con la gestión en sí misma del proyecto.

Confío en que vosotros que os dedicais a esto/lo habéis estudiado podáis conincidir en señalarme un par de buenos libros/imprescindibles que se adapten a lo que digo. También confío en que entendais a lo que me refiero .

A mí me gustaría empezar a aprender sobre desarrollo ágil de software pero no tengo mucho tiempo. Echa un vistazo a algunos libros (gratuitos): http://www.etnassoft.com/biblioteca/cate... Hay sobre SCRUM o TDD, por ejemplo, que son metodologías muy interesantes, tanto para la gestión del desarrollo como para la implementación.

No puedo ayudarte mucho más

Sobre guías de estilo, cada lenguaje tienes las propias, por ejemplo las de Java: http://www.oracle.com/technetwork/java/c...
Habla sobre los saltos de línea, cómo nombrar las variables, las constantes, los métodos, como comentar y qué partes del código comentar, etc. En los entornos de programación suelen venir esas reglas por defecto en los reformateadores automáticos.

Sobre estilo a la hora de programación, patrones. Principio de encapsulación, programar interfaces no implementaciones, encapsular familias de algoritmos, polomorfismo, herencia, principio Hollywood (no nos llames, nosotros te llamaremos), una clase una responsabilidad, Has-a Is-a, etc. Yo aprendí sobre esto en un libro de patrones y en otro de Ingeniería de Software de Roger Pressman.

Para la gestión de grandes proyectos, si es un equipo lo principal es definir bien los roles del equipo, plantear bien los requisitos y plantear un diseño de arquitectura que hay verificar cuanto antes su viabilidad. Definir bien la metodología del proyecto, definir bien las partes comunes del proyecto y las individuales... Para las fases de desarrollo, control de versiones, suvbersion es el complemento obligatorio para cualquier equipo de desarrollo. La Gestión de Proyectos es para hablar largo y tendido. Y más cuando te metes en los roles de un Jefe de Proyecto: métricas de tamaño, estimaciones, costes, métricas de calidad (y aquí el mundo de los ISOs), evaluacion... Y por supuesto, primer hay que definir qué tipo de modelo vas a seguir para el desarrollo del proyecto: incremental, reiterativo, cascada, etc. El CMMI es el más extendido, aunque todo depende del cliente, que por ejemplo a cliente pequeño le da igual pero para un banco, una corporación local o un ministerio de defensa cada uno tiene sus diferentes protocolos que estás obligado a cumplir si quieres el contrato. Yo en mi proyecto lo realicé conforme al Proceso Unificado ( http://en.wikipedia.org/wiki/Unified_Pro... )

Joder, estas dos respuestas ya me parecen la ostia. Si Palma o alguien más se anima a comentar, yo creo que vamos a poder intercambiar información bastante valiosa sobre este tema.

@Whiz Gracias por los enlaces, intentaré echar un ojo a eso que me comentas. Todas las siglas me suenan a chino, a este nivel soy como un noobie total.

@Gangrena Completísima información, me sobrepasa, pero me gusta porque se mencionan todos los temas que pretendía tratar. Empiezo comentándo párrafo a párrafo.

Trabajo en FORTRAN principalmente (con perl/batching MS-DOS para gestionar archivos), y no tengo claro que haya nada parecido, aunque lo voy a buscar. Mi compilador (Visual Compaq FORTRAN, el más utilizado para 32-bit, sustituido ahora por el Intel VISUAL FORTRAN para 64-bit) no tiene ningún tipo de procesado del código. Lo más que hacen (ambos) es resaltar los comentarios en verde, fin. Sin embargo todos los demás temas que hablas, aunque me suenan a chino me parecen interesante porque me refería en parte a ese tipo de cosas.

En cuanto a la gestión de equipos, debo decir por si se me ha malinterpretado que, por suerte para el futuro de la empresa/mío propio, el proyecto no es tan grande, el cliente es la propia empresa, y no existe ningún rol definido de nada más que "haced lo que os parezca". Digamos que todos estos principios que mencionas me gustaría poder ir conociéndolos para aplicarlos adecuadamente a pequeña escala, e intentar que desde ya el código que vaya desarrollando cumpla algunos requisitos que faciliten las cosas hacia el futuro. En cuanto a subversion, estoy de acuerdo que es algo que hay que usar y es un tema que me gustaría ir implementando, pero parece que hay ciertas reticencias entre los compañeros y habrá que ir limándolas porque tengo claro que sí que nos va a facilitar mucho la vida.

En fin, a los dos, gracias. Anoto los libros e intentaré ir echándoles un vistazo.

¿Tiene salida comercial programar con FORTRAN? Debe ser todo para desarrollar software en viejos equipos industriales y servidores.

Creo que Eclipse y NetBeans soportan FORTRAN y te reformateará el código conforme a algún tipo de protocolo. Y sino el SciTE también reconoce FORTRAN y reformatea el código aunque no sé si puedes cambiarle las reglas (Eclipse y Netbeans lo permite).

Sobre la gestión, entonces yo te recomendaría el proceso unificado que es muy sencillo aplicar rollo este plan:
Fase Incio: Recopilación de requisitos, casos de uso, objetivos y elección de la tecnología (5% de esfuerzo del Proyecto total)
Fase Elaboración: Diseño de la arquitectura, BBDD y esquema de la GUI. (20%)
Fase Construcción: Código de la aplicación y pruebas. Versión Alpha y algo de la Versión Beta. (65%)
Fase Transicioón: Más pruebas, optimización y corrección de bugs. Versión Beta y versión final (10%)

Muchas gracias a todos por vuestros consejos, creo que empezare por Pascal, parece de los mas sencillos

Sobre estilos, hay tantos como programadores existen. Yo personalmente me salgo un poco de lo habitual. Aunque sí que me gusta mantener correctamente las tabulaciones, declarar variables arriba del todo, y esas cosas, sigo mis propias reglas a la hora de nombrar variables o poner los nombres de las funciones. No me gusta eso de que todas las variables y funciones sean camelizadas, sino que prefiero que empiecen siempre por mayúscula. Tampoco me gusta que las llaves se abran en la misma línea en la que se pone el nombre de la función, prefiero ponerla en una línea nueva. Y además, todos los nombres los pongo en castellano.

En cuanto a la gestión de proyectos... si yo te contara el caos que llevo siempre con eso. Para empezar, hay clientes que ni siquiera saben lo que quieren. O lo saben pero se explican como el culo. O te dicen que ya lo irán viendo sobre la marcha. En fin, así que toca adivinar un poco lo que hay que hacer, e ir enseñando los progresos al cliente para que vea si la cosa va bien. Lo gracioso es que siempre dice que sí, que la cosa va bien, para luego, ya cerca del final o incluso con el proyecto ya terminado, de repente se acuerda de algo que tiene que estar, o de algo que sí que está pero no hace lo que debería, y que para poder incluirlo toca modificar la estructura de la base de datos, cuando no rehacer medio proyecto. Y no se dieron cuenta antes, no. Por supuesto, estas mierdas fuera de presupuesto se cobran aparte, pero vamos, que llevar una planificación seria es a veces una quimera.

Sobre el lemguaje: ADA, Pascal o C, diría yo. Empezar por POO me parece peligroso sin conocer la estructurada. Eso sí, ante todo conocer la metodología, no lanzarse a programar sin más.

Sobre el estilo:

- siempre sigo las convenciones de la tecnología y el lenguaje, algo que he notado muchísimo con Objectuve-C, que aquí a algunos les daba un soponcio.
- soy verboso con los nombres de variables. No suelo usar abreviaturas ni acrónimos. Si no existiese el autocompletado en los IDEs me lo plantearía pero como no es el caso no hago un usrImg sino userImage.
- camelizo todo, pero siempre viendo la convención.
- siempre siempre siempre siempre en inglés., tanto código como comentarios.

Al hilo del inglés, me parece un absoluto aborto encontrarte con un getTasacion() o cosas así. Lo primero porque tu código puede ser leído en el futuro por diferentes personas, y es evidente que ese método solo lo entendería el que lo creó. Aparte, choccan convenciones básicas como es nombrar getters y setters de una forma clara y concisa que exprese su función, que es con "get" y "set" y luego ver el nombre en castellano. Mezclar idiomas es absurdo, desde mi punto de vista, porque para todo hay traducción.

En fin, que no me parece ni limpio, ni legible y, sobre todo, no tiene en cuenta que en el futuro puede que no seas el único que mantenga el código. Hay una máxima muy clara que se nos debería meter a fuego a todos los que nos dedicamos a esto: no programes para ti sino para los demás, tanto cómo codificas, cómo comentas y en qué idioma.

PD: me tengo que poner con el SCRUM, a ver si saco tiempo. Me guardo los enlaces.

+1000 Que una vez trabajé con un compañero que el mamón escribía los comentarios, nombres de variables y demás en valenciano

Aunque eso sí, si algún día me voy al extranjero a currar tendré que escribirlo todo en inglés, pero mientras todos mis compañeros entiendan castellano, prefiero escribirlo todo en castellano.

Yo empezaría con C para aprender bien las estructuras y los algoritmos para hacer cada pequeña y estúpida operación. De ahi a algún lenguaje orientado a objetos (como Ruby, por ejemplo, que es el más molón )

Sobre el estilo, yo estoy de acuerdo con mys sobre usar la convención en cada lenguaje. A mi me parece vital. Lo mejor es poner en google el lenguaje y un "best practises". En sitios como stack overflow molan los debates que salen de temas así, se aprende mucho

Sobre mezclar el ingles y el español, ya veréis cuando se entere el tribunal de La Haya que vais haciendo esa cutrez. Avisados estáis!

Es que de eso se trata, al menos por mi parte. Quitando casos puntuales como el de VJ, en el que traté de seguir el estilo que ya había pensando en eso, normalmente programo solo para mi y siguiendo mis propias convenciones. Nadie tiene que entender mi código, porque nadie tiene que leerlo. Yo no tengo porque aprender de los demás, QUE LOS DEMÁS APRENDAN DE MI, COJONES.

Debe de ser una maravilla ser compañero tuyo en algún proyecto

Aparte de tomarme a chirigota la última frase, por el hoyganismo, me pongo serio.

Nunca sabes, y no me digas que lo sabes a ciencia cierta por mucho que sea tu empresa, que tu código no vaya a ser leído por otra persona. En el hipotético caso de que tengas que contratar a alguin es egoísta y enfermizo obligar a esa persona a olvidar las convenciones profesionales y MUNDIALES de cada teconología/lenguaje porque a ti se te ponga en los cojones. Es obsceno.

Aparte, ¿por qué no seguir convenciones de lenguaje, que están revisadas por cientos de personas que se dedican a esto? Me dirás que te parecen absurdas, poco útiles o incluso erróneas, pero a mi me suena a que no las aprendiste en su momento, te montaste tú una película y no te apetece cambiarlas.

Una cosa es cómo formateas, por ejemplo, los bloques condicionales (donde pones la {, por ejemplo) y otra cómo nombras tus variables, métodos, clases, etc y saber, porque esto es básico, que cada lenguaje tiene sus convenciones y, en muchos casos, por algo será.

Te pongo el ejemplo de Objective-C y Cocoa. Es conocida la convención de que en POO a las variables miembro de la clase se las suele nombrar con un guión bajo delante: _variable. Bien, en Obj-C eso, aparte de no ser necesario por el control de variables privadas de las clases, choca con la nomenclatura de las variables del framework, de forma que puede haber conflicto. En caso de querer marcar variables miembro como privadas (como digo no es necesario(, pon el underscore detrás: variable_. Y como ese varios ejemplos.

Y bueno, hablo de convenciones, pero lo del inglés me parece que clama al cielo. Yo que obligaría a estudiar todos los años una asignatura de inglés en la carrera y/o CFGS, y aquí la peña con estas. Urticaria.

Me has aclarado una cosa: si alguna vez soy responsable de la contratación de alguien le pediré que me enseñe su código, ni harto de vino contrataría a un tío que siguiese tus prácticas y no atendiese a razones, como dice Cartman debías de ser un compañero de proyecto para enmarcar

A ver, que creo que no me he explicado. No se trata de que yo siga mis propias convenciones porque piense que nadie más va a leer mi código, sino porque no quiero que nadie lo lea. Lo admito, soy extremadamente celoso con mi código. He visto el código de todos los programadores que he conocido, y bueno, no está bien que yo lo diga, pero suele ser basura comparado con lo que yo hago. No me gusta que me copien, de igual manera que me gusta hacer las cosas por mi mismo, de hecho hasta tengo mi propio framework, que no será perfecto, pero al menos puedo decir que todo lo que hago lo he hecho yo desde cero. Además soy un maniático para el código, me puedo tirar varios minutos solo para decidir el orden en el que quiero poner las variables o las funciones dentro de una clase o si quiero dejar en líneas en blanco que separen bloques de código, y a veces esas manías chocan con las convenciones.

Y que conste, yo si que aprendí las convenciones, y las he utilizado en todas aquellas ocasiones en las que he tenido que hacerlo por el motivo que sea. Y si alguna vez me viese en la obligación de presentar un código en algún proceso de selección, pues también lo haría. Pero fuera de esos entornos, lo que yo hago es solo para mi por lo expuesto en el párrafo anterior.

En fin, yo sé que las convenciones existen por algo, y no dudo de su utilidad. Pero al igual que en muchos otros aspectos de la vida, hay cosas en las que prefiero seguir mi camino, y no el que marcaron otros.

De echo, por lo menos a mi, ya lo comente, en la carrera si te da por llamar a las constantes y no como te han enseñado te crujen, al igual que si no tabulas ni modulizas. Para algo esta cada cosa, y luego si lo ves en el codigo sabes antes de que va cada cosa, y que tienes que modificar en el caso que no fuese.

Una cosa son las convenciones y otra el formateo. La primera se debería seguir a rajatabla, la segunda es personal en tanto en cuanto se cumpla la mínima indentación.

Palma, con lo del framework no te confundas, en Telefónica I+D, por ejempelo, usábamos un framework propio. Una cosa es crearte herramientas que faciliten tu trabajo, o la forma de estructurar una aplicación, y otra lo que tú haces. Pero en serio, me estás descubriendo muchas cosas. Ahora entiendo que en algunas ofertas de trabajo especifiquen que se busque a alguien que pueda trabajar en equipo. Debías de ser el peor compañero de trabajo posible, la verdad.