Portada
mis comunidades
otras secciones
![¿Por qué es tan jodidamente difícil aprender a programar? [Eng]](https://cdn.mnmstatic.net/cache/23/d4/media_thumb_2x-link-2348085.jpeg?1423075146)
#3:
Programar es fácil.
Lo que es más jodío es hacerlo bien.
Lo que es más jodío es hacerlo bien.
#14:
Aprendí a programar a los 16 años con el manual del Amstrad, (un basic en rom muy potente para la época) y no es difícil. No es verdad que el basic enseñe malos hábitos de programación,los malos hábitos los coge la gente predispuesta a cogerlos. Un mal programador que llama a gotos probablemente tb será alcohólico y ludópata
Yo huía de los goto y competíamos por hacer el programa más rápido y a la vez más pequeño y elegante.Codigo indescifrable e inentendible sin comentar.
No sabíamos algoritmia: Los inventábamos. Para las cosas que no alcanzaba el basic, ensamblador llamado con un CALL.
ah! que tiempos aquellos.Nada es dificil si te apasiona,nada.
Yo huía de los goto y competíamos por hacer el programa más rápido y a la vez más pequeño y elegante.Codigo indescifrable e inentendible sin comentar.
No sabíamos algoritmia: Los inventábamos. Para las cosas que no alcanzaba el basic, ensamblador llamado con un CALL.
ah! que tiempos aquellos.Nada es dificil si te apasiona,nada.
#44:
Saludos a todos. 28 añitos ya dedicado a esto de programar y he visto de todo. Para mi, programar bien son dos cosas principalmente. La primera, que funcione. La segunda, que mañana llegue otro programador y no tenga que rehacer el programa de nuevo por que tu código es una basura. Da igual el lenguaje , framework o herramienta.
Es mi más subjetiva y personal opinión.
Es mi más subjetiva y personal opinión.
#83:
#21 Se nota que eres todo un guruh de esos hamijo!
Una de las formas más sencillas de identificar a un flipadito que se cree que sabe programar y no tiene ni puta idea es precisamente buscar frases como la tuya de "hacer webs no es programar". Así uno os identifica rapido y os evita en los proyectos.
Te ponía yo un par de webs de nada de AA.PP. o de gestión de grandes empresas, que tienen más diseño y codificación seguramente por si mismas que todas las aplicaciones que has hecho en tu dilatada e increible experiencia programando.
A ver si alguno os entra en el cerebro que una web no es un html cutre bien maquetado, sino que muchas veces son aplicaciones de gestión, facturación, etc. ingentes cuya única diferencia con una aplicación de las que tu llamas de verdad, es que la interfaz es via web.
De verdad cuanto tonto con aires. Sigue así, te auguro en un futuro próximo tu ascenso a gerente, que ese es otro patrón tipico en España, que acaben de jefes los más inútiles, esos que luego te dirán en una planificación "pero si esto se hace en dos días, hombre"
Una de las formas más sencillas de identificar a un flipadito que se cree que sabe programar y no tiene ni puta idea es precisamente buscar frases como la tuya de "hacer webs no es programar". Así uno os identifica rapido y os evita en los proyectos.
Te ponía yo un par de webs de nada de AA.PP. o de gestión de grandes empresas, que tienen más diseño y codificación seguramente por si mismas que todas las aplicaciones que has hecho en tu dilatada e increible experiencia programando.
A ver si alguno os entra en el cerebro que una web no es un html cutre bien maquetado, sino que muchas veces son aplicaciones de gestión, facturación, etc. ingentes cuya única diferencia con una aplicación de las que tu llamas de verdad, es que la interfaz es via web.
De verdad cuanto tonto con aires. Sigue así, te auguro en un futuro próximo tu ascenso a gerente, que ese es otro patrón tipico en España, que acaben de jefes los más inútiles, esos que luego te dirán en una planificación "pero si esto se hace en dos días, hombre"
#19:
Es difícil meterse porque:
- Hay muchos idiomas y el lego no sabe por cual decidirse al principio.
- Unos idiomas son mejores para una cosa y otros para otra, y todos tienen profetas que los defienden por encima del resto.
- Hay que pensar de modo diferente, muchas veces en términos de si/no, y siempre en una estructur diferente a los "idiomas" a los que la gente está habituada (excepto el lenguaje matemático)
- Hay que ser muy ordenado, constante, aplicado, leer mucho, etc...
- Llega un momento en el que todo falla, no se encuentra el error por ninguna parte y parece que nadie puede ayudarte (ahí lo dejan muchos)
- Cuando al fin consigues programar algo, descubres que habría sido mejor en otro lenguaje o que alguien ya lo había hecho antes que tu, mejor, más bonito y además con prestaciones que le dan mil vueltas al tuyo.
...
En cualquier caso creo que cada vez es más necesario tener alguna noción sobre programación y es una de las grandes carencias del sistema educativo.
- Hay muchos idiomas y el lego no sabe por cual decidirse al principio.
- Unos idiomas son mejores para una cosa y otros para otra, y todos tienen profetas que los defienden por encima del resto.
- Hay que pensar de modo diferente, muchas veces en términos de si/no, y siempre en una estructur diferente a los "idiomas" a los que la gente está habituada (excepto el lenguaje matemático)
- Hay que ser muy ordenado, constante, aplicado, leer mucho, etc...
- Llega un momento en el que todo falla, no se encuentra el error por ninguna parte y parece que nadie puede ayudarte (ahí lo dejan muchos)
- Cuando al fin consigues programar algo, descubres que habría sido mejor en otro lenguaje o que alguien ya lo había hecho antes que tu, mejor, más bonito y además con prestaciones que le dan mil vueltas al tuyo.
...
En cualquier caso creo que cada vez es más necesario tener alguna noción sobre programación y es una de las grandes carencias del sistema educativo.
#59:
#c-56" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/56">#56 Lo siento pero estas terriblemente mal informado.
Las cosas que salen para c# salen al mismo tiempo para VB. Ejemplo, cuando salio .NET 4.5 se pudo usar async y await al mismo tiempo en ambos lenguajes.
El resto de lenguajes como F# y demas si que van "con retraso".
En cuanto a rendimiento, todo se traduce al mismo lenguaje intermedio para la maquina virtual. Es exactamente igual. El ILSpy te abre dlls y te permite ver el codigo indistintamente en c# o vb.net.
Por eso digo que hay mucha ignorancia con VB. A dia de hoy solo difiere de C# en sintaxis, nada mas.
Hablar de VB6 es tan ridiculo como comparar un linux del 2000 con Windows 8.1, por ejemplo.
No tiene pies ni cabeza.
Las cosas que salen para c# salen al mismo tiempo para VB. Ejemplo, cuando salio .NET 4.5 se pudo usar async y await al mismo tiempo en ambos lenguajes.
El resto de lenguajes como F# y demas si que van "con retraso".
En cuanto a rendimiento, todo se traduce al mismo lenguaje intermedio para la maquina virtual. Es exactamente igual. El ILSpy te abre dlls y te permite ver el codigo indistintamente en c# o vb.net.
Por eso digo que hay mucha ignorancia con VB. A dia de hoy solo difiere de C# en sintaxis, nada mas.
Hablar de VB6 es tan ridiculo como comparar un linux del 2000 con Windows 8.1, por ejemplo.
No tiene pies ni cabeza.
#55:
#c-7" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/7">#7 Que graciosa la ignorancia... dime, ¿que te permite hacer C# o Java que no te permita VB.NET?
Venga, espero la respuesta.
Funciones lambda, mocking, Linq (uppps eso en Java no existe), programacion asíncrona, paralelismo avanzado, etc... VB no es como hace 15 años.
Quizas no te guste la sintaxis, pero te permite hacer lo mismo o mas que Java (me atrevo a decir mas por Linq)...
Venga, espero la respuesta.
Funciones lambda, mocking, Linq (uppps eso en Java no existe), programacion asíncrona, paralelismo avanzado, etc... VB no es como hace 15 años.
Quizas no te guste la sintaxis, pero te permite hacer lo mismo o mas que Java (me atrevo a decir mas por Linq)...
#222:
#43 #114 #118 #212 algún día escribiré más a fondo sobre ello... pero sería demasiado que contar sobre esos 3 meses perdidos.
Uno de los principales fallos que le vimos es Eloquent, un ORM de juguete que no te permite hacer sentencias con join complejas, y que al final, te da más problemas de los que te resuelve.
Las migraciones, otro chiste malo. Mientras otros ORMs, como es normal, crean las migraciones desde los modelos, aquí pierden casi todo su sentido. No dejas de repetir trabajo ya hecho. Ah, y mejor no hablemos de que cada clase de una tabla tenga que ser un archivo, incluyendo joins, tablas proxy, etc. Hemos llegado a tener 20-30 archivos de modelos por aplicación.
Laravel no deja de estar fuertemente basado en Symfony, pero sin serlo. Una mezcla rara, un frankenstein. Por ejemplo, Laravel tiene su propio sistema de rutas (Symfony ya trae), el cual funciona francamente mal. Te limita muchísimo, porque cosas como tener grupos anidados de rutas no es posible, cosa que sí se puede en otros frameworks.
Laravel debería ser sinónimo de dump-autoload (y no es tanto culpa de Laravel sino de Composer), ya que la creación de nuevas clases requiere estar ejecutando comandos para que el PSR lo tenga registrado (¿de verdad es necesario en desarrollo?), o al menos así era necesario en los workbenchs. A veces fallaba porque se hacen referencias a la clase aún no disponible, tenías que hacer malabares, etc. Un asco para trabajar.
Esto me lleva a hablar de los paquetes. Crear paquetes es incómodo, no se trabaja de la misma forma que sobre el proyecto. Mi conclusión es que afirma ser modulable sin serlo de verdad. Por ejemplo, no tiene nada que ayude al menos en desarrollo a servir los archivos estáticos de tus paquetes.
Otro tema es el de las versiones. Laravel al estar en pañales (aunque aseguren estar ya en su versión 5), de versión en versión mucho código y paquetes pasan a ser incompatibles. Otros frameworks tienen más cuidado en este aspecto, dando alertas de uso de métodos deprecated, retrocompatibilidad hacia atrás, versiones LTS, etc. Laravel no.
Podría estar todo el día hablando, de todos los problemas que hemos tenido, pero no quiero irme sin comentar la documentación: Laravel tiene probablemente una de las peores documentaciones para un framework ampliamente usado que he conocido. En un principio pinta bien, sencilla, ¿qué puede salir mal? La falta de ejemplos para casos reales, pero sobre todo, que la gran mayoría de métodos del mismo framework no estén documentados, te hace darte cuenta de la poca seriedad que en realidad tiene Laravel.
Mi conclusión, es que Laravel debe estar programado por expertos de marketing e imagen, pero no por programadores. Saben vender el producto y su relativa sencillez. Tienen una web bonita que te entra por los ojos. Pero la realidad es que se trata de un framework poco estable, mal documentado y pobre.
Si eres un particular y vas a hacer un proyecto sencillo... bueno, puede que te sirva. Pero para una web grande de una empresa, imposible. No puedo recomendarlo.
En 10 días hemos llegado al mismo punto que estábamos en Laravel tras 3 meses. Yo sabía programar en Python, otros de la empresa no, pero igualmente, siendo un lenguaje tan fácil (aunque les esté costando), ahora, y tras tan poco tiempo, agradecemos la decisión.
Uno de los principales fallos que le vimos es Eloquent, un ORM de juguete que no te permite hacer sentencias con join complejas, y que al final, te da más problemas de los que te resuelve.
Las migraciones, otro chiste malo. Mientras otros ORMs, como es normal, crean las migraciones desde los modelos, aquí pierden casi todo su sentido. No dejas de repetir trabajo ya hecho. Ah, y mejor no hablemos de que cada clase de una tabla tenga que ser un archivo, incluyendo joins, tablas proxy, etc. Hemos llegado a tener 20-30 archivos de modelos por aplicación.
Laravel no deja de estar fuertemente basado en Symfony, pero sin serlo. Una mezcla rara, un frankenstein. Por ejemplo, Laravel tiene su propio sistema de rutas (Symfony ya trae), el cual funciona francamente mal. Te limita muchísimo, porque cosas como tener grupos anidados de rutas no es posible, cosa que sí se puede en otros frameworks.
Laravel debería ser sinónimo de dump-autoload (y no es tanto culpa de Laravel sino de Composer), ya que la creación de nuevas clases requiere estar ejecutando comandos para que el PSR lo tenga registrado (¿de verdad es necesario en desarrollo?), o al menos así era necesario en los workbenchs. A veces fallaba porque se hacen referencias a la clase aún no disponible, tenías que hacer malabares, etc. Un asco para trabajar.
Esto me lleva a hablar de los paquetes. Crear paquetes es incómodo, no se trabaja de la misma forma que sobre el proyecto. Mi conclusión es que afirma ser modulable sin serlo de verdad. Por ejemplo, no tiene nada que ayude al menos en desarrollo a servir los archivos estáticos de tus paquetes.
Otro tema es el de las versiones. Laravel al estar en pañales (aunque aseguren estar ya en su versión 5), de versión en versión mucho código y paquetes pasan a ser incompatibles. Otros frameworks tienen más cuidado en este aspecto, dando alertas de uso de métodos deprecated, retrocompatibilidad hacia atrás, versiones LTS, etc. Laravel no.
Podría estar todo el día hablando, de todos los problemas que hemos tenido, pero no quiero irme sin comentar la documentación: Laravel tiene probablemente una de las peores documentaciones para un framework ampliamente usado que he conocido. En un principio pinta bien, sencilla, ¿qué puede salir mal? La falta de ejemplos para casos reales, pero sobre todo, que la gran mayoría de métodos del mismo framework no estén documentados, te hace darte cuenta de la poca seriedad que en realidad tiene Laravel.
Mi conclusión, es que Laravel debe estar programado por expertos de marketing e imagen, pero no por programadores. Saben vender el producto y su relativa sencillez. Tienen una web bonita que te entra por los ojos. Pero la realidad es que se trata de un framework poco estable, mal documentado y pobre.
Si eres un particular y vas a hacer un proyecto sencillo... bueno, puede que te sirva. Pero para una web grande de una empresa, imposible. No puedo recomendarlo.
En 10 días hemos llegado al mismo punto que estábamos en Laravel tras 3 meses. Yo sabía programar en Python, otros de la empresa no, pero igualmente, siendo un lenguaje tan fácil (aunque les esté costando), ahora, y tras tan poco tiempo, agradecemos la decisión.
#30:
Programar es fácil. Hacerlo bien también.
Programar es fácil.
Para programar se necesita aprender un lenguaje (para entender como "piensan" los computadores), conocimientos de algoritmos y estructuras de datos, etc. Luego, con que la persona tenga una buena lógica se puede programar.
Programar bien es fácil.
Una vez que se sepa programar, es decir, describir al computador cómo realizar una tarea, hay que aprender a hacerlo bien. Es decir, hacer las cosas de la manera más sencilla y simple, clara y limpia, que el código sea fácil de depurar, cambiar, añadir cosas, eliminar cosas, comentado, etc.
En otras palabras, el programa no solo debe de funcionar, sino que se debe evitar a toda costa la complejidad, (que viene de hacer las cosas mal). No poner buenos nombres a las variables o funciones, complica las cosas. Poner una porción de código en el lugar equivocado, complica las cosas. Estructuras anidadas de gran profundidad, complica las cosas. Copia y pega de código en vez de generalizar complica las cosas. un formato malo e inconsistente tamnién las complica. Todo lo que se haga que complique las cosas, por muy pequeño que sea, añade complejidad y tiene un efecto multiplicativo geométrico a medida que el programa crece. Todo lo que se haga bien también tiene un efecto multiplicativo geométrico que beneficia al programador.
Cuando las cosas se complican y no se detiene para reparar el daño (refactorizar, rediseñar, etc), se entra a una zona caótica del horror en donde cualquier cosa que se toque va a hacer mucho daño, porque se van a enredar las cosas, una modificación aquí, dañará el programa allá, etc. Hay que detenerse y repensar, no se puede seguir por el barranco.
Programar es fácil.
Para programar se necesita aprender un lenguaje (para entender como "piensan" los computadores), conocimientos de algoritmos y estructuras de datos, etc. Luego, con que la persona tenga una buena lógica se puede programar.
Programar bien es fácil.
Una vez que se sepa programar, es decir, describir al computador cómo realizar una tarea, hay que aprender a hacerlo bien. Es decir, hacer las cosas de la manera más sencilla y simple, clara y limpia, que el código sea fácil de depurar, cambiar, añadir cosas, eliminar cosas, comentado, etc.
En otras palabras, el programa no solo debe de funcionar, sino que se debe evitar a toda costa la complejidad, (que viene de hacer las cosas mal). No poner buenos nombres a las variables o funciones, complica las cosas. Poner una porción de código en el lugar equivocado, complica las cosas. Estructuras anidadas de gran profundidad, complica las cosas. Copia y pega de código en vez de generalizar complica las cosas. un formato malo e inconsistente tamnién las complica. Todo lo que se haga que complique las cosas, por muy pequeño que sea, añade complejidad y tiene un efecto multiplicativo geométrico a medida que el programa crece. Todo lo que se haga bien también tiene un efecto multiplicativo geométrico que beneficia al programador.
Cuando las cosas se complican y no se detiene para reparar el daño (refactorizar, rediseñar, etc), se entra a una zona caótica del horror en donde cualquier cosa que se toque va a hacer mucho daño, porque se van a enredar las cosas, una modificación aquí, dañará el programa allá, etc. Hay que detenerse y repensar, no se puede seguir por el barranco.
#42:
Llevo 14 años programando en Java. No sé si programo bien o mal, pero siempre intento hacer el código más claro y legible. Sin embargo sí que me río de quien asegura que programa bien.
Es decir:
Si comentas tu código e ideas soluciones a problemas que son óptimas, entonces, programas bien. En eso estamos todos de acuerdo, pero, me enseñó un jefe que tenía (que no tenía ni zorra idea de programar) que para él un buen programa es aquel que lo puede leer un mono y corregirlo si tiene un error.
Y en parte tiene razón. Me río de aquellos programadores que son cracks de la abstracción(Yo en mis orígenes les envidiaba). En Java, como OO, puedes hacer auténtica magia con los polimorfismos, reflexión, construcción dinámica etc. Puede ser que te flipes e inventes un nuevo "Spring" en tu proyecto, pero entonces y esto está garantizado, ni dios entenderá como funciona lo que has hecho.
Podías haber solucionado el problema con un par de clases, métodos sencillos y demás y sin embargo en tu afán de demostrar tu capacidad "ingeniera" te metes en el agujero de la abstracción y creas un monstruo de interfaces, dependencias, inyecciones y bla, bla, bla.
Y sé de lo que hablo, en un proyecto un colega se creó un sistema súper abstracto que solo conseguía entender él y que todo el que tocaba algo, rompía otra cosa. Lo echaron y volvieron a hacerlo todo.
Es decir:
Si comentas tu código e ideas soluciones a problemas que son óptimas, entonces, programas bien. En eso estamos todos de acuerdo, pero, me enseñó un jefe que tenía (que no tenía ni zorra idea de programar) que para él un buen programa es aquel que lo puede leer un mono y corregirlo si tiene un error.
Y en parte tiene razón. Me río de aquellos programadores que son cracks de la abstracción(Yo en mis orígenes les envidiaba). En Java, como OO, puedes hacer auténtica magia con los polimorfismos, reflexión, construcción dinámica etc. Puede ser que te flipes e inventes un nuevo "Spring" en tu proyecto, pero entonces y esto está garantizado, ni dios entenderá como funciona lo que has hecho.
Podías haber solucionado el problema con un par de clases, métodos sencillos y demás y sin embargo en tu afán de demostrar tu capacidad "ingeniera" te metes en el agujero de la abstracción y creas un monstruo de interfaces, dependencias, inyecciones y bla, bla, bla.
Y sé de lo que hablo, en un proyecto un colega se creó un sistema súper abstracto que solo conseguía entender él y que todo el que tocaba algo, rompía otra cosa. Lo echaron y volvieron a hacerlo todo.
#160:
He estado años programando y este hilo es el ejemplo claro de por qué acabé hasta los huevos de programar. No, no fueron los dolores de cabeza de programar a contrareloj, fue el ambiente laboral de trabajar con compañeros insolidarios, chulos, engreídos, egocentricos y aspergers. Parece que el mundo de la programación es una selección natural para los sociópatas, almenos en España. Así le va al gremio, que siendo un gremio que aporta mucho valor añadido a las empresas están ninguneados, yendo por subcontratas y siendo mileuristas. En los foros muy machitos y llorando por sus condiciones laborales, pero luego a la hora de dar la cara e implicarse se encongen de hombros y te dicen "paso de follones"
#64:
#59 Hay mucha incultura informática. Eso sin contar que desde que Visual Studio 2005 cambió su filosofía (gracias a fichar al genial creador de Delphi) es la herramienta más productiva que yo he visto en muchísimos años. Todos los frikis-talibanes creen que Eclipse es el sancta-sanctorum de la programación y es una basura que IBM regaló al mundo tras fracasar con su hermano comercial Visual Age 4 Java.
#103:
Para #50. Estás equivocado en cuanto a lo de las matemäticas. Las matemáticas en informática se presentan en variadas e insospechadas formas. Algoritmos muy comunes son matemáticas. Casi cualquier proceso en programación por muy común que pueda parecer a primera vista oculta un transforndo matemático.
Obviar la trigonometría, la matemática discreta, el cálculo (derivación, integración), la teoría de conjuntos, la lógica, la estadística, la programación orientada a objetos, obviar todo eso limita muchísimo como programador en muchísimas areas dentro de la computación actual.
Con una buena base matemática no solo ahorrarias mucho esfuerzo en abordar ciertos problemas sino que aportarias mejores y más eficientes soluciones en el ámbito de la programación.
(CC #69)
Obviar la trigonometría, la matemática discreta, el cálculo (derivación, integración), la teoría de conjuntos, la lógica, la estadística, la programación orientada a objetos, obviar todo eso limita muchísimo como programador en muchísimas areas dentro de la computación actual.
Con una buena base matemática no solo ahorrarias mucho esfuerzo en abordar ciertos problemas sino que aportarias mejores y más eficientes soluciones en el ámbito de la programación.
(CC #69)
Comentarios
Programar es fácil.
Lo que es más jodío es hacerlo bien.
#3 Y leer, leer, más leer, practicar, practicar y luego volver a leer de nuevo porque ha salido un nuevo megachachiframework que lo revienta para volver a entrar en el ciclo.
#5 Eso es cuando desarrollas aplicaciones web normalmente. Programar (software) no es hacer páginas web.
#6 "Hacer páginas web" si es programar. Y frameworks hay igual para web que para escritorio que para movilidad...
#9 Hacer una pagina web es maquetar. No programar. Lo que si puedes es obtener direfentes paginas web mediante un CGI, sea en el lenguaje que sea.
#6 Me da que programar, tu poco.
#13 Más que tu, seguramente.
Hacer páginas web es programar lo mismo que scripting para minecraft, ingeniería del software... también, pero no es lo mismo hacer una página web que un firmware complejo, un sistema operativo, u desarrollar usando opengl o para una GPU.
Hacer una web en PHP o con Wordpress... o usando "laravel", no es lo mismo.
#21 #13 ¿ya estais midiendoos las pollas? jajaja
#22 Él ha empezado. Pero ya está no sigo el rollo.
#24 #13 Que sois del gremio, coño
#25 lol, Lo mismo no, con el intrusismo que hay.
#25 Esa es una variación de la clásica:
"Que sois compañeros, coño"
#21 Con Laravel mejor no. En el curro intentamos adoptarlo, y llegamos a la conclusión de que había sido desarrollado por los mismos que no programan bien de los que habla #3
Ahora mismo estamos con Django y no hay color.
#33 ¿ Qué visteis de malo ? Es por que estamos evaluándolo. Saludos.
#33 #43 Yo estoy evaluando laravel 5 para un tema personal. A mi me gusta
#43 #114 #118 #212 algún día escribiré más a fondo sobre ello... pero sería demasiado que contar sobre esos 3 meses perdidos.
Uno de los principales fallos que le vimos es Eloquent, un ORM de juguete que no te permite hacer sentencias con join complejas, y que al final, te da más problemas de los que te resuelve.
Las migraciones, otro chiste malo. Mientras otros ORMs, como es normal, crean las migraciones desde los modelos, aquí pierden casi todo su sentido. No dejas de repetir trabajo ya hecho. Ah, y mejor no hablemos de que cada clase de una tabla tenga que ser un archivo, incluyendo joins, tablas proxy, etc. Hemos llegado a tener 20-30 archivos de modelos por aplicación.
Laravel no deja de estar fuertemente basado en Symfony, pero sin serlo. Una mezcla rara, un frankenstein. Por ejemplo, Laravel tiene su propio sistema de rutas (Symfony ya trae), el cual funciona francamente mal. Te limita muchísimo, porque cosas como tener grupos anidados de rutas no es posible, cosa que sí se puede en otros frameworks.
Laravel debería ser sinónimo de dump-autoload (y no es tanto culpa de Laravel sino de Composer), ya que la creación de nuevas clases requiere estar ejecutando comandos para que el PSR lo tenga registrado (¿de verdad es necesario en desarrollo?), o al menos así era necesario en los workbenchs. A veces fallaba porque se hacen referencias a la clase aún no disponible, tenías que hacer malabares, etc. Un asco para trabajar.
Esto me lleva a hablar de los paquetes. Crear paquetes es incómodo, no se trabaja de la misma forma que sobre el proyecto. Mi conclusión es que afirma ser modulable sin serlo de verdad. Por ejemplo, no tiene nada que ayude al menos en desarrollo a servir los archivos estáticos de tus paquetes.
Otro tema es el de las versiones. Laravel al estar en pañales (aunque aseguren estar ya en su versión 5), de versión en versión mucho código y paquetes pasan a ser incompatibles. Otros frameworks tienen más cuidado en este aspecto, dando alertas de uso de métodos deprecated, retrocompatibilidad hacia atrás, versiones LTS, etc. Laravel no.
Podría estar todo el día hablando, de todos los problemas que hemos tenido, pero no quiero irme sin comentar la documentación: Laravel tiene probablemente una de las peores documentaciones para un framework ampliamente usado que he conocido. En un principio pinta bien, sencilla, ¿qué puede salir mal? La falta de ejemplos para casos reales, pero sobre todo, que la gran mayoría de métodos del mismo framework no estén documentados, te hace darte cuenta de la poca seriedad que en realidad tiene Laravel.
Mi conclusión, es que Laravel debe estar programado por expertos de marketing e imagen, pero no por programadores. Saben vender el producto y su relativa sencillez. Tienen una web bonita que te entra por los ojos. Pero la realidad es que se trata de un framework poco estable, mal documentado y pobre.
Si eres un particular y vas a hacer un proyecto sencillo... bueno, puede que te sirva. Pero para una web grande de una empresa, imposible. No puedo recomendarlo.
En 10 días hemos llegado al mismo punto que estábamos en Laravel tras 3 meses. Yo sabía programar en Python, otros de la empresa no, pero igualmente, siendo un lenguaje tan fácil (aunque les esté costando), ahora, y tras tan poco tiempo, agradecemos la decisión.
#33 #21 he probado yii, laravel y codeigniter y me sigo quedando con este último por su curva de aprendizaje más rápida.
#33 Python es Dios y Django su Profeta. Luego te vas a otros frameworks y se te ocurren mil maneras de suicidarte.
#33 La cosa sería, muerte a PHP, larga vida a Python ?
#21 http://i.imgur.com/35stCZE.gif
#21 Se nota que eres todo un guruh de esos hamijo!
Una de las formas más sencillas de identificar a un flipadito que se cree que sabe programar y no tiene ni puta idea es precisamente buscar frases como la tuya de "hacer webs no es programar". Así uno os identifica rapido y os evita en los proyectos.
Te ponía yo un par de webs de nada de AA.PP. o de gestión de grandes empresas, que tienen más diseño y codificación seguramente por si mismas que todas las aplicaciones que has hecho en tu dilatada e increible experiencia programando.
A ver si alguno os entra en el cerebro que una web no es un html cutre bien maquetado, sino que muchas veces son aplicaciones de gestión, facturación, etc. ingentes cuya única diferencia con una aplicación de las que tu llamas de verdad, es que la interfaz es via web.
De verdad cuanto tonto con aires. Sigue así, te auguro en un futuro próximo tu ascenso a gerente, que ese es otro patrón tipico en España, que acaben de jefes los más inútiles, esos que luego te dirán en una planificación "pero si esto se hace en dos días, hombre"
#83 Más razón que un santo. Las aplicaciones web son igual de jodidas que las de escritorio, a veces incluso más porque tienes el factor de los distintos navegadores.
#83 A las cosas por su nombre http://es.wikipedia.org/wiki/Efecto_Dunning-Kruger
#83 Hay muchas veces que una "aplicación ingente" se queda en cuatro líneas usando un lenguaje decente.
Es el caso por ejemplo de algo con SOAP, WSDL y Java que pasa a REST con Python o JavaScript (Node.js).
Todo el mundo que conozco que ha pasado de Java a Scala me ha comentado que el código se ha quedado en 1/4 de las líneas y Scala no tiene las macros de Clojure. Tiene macros, pero son menos potentes.
Abstracciones más potentes implican volúmenes de código menores, pero una abstracción potente también requiere una mente potente por parte del programador, no todo el mundo está a la altura.
#21 te iba a decir lo mismo que #83 aunque igual algo más suave.
No es lo mismo la web del zapatero de la esquina que una aplicación. Una intranet web, un sistema gestor de lo que sea... Son aplicaciones. Sobre la nube. Pero aplicaciones. No veo ninguna diferencia a hacer una APP o un programa de escritorio.
#83 lo que tu digas, no sabes nada de mí.
Limitate a comentarios más objetivos.
#6 bueeeeno ya empezamos con el desprecio a la programación web.
He programado en diferentes lenguajes y entornos y algunas de las cosas más jodidamente dificiles han sido para webs en php. Que existan facilidades como San Wordpress no quiere decir que todo se pueda hacer bajándote temas y plugins sin rascar una linea de código.
Lo que más me jodía en mi etapa de programador web era que tipos semianalfabetos me pidieran funcionalidades bastante complejas diciendo: "esto te lo bajas de internet y en una mañana esta hecho no?".
#6 Perdona, pero cuando alguien dice muy gratuitamente 'programación web' uno se refiere a tratar varios temas de la ingeniería del software:
- Arquitecturas para soportar concurrencia de miles de usuarios a la vez, que funcione 24/7.
- Obtener el mejor rendimiento de una muy compleja capa de presentación (cada navegador web tiene sus peculiaridades, no es un windows form o similar).
- Que esta capa de presentación tiene que jugar bien con requerimientos de varios stakeholders, ya sea marketing, crawlers de buscadores, equipos de UX...
- Estando expuesto a muy serios problemas de seguridad, que te pueden llevar desde a tener problemas jurídicos a perder la misma credibilidad como negocio.
- Tener que hacer colección de toda la posible analítica de uso por parte del usuario, sin mermar en esto el perfecto funcionamiento del sistema (con todo el trabajo que lleva aparte el análisis de grandes volúmenes datos).
...
Bueno, en definitiva que 'programación web' envuelve muchas cosas, solo quería romper una lanza a favor de ello ;).
#3 Por otro lado, el buen programador (o informático en general) no es aquel que hace cosas extremadamente complicadas, si no el que hace que las cosas sean fáciles.
#c-55" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/55">#55 ¿que te permite hacer C# o Java que no te permita VB.NET?
goto #3: C# te permite hacerlo bien.
#c-94" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/94">#94 No se trata de eso, son sintaxis diferentes y hay gente que prefiere C# o Java. Que puedes hacer lo mismo? no te lo cuestiono.
#3 Es que hacerlo bien, es programar, hacerlo mal no.
#3 Te votaría dos veces.
#3 Es difícil, porque son lenguajes artificiales, punto.
#3 He venido aquí para decir lo mismo. Yo pensaba que sabía programar, hasta que me puse a programar videojuegos.
#3 Lo que es jodido realmente es pensar. Una vez que piensas bien, programar es como aprender inglés en 300 palabras
Aprendí a programar a los 16 años con el manual del Amstrad, (un basic en rom muy potente para la época) y no es difícil. No es verdad que el basic enseñe malos hábitos de programación,los malos hábitos los coge la gente predispuesta a cogerlos. Un mal programador que llama a gotos probablemente tb será alcohólico y ludópata
Yo huía de los goto y competíamos por hacer el programa más rápido y a la vez más pequeño y elegante.Codigo indescifrable e inentendible sin comentar.
No sabíamos algoritmia: Los inventábamos. Para las cosas que no alcanzaba el basic, ensamblador llamado con un CALL.
ah! que tiempos aquellos.Nada es dificil si te apasiona,nada.
#14 El que el basic copiando cosas del algol como el qbasic y otros es muy diferente al basic 2.0 u otros de baja versión de los micros o el gwbasic o basica
En estos se tenía que poner número de línea sí o sí y para procedimientos usabas el goto y para funciones el gosub. No existían ni definiciones de procedimientos, ni de funciones, wheres ni do ultil ni nada de eso. El for to next y "if then" aninados "gotos y gosub.. return" y se acabó. Claro que daba malos hábitos hasta que te ponías bajo pascal y no podías creer que no hiciera falta usar ni un solo goto es más, costaba quitarse la manía y ver que realmente no se necesita nunca con un lenguaje con esos controles del flujo... Luego el basic en los PC evolucionó terriblemente con el qbasic y el quikbasic en cuanto a controles de flujo y a partir de ahí al visual..
'*****
no alcanzaba el basic, ensamblador llamado con un CALL.
'*****
O con montones de peek y poke Más operaciones matemáticas con los valores curiosas a veces...
Para #14. Pásate por aquí : http://www.sdlbasic.altervista.org/main/
Para visualizar restultados gráficos rapidamente en pantalla con aceleración 2D incluida va de primera. Se puede experimentar incluso con sonido en un montón de formatos 'vintage' incluido el mp3 o el ogg.
Ejemplos de código : http://sourceforge.net/projects/sdlbasic/files/software/
Carga la demo de la presentación del 'Shadow of the Beast' es impresionante tanto el resultado como la logitud del código.
No es en PC pero puedes verla aquí :
#14 Grandísimo comentario.
Sin embargo, te faltaba añadir también Prolog embebido abusando del operador corte.
#14 ...cuando los hombres eran hombres y programaban sus propios drivers...
#14 "Un mal programador que llama a gotos probablemente tb será alcohólico y ludópata", brutal.
Saludos a todos. 28 añitos ya dedicado a esto de programar y he visto de todo. Para mi, programar bien son dos cosas principalmente. La primera, que funcione. La segunda, que mañana llegue otro programador y no tenga que rehacer el programa de nuevo por que tu código es una basura. Da igual el lenguaje , framework o herramienta.
Es mi más subjetiva y personal opinión.
#44 Luego está programar mal, y programar mal nivel "el código del hijoputa ese" del que cuentas anécdotas de su código.
#49 Los grupos de delincuentes parte piernas no saben que nicho de mercado se están perdiendo con esos malos programadores
Es difícil meterse porque:
- Hay muchos idiomas y el lego no sabe por cual decidirse al principio.
- Unos idiomas son mejores para una cosa y otros para otra, y todos tienen profetas que los defienden por encima del resto.
- Hay que pensar de modo diferente, muchas veces en términos de si/no, y siempre en una estructur diferente a los "idiomas" a los que la gente está habituada (excepto el lenguaje matemático)
- Hay que ser muy ordenado, constante, aplicado, leer mucho, etc...
- Llega un momento en el que todo falla, no se encuentra el error por ninguna parte y parece que nadie puede ayudarte (ahí lo dejan muchos)
- Cuando al fin consigues programar algo, descubres que habría sido mejor en otro lenguaje o que alguien ya lo había hecho antes que tu, mejor, más bonito y además con prestaciones que le dan mil vueltas al tuyo.
...
En cualquier caso creo que cada vez es más necesario tener alguna noción sobre programación y es una de las grandes carencias del sistema educativo.
#19 Eso, metámosles programación a los chavales en el colegio para que acaben siendo carne de cárnica (valga la redundancia) en un futuro.
Para programar, te tiene que gustar lo que haces, porque si no, haces unos truños de p... madre, que es exactamente lo que hago yo. Como en su día cometí la gran cagada de dedicarme a ésto, ahora me dedico a que las cosas simplemente funcionen, con la ley del mínimo esfuerzo, sea lo más óptimo o no.
#19 "Llega un momento en el que todo falla, no se encuentra el error por ninguna parte y parece que nadie puede ayudarte (ahí lo dejan muchos)"
Eso en el pasado era frustrante, ahora con sitios como Stack Overflow tienes muchos más recursos para resolver problemas que en el pasado
#19 No sé... no estoy de acuerdo en todo..
- Hay muchos idiomas y el lego no sabe por cual decidirse al principio.
Pues para empezar hay mucha gente que suele recomendar Python, un lenguaje versátil, limpio y fácil de aprender. De todos modos, yo lo enfocaría de otro modo: Si lo que quieres es desarrollar apps para móviles Android, por ejemplo, no te queda otra que Java (O C++ si quieres hacer la app nativa). No hay muchos más lenguajes donde elegir. Idem con otros ejemplos parecidos.
- Unos idiomas son mejores para una cosa y otros para otra, y todos tienen profetas que los defienden por encima del resto.
Los profetas, como te refieres a ellos deberían ser ignorados ... Hoy día con cualquier lenguaje puedes hacer de todo o casi de todo. Para lo que alguien podría necesitar en el desarrollo de una app, cualquier lenguaje podría valerte.
- Hay que pensar de modo diferente, muchas veces en términos de si/no, y siempre en una estructur diferente a los "idiomas" a los que la gente está habituada (excepto el lenguaje matemático).
Aquí no te acabo de entender, no sé a qué te refieres. ¿Podrías explicarlo?
- Hay que ser muy ordenado, constante, aplicado, leer mucho, etc...
+1 totalmente de acuerdo
- Llega un momento en el que todo falla, no se encuentra el error por ninguna parte y parece que nadie puede ayudarte (ahí lo dejan muchos)
Si un programador no sabe utilizar un debugger, no debería llamarse a sí mismo programador. (Ni nadie creo que se lo llame).
- Cuando al fin consigues programar algo, descubres que habría sido mejor en otro lenguaje o que alguien ya lo había hecho antes que tu, mejor, más bonito y además con prestaciones que le dan mil vueltas al tuyo.
Pues si es Soft Libre, que el aspirante a programador coja el código fuente y lo lea. Yo he aprendido muchas cosas leyendo código de otras personas.
#c-56" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/56">#56 Lo siento pero estas terriblemente mal informado.
Las cosas que salen para c# salen al mismo tiempo para VB. Ejemplo, cuando salio .NET 4.5 se pudo usar async y await al mismo tiempo en ambos lenguajes.
El resto de lenguajes como F# y demas si que van "con retraso".
En cuanto a rendimiento, todo se traduce al mismo lenguaje intermedio para la maquina virtual. Es exactamente igual. El ILSpy te abre dlls y te permite ver el codigo indistintamente en c# o vb.net.
Por eso digo que hay mucha ignorancia con VB. A dia de hoy solo difiere de C# en sintaxis, nada mas.
Hablar de VB6 es tan ridiculo como comparar un linux del 2000 con Windows 8.1, por ejemplo.
No tiene pies ni cabeza.
#59 Hay mucha incultura informática. Eso sin contar que desde que Visual Studio 2005 cambió su filosofía (gracias a fichar al genial creador de Delphi) es la herramienta más productiva que yo he visto en muchísimos años. Todos los frikis-talibanes creen que Eclipse es el sancta-sanctorum de la programación y es una basura que IBM regaló al mundo tras fracasar con su hermano comercial Visual Age 4 Java.
#64 No hay nada comparable a Visual Studio, ni de lejos, y menos para trabajar en equipo.
Dicen que la herramienta de desarrollo, aún en pañales, para android que ha lanzado google tiene pinta de que en poco tiempo va a estar a la altura de VS
#64 Otros frikis-talibanes asocian eclipse a Java. Eclipse es una puta mierda, si, pero sabes que hay otros IDEs mucho mejores? Conoces el Intellij Idea? Hay que diferenciar entre lo que es un lenguaje y lo que es un IDE.
#64 Tienes toda la razon del mundo, Visual Studio es el mejor entorno de desarrollo que conozco, y ahora con la version 2015 casi me toco cada vez que acabo un desarrollo, y si ademas haces algo para web la implementacion con azure funciona perfectamente, con lo que en dos clicks puedes tener tu pagina web en internet de manera gratuita ( Azure te cobra por uso, asi que lo subes, lo pruebas y luego lo paras si no quieres gastar pasta hasta tenerlo terminado )
#59 Se puede trabajar bien y mal en cualquier lenguaje de programación. Los chapuceros lo serán hasta en la plataforma más productiva. He visto algún animal poniendo Goto's en VB.net.
#c-59" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/59">#59 Si compilas el mismo programa en C# y en Visual Basic el codigo en C# es mas eficiente y mas rapido.
Es cierto que MS da soporte a ambos y basicamente se puede hacer los mismo en un lenguaje que en el otro, pero en las futuras versiones y desde hace tiempo estan apostando claramente por C#.
No lo digo por decir, sino porque he asistido a conferencias de Plain Concepts acerca de VNext y claramente Visual Basic lo estan dejando un poco de lado.
#59 "En cuanto a rendimiento, todo se traduce al mismo lenguaje intermedio para la maquina virtual. Es exactamente igual." En esta parte eres tú el mal informado. Que el lenguaje intermedio sea el mismo no tiene mucho que ver con el rendimiento. No digo que VB sea más lento, que ni idea, lo que digo es que el compilador de uno u otro puede generar un código intermedio más o menos eficiente a partir de una versión equivalente del código.
#59 yo digo los conocimientos que el Guille en su momento dió en una seerie de charlas a las que acudí. Considero que sabrá del tema.
Programar es fácil. Hacerlo bien también.
Programar es fácil.
Para programar se necesita aprender un lenguaje (para entender como "piensan" los computadores), conocimientos de algoritmos y estructuras de datos, etc. Luego, con que la persona tenga una buena lógica se puede programar.
Programar bien es fácil.
Una vez que se sepa programar, es decir, describir al computador cómo realizar una tarea, hay que aprender a hacerlo bien. Es decir, hacer las cosas de la manera más sencilla y simple, clara y limpia, que el código sea fácil de depurar, cambiar, añadir cosas, eliminar cosas, comentado, etc.
En otras palabras, el programa no solo debe de funcionar, sino que se debe evitar a toda costa la complejidad, (que viene de hacer las cosas mal). No poner buenos nombres a las variables o funciones, complica las cosas. Poner una porción de código en el lugar equivocado, complica las cosas. Estructuras anidadas de gran profundidad, complica las cosas. Copia y pega de código en vez de generalizar complica las cosas. un formato malo e inconsistente tamnién las complica. Todo lo que se haga que complique las cosas, por muy pequeño que sea, añade complejidad y tiene un efecto multiplicativo geométrico a medida que el programa crece. Todo lo que se haga bien también tiene un efecto multiplicativo geométrico que beneficia al programador.
Cuando las cosas se complican y no se detiene para reparar el daño (refactorizar, rediseñar, etc), se entra a una zona caótica del horror en donde cualquier cosa que se toque va a hacer mucho daño, porque se van a enredar las cosas, una modificación aquí, dañará el programa allá, etc. Hay que detenerse y repensar, no se puede seguir por el barranco.
La programación es simplemente la expresión algebraica de un proceso, según la capacidad analitica y definitoria de cada cual, asi sera su capacidad para afrontar un determinado nivel y el algoritmo que desarrolle.
#10 joder ¿yo hago eso?
Llevo 14 años programando en Java. No sé si programo bien o mal, pero siempre intento hacer el código más claro y legible. Sin embargo sí que me río de quien asegura que programa bien.
Es decir:
Si comentas tu código e ideas soluciones a problemas que son óptimas, entonces, programas bien. En eso estamos todos de acuerdo, pero, me enseñó un jefe que tenía (que no tenía ni zorra idea de programar) que para él un buen programa es aquel que lo puede leer un mono y corregirlo si tiene un error.
Y en parte tiene razón. Me río de aquellos programadores que son cracks de la abstracción(Yo en mis orígenes les envidiaba). En Java, como OO, puedes hacer auténtica magia con los polimorfismos, reflexión, construcción dinámica etc. Puede ser que te flipes e inventes un nuevo "Spring" en tu proyecto, pero entonces y esto está garantizado, ni dios entenderá como funciona lo que has hecho.
Podías haber solucionado el problema con un par de clases, métodos sencillos y demás y sin embargo en tu afán de demostrar tu capacidad "ingeniera" te metes en el agujero de la abstracción y creas un monstruo de interfaces, dependencias, inyecciones y bla, bla, bla.
Y sé de lo que hablo, en un proyecto un colega se creó un sistema súper abstracto que solo conseguía entender él y que todo el que tocaba algo, rompía otra cosa. Lo echaron y volvieron a hacerlo todo.
#42 Te cuento la verdad:
Las cosas esas de abstracciones y interfaces dependencias etecetera.... no se hacen para demostrar tu capacidad ingeniera... Se hacen para trabajar MENOS. Para ampliar las funcionalidades mas facilmente, para no duplicar codigo, para no duplicar errores, para no tener problemas al cambiar de entorno...
Pero si, estando en el mundo en el que estamos, en el que cualquier mono deseoso de cacahuetes puede ponerse a cortar y pegar por doquier, no merece la pena...
Pero vamos, que el hecho de que el 90% sean monos programadores es lo que hace que la programacion para monos triunfe y sea la 'buena'. Unido, claro esta, a que ni dios va a durar 5 años en la empresa o, al menos, programando pq al mono programador le apesta programar.
Y para estar enseñando continuamente como usar librerias propias es mejor no hacerlas.
Aunque bueno, en algunas empresas no usan ORM*s ni frameworks* porque no los entiende cualquier mono...
* Herramientas que se inventaron para poner coto a los malos programadores.
#60 Mientras que tienes razón, hay una tendencia a la sobreingeniería en muchos lugares. Las abstracciones en lo posible deben usarse como bloques de construcción de las cosas más complejas (frameworks, objetos importantes de la aplicación, etc.).
Ahora bien, si a la hora de ponerse manos a la obra, sumar dos números te supone tener que instanciar doscientos objetos diferentes, usar doscientas factorías y utilizar doscientos tipos de datos, hay algo que está mal ahí.
En muchas ocasiones hay soluciones alternativas simples que funcionan mejor y son más fáciles de mantener que las arquitecturas catedralicias overkill.
#87 Sin duda, pero yo he trabajado con gente que siguiendo esa filosofia hacia todo en bonitas funciones de 3000 lineas que cualquier mono puede seguir hasta que se vuelva loco y con la alegria que da que NINGUN error se arregle cambiando solo una cosa....
Lo he visto, mucho.
#60 Yo tengo los conocimientos para entender y realizar este tipo de software. No tengo problema para abstraerme cuando es necesario. Y esa es la palabra NECESARIO.
Casi todas las soluciones, diría el 90% (y es una estadística metafórica) de los problemas, no requieren una solución abstracta sino funcional. Ser un experto y querer demostrarlo siempre es un error que cometen los que tienen un control absoluto de la herramienta.
Es de hecho uno de los grandes males de los proyectos, junto con los tiralineas, aquellos que se creen que pueden introducir su catálogo de patrones en cualquier sitio.
Edito: Es cierto, los Frameworks los preparan para que cualquiera se pique cualquier cosa sin casi saber programar. Pero en los grandes proyectos, el peso funcional no está en el uso de tal fw, está en dar soluciones a problemas funcionales y ahí es mejor ser claro y directo que andarse por las profundidades de la ingeniería informática.
#96 Pues sorry, pero me he cruzado en mi vida laboral con mucha gente que no puede aplicar nada ni cuando es NECESARIO.
Y esa gente es mayoria. Y el hecho de que esa gente sea mayoria limita la utilizacion de buenas practicas y cambia el significado de 'buen codigo'.
Y por supuesto que existe la sobreingenieria, pero es un problema mucho menos habitual que el trabajar con gente a la que no le gusta su trabajo, se la suda, y no quiere pensar.
Que ganas de picarse todos con todos:
Los viejos con los nuevos, los lenguajes populares con los impopulares, los que hacen desarrollo web con los que hacen escritorio.
con quien más estoy de acuerdo es con #c-42" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/42">#42.
Puedes complicar infinito tu código pero la mayor parte del tiempo estarás preparándolo para mantenimientos o ampliaciones que nunca llegarán. Es mucho más eficiente hacerlo simple y aumentar su complejidad y abstracción a medida que el programa lo requiere.
Yo he hecho muy buenas aplicaciones con VB6 para hospitales con muchos usuarios y siguen funcionando después de 8 años. Luego me pasé a C# y mejoré en estructuración de código pero perdí muchísimo en agilidad.
Los frameworks (propios o de terceros) ayudan pero también te hacen perder control si son de terceros a no ser que tengas el código fuente y tiempo ilimitado.
La realidad es que los programadores construimos el mundo que se mueve actualmente y la gente no es consciente. Da igual si haces wordpress y modificas el functions.php de tu tema o programas routers de seguridad extrema, lo importante es que nuestro trabajo perdura y hace más fácil la vida a mucha gente.
¿Es jodido? Un montón, tienes que tener paciencia infinita cada vez que algo no sale y aprender a dejar cosas de lado para volver otro día.
A partir de ahí que cada uno programe en lo que le de la gana...
#85 "Da igual si haces wordpress y modificas el functions.php de tu tema o programas routers de seguridad extrema, lo importante es que nuestro trabajo perdura y hace más fácil la vida a mucha gente"
que bonito me he imaginado a todos los de los comentarios unidos cantando a lo de are the world we are the children
#42 Pues no estoy para nada de acuerdo con tu jefe. Tanto la sobreingeniería, utilizar recursos que no son ni de lejos necesarios para hacer algo, como la infraingeniería, utilizar lo más básico para que el "mono" pueda entenderlo, tienen problemas, la primera generalmente a corto plazo, y la segunda a largo porque lo de mil monos picando teclas te acabarán escribiendo las obras de Shakespeare está muy bien pero no sucede en la realidad. Un jefe evidentemente preferirá la segunda, menos coste y algo que funciona, y que seguramente cuando deje de funcionar ya será problema de otro.
La ingeniería de software está para algo y saber cuando se deben aplicar soluciones sencillas y cuando y como las abstractas y complicadas que, aquí está la clave, requieren más conocimientos para entenderlas, es lo que diferencia a alguien que lo hace bien de alguien que lo hace mal. Por ejemplo la programación en paralelo es compleja, pero claramente hay un conjunto de problemas que requieren de su uso para solucionarlos de forma eficiente, pero no pidas que un mono te diseñe o mantenga un sistema áltamente paralelizable porque no sucederá.
Que algo sea complejo no es malo si esa complejidad está bien aplicada, ¿qué no lo puede entender todo el mundo?, cierto, que tu colega que hizo un sistema super abstracto lo hizo mal, cierto, pero que un colega tuyo lo haga mal no quiere decir que no se pueda hacer bien, sino que simplemente él no lo supo hacer en ese caso en concreto. Lo de "cuando tengo un martillo todos los problemas son clavos" no suele funcionar bien en la programación ni en cualquier otro ámbito.
#42 Siempre he pensado que hay que comentar el código, sobretodo funcionaliades complejas. Pero hay gente que pasa, yo creo que para que nadie entienda su código y tomar una posición de poder en la empresa.
#42 si comentas tu código lo estás haciendo mal, el código debe ser la misma documentación. Si el código necesita documentación adicional es que está mal hecho.
Me da risa los que se llaman programadores hoy en las carnicas, con su titulo universitario bajo el brazo, y solo son malos usuarios de bases de datos y frameworks que los alejan tanto de la máquina que hasta la pierden de vista
los programadores de la Demoscene, eran programadores. El resto sois putos usuarios
#15 Cierto. Pero aún es posible hacer arte con frameworks. Template metaprograming con Qt, por ejemplo. Como siempre el lenguaje es un mero vehículo. De las bases de datos mejor nos olvidamos.
#15 bueno la gente se gana la vida, y alguna vez he visto a gente que se gana la vida con el ensamblador y son unos cracks en eso, pedirle a un amigo que trabaja "tan lejos de la maquina" que le hicera una aplicacion para esto y aquello por que el se puso y se perdia y no tenia tiempo para aprender
asi que RESPECT
#15 Maldito... he estado apunto de votarte positivo...
#15 Positivo sólo por la última frase. Lo que hace esa gente a veces es puta magia.
Cuánto programador estrella se ve por aquí. Cuánto crack. La mayoría de aquellos que dicen que programan bien y los demás mal, son los mismos que cuando Messi falla un gol dicen -pues yo eso lo metía-.
No sabía que en España también había programadores de barra de bar.
#46 Jajaja, ya te digo. Mucho "programar es facil, solo hay que ser ordenado", pero eso díselo tu a tu tiempo libre, cuando te aprietan con tiempos irrisorios, requisitos inexistentes o poco definidos y jefes de proyecto todólogos que además, se meten en los jardines de la arquitectura software o de sistemas. Al final, que algo salga bien (bien como le gustaría a uno) va SIEMPRE en detrimento de tu tiempo libre.
De verdad que cuanta estupidez junta he leído aquí.
Todos gurus de la leche, todos programais con la punta del pito y currais en Google, por eso España es meca de la programación y no La India.
#46 no se podía definir mejor. Me copio lo de "programador de barra". Muy grande
Yo creo que te tienen que gustar la informática y las matemáticas y éstas en España no son muy queridas por los estudiantes.
#4 gustarle además el inglés. Que muchas sentencias y comandos están pensados en palabras en ese idioma.
#29 Pues sí.
#29 No sólo esto. Toda la documentación está en inglés. Si quieres esperar a que alguien te lo traduzca al castellano, estarás siempre a rebufo del resto.
#4 De matemáticas no mucho, yo lo considero un mito. No he tocado una fórmula más compleja que una regla de tres en mucho tiempo. Todo dependerá de el tipo de programa que estés desarrollando, claro.
#50 En eso tienes razón. Yo no soy programadora, mis conocimientos son limitados y para los programillas que me he hecho (para utilizarlos en mi trabajo) por lo menos la trigonometría y geometría las tenía que tener dominadas.(además de las funciones lógicas claro).
Para #50. Estás equivocado en cuanto a lo de las matemäticas. Las matemáticas en informática se presentan en variadas e insospechadas formas. Algoritmos muy comunes son matemáticas. Casi cualquier proceso en programación por muy común que pueda parecer a primera vista oculta un transforndo matemático.
Obviar la trigonometría, la matemática discreta, el cálculo (derivación, integración), la teoría de conjuntos, la lógica, la estadística, la programación orientada a objetos, obviar todo eso limita muchísimo como programador en muchísimas areas dentro de la computación actual.
Con una buena base matemática no solo ahorrarias mucho esfuerzo en abordar ciertos problemas sino que aportarias mejores y más eficientes soluciones en el ámbito de la programación.
(CC #69)
#103 Totalmente de acuerdo.
#50 Hace poco en mi trabajo tuve que desarrollar algo y necesité de las matemáticas. En un mapa de google tuve que hacer unos cálculos para calcular un área comprendida entre dos lineas.
#50 Esto me recuerda a la eterna discusión de comentarios sí o código que en sí mismo es autoexplicativo. Si quieres hacer programas tipo "gestión", no estás haciendo nada del otro mundo, si quieres programar algo que vaya más allá sí vas a tener que usar comentarios y sí tendrás que usar matemáticas.
Además hay un problema añadido que a veces no te das cuenta que un problema que estás resolviendo es realmente un problema matemático que además ya tiene una solución bien conocida y eficiente.
#50 las matematicas son fundamentales, asi como el pensamiento logico, no es que resuelvas formulas, es que sepas reducir problemas fisicos a numeros y logica.
Experiencia buscando programadores. Entrevista. Escribe en un par de renglones por qué quieres trabajar en esta carnicería.
El que se defiende escribiendo, suele programar decentemente. Programar es escribir en un lenguaje determinado, así que no es solamente matemáticas sino también otras cosas como, por ejemplo, ser ordenado.
#28 No puedo más que estar de acuerdo.
#28 y documentar el código cuando corresponda.
#28 razón toda tienes la.
Esto se llama la curva del cambio y sirve para explicar el aprender a programar, a conducir, a no cagarte en los pañales....
Lo que explica puedes aplicarlo a muchos más trabajos, en realidad a todos los que se requieren de conocimiento y formación continua. A un médico, un químico, físico, etc tambien pasa por las mismas fases.
#89 Hasta donde yo se, para muchas disciplinas, los niños son más eficientes aprendiendo que un adulto en el sentido de que ellos no se cuestionan si lo que les están enseñando es lógico o no, si tiene sentido o no, o de porque tiene que ser de esta manera y no de otra. Esto es así desde los conceptos más básicos.
Aprender a programar, a usar un lenguage, no se diferencia mucho de aprender a usar un idioma para comunicarse con otras personas. Los niños simplemente lo asimilan, lo absorven como si fuesen una esponja. Es algo que incluso los navi, la raza humanoide de la luna Pandora saben: "Es difícil llenar una taza cuando ésta ya está llena."
Naturalmente que no vas a poner a un niño a programar una aplicación que use algoritmos, o funciones avanzadas, pero es que la pregunta del enunciado dice "¿Por qué es tan jodidamente difícil APRENDER a programar"?
Aprender a programar y programar en profundidad son 2 conceptos completamente diferentes.
Porque como en el cine, la fotografía o la música, se necesita talento y disciplina.
Creo que #31 es el que mejor lo ha resumido. Talento y disciplina.
...Aparte. Lo más odioso de la informática son los pardillos que salen de la universidad con vocación evangelista y que van presumiendo que ellos saben de design patterns.El service locator, el dependency injection, el factory method, el unit of work...
Pero gilipollas, ¿no te das cuenta que todo eso lo inventamos los que ya programabamos antes de existir el java?
Señor señor...
#66 Y muchos de esos patrones surgen debido a las limitaciones de determinados lenguajes, en otros símplemente muchos de esos patrones no son necesarios, porque se pueden hacer las mismas cosas de forma más directa/sencilla.
#72 menuda chorrada acabas de soltar. Claro claro, los patrones existen por limitaciones del lenguaje, si si. O sea, el MVC, que se usa en todas las plataformas, son por limitaciones. Es mucho mejor no usar patrones, esta misma página de meneame, se podria mezclar todo en una jsp/php/asp o lo que te de la gana: mezclamos html, javascript, php y sql, todo mezcladito en el mismo archivo, ni MVC ni hostias, verdad?
En los 80 los niños programaban en BASIC para divertirse, ahora ven La Voz, no es dificil, es que somos cada vez más tontos.
Para #54. Es que es ridiculamente incomparable un flamante Commodore 64, ZX Spectrum, Amstrad CPC o MSX con lo que se le ofrece ahora a los más 'jovenes' :
Porque se empieza cuando uno ya es demasiado mayor.
#2 En mi opinión, para muchas disciplinas, eso de que los niños son más eficientes aprendiendo que los adultos es un mito.
A parte, programar no es sólo aprender un lenguaje. También necesitas aplicar otras disciplinas y, sobre todo, sentido común, que es una habilidad que acostumbra a desarrollar con la edad.
No digáis "jodidamente", ¡coño!. Se dice "difícil de cojones" No digáis "jodidamente", coño
No digáis "jodidamente", coño
delbarrio.euAquí os dejo una joya:
Code Complete: A Practical Handbook of Software Construction, Second Edition
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
Para mi programar es muy complicado y eso que llevo años...
A mi me gustaba programar el video cuando los VHS pero ya lo he dejado, hace años que no programo...
Yo veo la programación como el que sabe tocar un instrumentos, o tiene el oido o no lo pillas en la vida. Pues en programación o ver las estructuras en tu cabeza o no tienes na que hacer.
Viendo como funcionan algunas aplicaciones y videojuegos desde su ingreso al mercado, no debe ser muy difícil...
No acabo de pillar el truco a las modulaciones, al menos no del todo. Lo mismo me ha pasado con el tema de los punteros -perdón por el pareado tonto- pero los punteros son puñeteros 
.
En serio, es difícil por muchas razones. Muy buena apreciación de ahvega en su comentario #91 curiosamente yo tengo ese problema también con el piano.
Salu2
¿Quién escribió este jodidamente fucked titular? ¿Robert de Niro?
Y porqué es tan
jodidamentejodido encontrar adverbios de modo bien traducidos al castellano? Tengo que venir yo de tabilán ?Aqui vuelve a salir a relucir la mentalidad del programador: Yo molo, los demas hacen mierda.
Que dificil es encontrar a un programador que no se considere la hostia, que no considere a los demas paquetes, y que no sea un taliban defensor a ultranza de la tecnologia que conoce (y por supuesto, un critico destructivo con el resto de las tecnologias).
¡Viva el programador medio!
#76 Yo conozco a verdaderos cracks y la característica común a todos ellos es que aconsejan el lugar de atacar o presumir. Normalmente los que creen que saben la hostia son niñatos que no son conscientes de todo lo que no saben.
A mi programar me recuerda a los ejercicios de lógica que hacía en filosofía en bachiller. Si no p entonces q (¬ p → q), con un poco más de complejidad, claro.
#99 Mira mi comentario #100 jeje
#100 A mi la investigacion quimica farmaceutica me recuerda a cocinar un huevo frito solo que con un poco mas de complejidad.
Pues eso
Porque juntar letras o picar código, eso puede hacerlo cualquiera.
Pero el verdadero arte, ya sea escribir literatura o programar, sólo está al alcance de unas pocas mentes privilegiadas.
Ojalá fuera cierto eso de que muchos abandonan... Por que madre mía lo que se ve por ahí.
Si es que es difícil es porque no han inventado aun la forma de hacerlo lo suficientemente facil.
Y para cuando los talibanes que dicen que python es mejor y que c aplasta a c++?
Por que ya vi uno que dijo que hacer html no es programar.
Si vieran los programas que vi en gwbasic, cosas en 3D y animaciones que corrían a la misma velocidad en cualquier pc, partículas, cientos de ellas y no ponían lento el pc
#40 Por que ya vi uno que dijo que hacer html no es programar
Es que HTML no es un lenguaje de programación, es un lenguaje de marcado. Maquetar una web NO es programar.
#57 #93 Talibanes, ya me están juzgando, no se lo que es, deben pensar que soy un sicologo, no me corten la cabeza por decir que un lenguaje de marcado se usa para programar.
Mi punto:
10 print "Hola"
HTML - CSS
Hola
Bajo instrucciones se imprime lo mismo, logicamente no se puede hace los mismo con gwbasic que con html, ahora si le aplicamos comportamientos, como que cuando una resolución X esconda contenido, o se pase el puntero encima ilumine una casilla... esto que es?
#40 Y tiene razón.
Escribir HTML y CSS a mano no es programación ya que HTML no es un programa, ni puedes ejecutar nada.
Si programas código que genere HTML desde el servidor sí es programar. El Javascript que pueda haber empotrado en un HTML sí es programar.
Es así de sencillo. El hecho de que hayas dicho esto deja muy claro que no sabes lo que es.
por qué es tan dificilmente imposible conseguir un sueldo decente para un programador? (al menos en españa)
#75 Depende de que consideres un sueldo decente. No obstante, la respuesta es facil: Estamos en un pais que considera al programador el ultimo eslabon de la cadena, el paleta de la profesion. Esto era asi en tiempos de las vacas gordas porque daba igual entregar basura, lo que vendia era la consultoria y los analisis infumables (e imposibles), y con una demanda creciente que hacia que con 2 años programando o menos ya "ascendias". Hoy en dia la cosa esta mejorando, y se empieza a valorar un poquitin al "picateclas".
Pero todavia hay gente que se cree que se puede liderar un proyecto o realizar una estimacion/analisis sin ser previamente un experimentado programador. Poco a poco, tiempo al tiempo.
#79 y dale con España ... he hablado con americanos y me dicen que eso de la programacion y la informatica alli tampoco es que este tan bien pagado ... has visto la pelicula "trabajo basura", en fin se llevan todo la pelicula diciendo "si somos unos genios de la programacion porque ganamos tan poco" y al final le meten fuego a la empresa ... en fin ... que daño hace la publicidad al par de billonarios todos quieren ser como ellos, pero lo son precisamente debido a esto
#79 Se puede "gestionar" un proyecto sin haber sido programador, pero efectivamente no se puede "liderar". Es más, el perfil de gestor, al no ser técnico, en otros países no tiene la misma banda salarial: el programador es la estrella, el gestor de proyecto, pues poco más que un mero contable.
Para ello, hace tiempo que se separó la gestión de la metodología. La gestión se preocupa del budget, hacer el gantt, gestionar recursos, gestionar milestones,... La metodología es la que lleva el día a día, y la que requiere un líder. Un gestor de proyecto necesita la ayuda del equipo para realizar las estimaciones.
En cuanto al análisis, para hacer un buen análisis funcional no siempre es bueno haber sido programador, aunque sí totalmente necesario haber estudiado informática para conocer las técnicas. Ahora mismo estoy lidiando con supuestos "analistas" que vienen de económicas, y que aunque han programado toda su vida, no saben lo que es normalizar un modelo, ni saben tener una visión un poco más amplia de las consecuencias de las decisiones que toman. Por el contrario, he tratado con analistas que eran ingenieros informáticos pero que no se habían dedicado a programar, pero eran estructurados y organizados, y la verdad es que muy bien.
#79 El problema es que en las empresas españolas, quieren que asciendas y lideres proyectos, sino no te van a pagar bien. Ellos no conciben a un programador con 20 años de experiencia, ni lo valoran. Que pasa si yo quiero ser siempre programador? Pues eso lo ves fuera de españa, donde yo he tenido un colega que podríá ser mi padre y estaba picando código como yo.
#75 es muy simple: oferta y demanda. Si hay un programador dispuesto a cobrar 900€, no le van a pagar 2000€ aunque sea buenísimo. Si todos nos varloraramos mas a nosotros mismos, mas nos pagarian. Pero como eso no ocurre, me tuve que largar del país.
Yo empecé con una calculadora HP, después un VIC20 Commodore con BASIC, GWBasic, después TPascal de Borland y posteriormente Delphi. Antes los programas, ordenadores y calculadoras venían excelentemente documentados y con manuales para aprender. Después en la carrera implementaba todos los cálculos (fundamentalmente de estructuras e instalaciones), también algún juego como damas y reversi etc por afición, etc.
Lo curioso es que aunque me gustan las matemáticas y la física nunca había tenido formación en algoritmia y años después, estudiando por libre, descubrí que aunque tenía buena intuición... para muchas cosas existían soluciones más rápidas, eficaces y mejores, etc. En fin, que para programar bien IMHO será una combinación de personalidad analítica, algo de intuición y formación en algoritmia. En fin que tranquilos, que profesionalmente lo he dejado y ahora solo programo por hobby
#70 Aqui otro que empezó con Vic. 3583 bytes free!
#77 ** CBM BASIC V2.0 **
3583 BYTES FREE
READY.
_
¡Como Linus Torvalds!
Si aprendes a programar en Miranda tienes la vida asegurada...
#27 o lisp, también es un amor
#27 #58 ¿ Porqué ?
Forma de distinguir a alguien que trabaja de alguien que sólo intenta aparentar que sabe: el poser sólo habla de lenguajes.
Lo difícil no es "programar" sino hacerlo bien.
Cualquiera puede hacer un bucle para calcular el máximo común divisor de dos números. Hacerlo en tiempo logarítmico, ya es otro cantar (aun consultando la wikipedia).
Supongo que el hecho de no enseñar lógica en el colegio influirá bastante.
Joder que largo. Me lo guardo para despues.
Programar es tan facil q lo puede hacer un niño. Lo dificil es mantenerse rocoso y documentar el codigo
El desierto de la desesperacion, me ha tocado en el alma
Los programadores hacen que sea difícil a propósito para limitar la entrada de competidores. Hoy en día programar es igual de sencillo que navegar la web, gracias a lenguajes como Visual Basic, pero como a los programadores no les conviene hacen todo lo posible para marginarlos.
#1 Visual Basic es como los libros esos de pinta y colorea.
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/7">#7 Que graciosa la ignorancia... dime, ¿que te permite hacer C# o Java que no te permita VB.NET?
Venga, espero la respuesta.
Funciones lambda, mocking, Linq (uppps eso en Java no existe), programacion asíncrona, paralelismo avanzado, etc... VB no es como hace 15 años.
Quizas no te guste la sintaxis, pero te permite hacer lo mismo o mas que Java (me atrevo a decir mas por Linq)...
#c-55" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/55">#55 la cuestión ahora mismo con .NET es que la gente se está decantando mucho más por C# que por VB.NET, supongo, esto ya son teorías, que porque tiene más paralelismos con Java por un lado, por otro es el primero que tiene las nuevas tecnologías (primero sacan las cosas nuevas para C# y ya las van ampliando poco a poco al resto de lenguajes de .NET) y porque sí que es cierto, o era cierto hace 5-6 años, que es más rápido que VB.NET.
#55 Hay implementaciones de Linq hasta en JavaScript. Por supuesto, para Java también.
https://code.google.com/p/jaque/
#55 una aplicación multiplataforma que funcione igual tanto en sistemas UNIX como en sistemas Windows
#55 linq está muy muy bien... hasta cierto punto. Para hacer consultas "chorras", facilitas pues muy bien. el nivel de abtracción es muy alto. Pero cuando tienes de por medio muchas tablas y muchas dependencias en una query, las consulta que genera son realmente muy malas. Es muy típico que pase de usar índices aunque estén creados.
Me he encontrado muchas veces con situaciones de que una query que montamos con linq to sql tardaba más de lo normal, y cuando obtienes la sql que generas te tiras de los pelos.
#c-55" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/55">#55 No es lo que te permita o no, es las vueltas que tienes que dar en VB.NET para hacer lo mismo que puedes hacer con C# también en .NET. Yo no tengo anda contra .NET, es un Framework muy cómodo, pero si me dan a elegir entre VB o C#, me quedo con C# de lejos (el problema es que no me dan a elegir
)
#55 Que sea como "pinta y colorea" no quiere decir que no puedas pintar y colorear un Picasso.
Es ridiculo que hablemos de lo facil o dificil que es programar y algunos os pongais a hablar de lenguajes... el lenguaje no tiene mucho que ver (quitando los extremos como otros paradigmas o lenguajes de muy bajo nivel). Cuando sabes conducir no depende del coche que lleves, al coche te acostumbras y punto, pero si no sabes conducir da igual que coche te pongan.
#55 Java también es como los libros de pinta y colorea. De hecho Eclipse y NetBeans te escriben más de la mitad del código.
Si me hablas de gestionar la memoria en C y optimizar el código, o de usar macros y orden superior en Lisp, o al menos unificación en Prolog, pues vale. Pero habláis de unos lenguajes que sólo se os puede responder: "la ignorancia es atrevida".
#7 Yo con Visual Basic hago interfaces para rastrear ips mindundis
#7
Me imagino que lo dices porque programas en C. Pero eso no es nada, yo programo así:
http://xkcd.com/378/
=P
#1 Que si, que si, Bil Geis...
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/1">#1 No he programado aplicaciones desde hace 10 años, pero entonces teníamos C#, no el puto visual basic.
#11 Hace unos 15 años que se programar en Visual Basic. Así que por tenerlo, también lo teníamos
También se C++ y otros, no me maltratéis por saber VB
#20 Cuando aprendí a programar allá por los 80 BASIC (en mayúsculas) tenía números de línea...
#11 Hace 10 años tenías VB.NET e incluso el VB6 de toda la vida. Microsoft ha llegado a hacer antes de esto un engendro que fue el Visual J. El 90% de lo que usa la gente a nivel de orientación a objetos se puede implantar con casi cualquier lenguaje.
#1 Ups, siento el negativo, te lo compenso por otro lado. Malditos dedos obesos...
#1 Visual Basic es relativamente sencillo de utilizar y sirve para ciertas cosas, pero se puede hacer grandes cosas con él.
Hay una gran cantidad de recursos para hacer desarrollos en VB, C, C++, fortran, pascal, delphi, etc. y millones de ejemplos.
El que no aprende es por falta de dedicación y por aprender me refiero a conocer el lenguaje hasta el punto en que te permita hacer ciertos desarrollos.
#1 Claro, como apenas hay intrusismo laboral en la informática...
Darse de programador por saber VB es como si voy yo a pasar consulta del médico porque se buscar síntomas en google.
#1 trollolololololloloooooooo trolololooooooooooooooo
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/1">#1 Parece que se hable de GWBASIC ... ahora mismo Visual Basic se compila al mismo código intermedio que C# o Ms Java o F# o Ms C++ ... vamos que puedes hacer el código en el lenguaje que quieras y el resultado final ser el mismo a la hora de ejecutarlo en .NET
Ahora si es cierto que Visual Basic puede ser un poco más cómodo para hacer cosas fáciles y un poco más incómodo para las difíciles...
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2348085/order/1">#1 jajajajajja Los programadores programamos herramientas como Visual Baisc para que gente como tu puedan hacer como que programan, no tienes ni puta idea de lo que has dicho ... Visual Basic es una mierda por sus limitaciones y las gran cantidad de bug que tiene (yo no espero menos de microsoft). Iba tan bien que hasta microsoft se ha pasado a una metodología mas de programación como c# o .net mas parecidas a PHP y sin entorno gráficos que no funcionan. por tu comentario se te nota resentido ...
#1 joer, de verdad, deberias replantearte lo tuyo, porque entar a poner una estupidez semejante lo unico que hace es dejarte como un completo gaznápiro.
#1 Hoy en día programar es igual de sencillo que navegar la web, gracias a lenguajes como Visual Basic
Chupado vamos. En Visual Basic tienes que hacer un master para saber que tipos soportan DBNull.Value, que tipos soportan Nothing y que tipos tienen un valor por defecto. Pero no te preocupes que, además, si un tipo no soporta Nothing siempre puedes declararlo como Integer?, Boolean? o Date? (lo de las fechas en Visual Basic da casi tanto asco como Javascript).
Sencillísimo todo. También declarar getters y setters en Visual Basic es muy fácil y muy reducido en código.
Manda cojones tener que leer estas subnormalidades a primera hora de la mañana cuando me esperan 7 horas de picar código en VB.NET.
#1 No tienes ni puta idea, así de claro te lo digo.
#1 Tu eres el que se creyó lo de CSI
:
#1 Oye ni puta idea tienes, que para un tipo con conocimientos técnicos elevados, o un ingeniero con conocimientos tecnicos despues de mucho teimpo documentandose le sea relativamente facil hacer un holamundo, no quiere decir que sea facil. El 90% de la poblacion española no sabe ni buscar en google.
#1 Usar ironías es muy peligroso en un sitio lleno de ineptos.
#1 Hoy en día programar es igual de sencillo que navegar la web