El ingeniero del artículo no termina haciendo "ñapas", sino que deja de sobredimensionar la solución. A medida que un programador va aprendiendo patrones, metodologías, paradigmas... trata de implementarlos en lo que hace, muchas veces sin sentido. Al final se va encontrando el equilibrio y se deja la complejidad para lo que tiene que ser complejo, y la simplicidad para lo que tiene que ser simple. El principio KISS. Te lo dice un programador con 30 años de experiencia.
#17:
#12 Java es de lo poco que ha conseguido poner de acuerdo a Richard Stallman y Linus Torvalds.
#2:
La verdad es que un ingeniero de software, cuanto mas vago, mejor codigo escribe... sin duda.
#14:
#10 Bien dicho. Lo suyo sería referirnos al vigésimo año como anyo[19].
#110:
#99 si comparas dos cosas, deben de ser al menos en un campo comparable. Evidentemente C/C++ se come a Java con patatas cuando hace falta utilizar rutinas de bajo nivel optimizandolas para la cpu/gpu objetivo en tiempo de compilación. Pero te aseguro que en programación más generalista la diferencia es despreciable. Y te lo digo como alguien que hasta hace muy poco tiempo defendía tu postura hasta que me lo demostraron.
#141:
#28 No se que sentido tiene usar C hoy en día. A no ser que estés haciendo software empotrado donde usar C++ no está permitido por temás de seguridad (Software on-board aeroespaciales, por ejemplo), C solo te lastra.
C++11 es una maravilla, el problema es que hay mucha gente que sigue anclada en el "C++ es C con clases", y no.
#121:
#95 Amen. Empiezan hablando como pajilleros. Quienes eligen java no suele buscar eficiencia sino una velocidad de desarrollo aceptable "despreocupandose" de la portabilidad y viceversa.
Esto es como un arquitecto, para elegir materiales de construcción no siempre elegirá el mismo porque piense que sea "mejor", sino porque es el mas adecuado para las condiciones que va a soportar dentro del presupuesto en cada caso.
Ahora en serio, existe una tendencia absurda a hacer código overengineered. Si necesitas medir tu ego, mejor juega a ver quien mea mas lejos, que luego hay gente que tiene que leer tu código...
La de salvajadas que se ven por ahí para hacer cualquier puta irrelevancia donde alguna estrellita del código ha gastado todas las opciones que le ofrecía el lenguaje. Y por supuesto, sin ni un puto test, claro. Las estrellitas del código no escriben tests porque no hacen falta. Ni documentación, que el código "se lee solo" y si no sabes lo que hacen todas esas variables monoletra y sus complicadas operaciones y llamadas a 3 funciones distintas dentro de esa función que se supone que simplemente devuelve un fichero abierto, es porque no eres tan estrellita como ellos.
Nope. Ya quisiera acercarse, por ejemplo, Minecraft a Minetest con el segundo con el mod Carbone petado de módulos.
Que no, que se dejen de magufadas, que en la vida alcazarán a C++. En un i7 con un SSD no lo notas casi, pero un Core Duo maximiza la ventana del MC contra Minetest, anda, o mejor: En un P4. Ni lo intentes.
Todo el que dice que Java con JIT se acerca a C++ que baje de la nube e imagine un Unreal Engine 4 con "eso".
Todo dicho.
#5:
#4 2013 para ser más exactos, pero podía haber sido escrito ayer mismo y te hubiera dado igual. Es tecnología, no actualidad
#95:
#58 Un ingeniero que dice que algo es "mejor" o "peor", no es un gran ingeniero.
Ahora en serio, existe una tendencia absurda a hacer código overengineered. Si necesitas medir tu ego, mejor juega a ver quien mea mas lejos, que luego hay gente que tiene que leer tu código...
#7 Qué optimista. El año veinteavo un ingeniero no será el puto amo sino que estará despedido, porque cobra mucho y la empresa puede poner en su lugar al hijo/yerno del gerente. Total, solo tiene que enviar ese mail que dices al becario.
El ingeniero del artículo no termina haciendo "ñapas", sino que deja de sobredimensionar la solución. A medida que un programador va aprendiendo patrones, metodologías, paradigmas... trata de implementarlos en lo que hace, muchas veces sin sentido. Al final se va encontrando el equilibrio y se deja la complejidad para lo que tiene que ser complejo, y la simplicidad para lo que tiene que ser simple. El principio KISS. Te lo dice un programador con 30 años de experiencia.
La de salvajadas que se ven por ahí para hacer cualquier puta irrelevancia donde alguna estrellita del código ha gastado todas las opciones que le ofrecía el lenguaje. Y por supuesto, sin ni un puto test, claro. Las estrellitas del código no escriben tests porque no hacen falta. Ni documentación, que el código "se lee solo" y si no sabes lo que hacen todas esas variables monoletra y sus complicadas operaciones y llamadas a 3 funciones distintas dentro de esa función que se supone que simplemente devuelve un fichero abierto, es porque no eres tan estrellita como ellos.
#28 El secreto está en el gigantesco ecosistema que se creó en su día, perfectamente documentado y mantenido.
Aunque la mayoría de ese ecosistema sea un mamotreto de proporciones astronómicas y su documentación más infumable que la Biblia en versos arameos, es justamente lo que hace que Java siga siendo ampliamente utilizado hoy en día.
#99 si comparas dos cosas, deben de ser al menos en un campo comparable. Evidentemente C/C++ se come a Java con patatas cuando hace falta utilizar rutinas de bajo nivel optimizandolas para la cpu/gpu objetivo en tiempo de compilación. Pero te aseguro que en programación más generalista la diferencia es despreciable. Y te lo digo como alguien que hasta hace muy poco tiempo defendía tu postura hasta que me lo demostraron.
#58 No, te voy a decir que "mejor" depende del criterio de evaluación. Y la velocidad de ejecución o el consumo de recursos no son los únicos criterios posibles.
Sobre el meneo, real como la vida misma, yo nunca he abandonado la doctrina KISS (https://es.wikipedia.org/wiki/Principio_KISS), y según va pasando el tiempo, creo ha sido la mejor decisión de mi vida.
Nope. Ya quisiera acercarse, por ejemplo, Minecraft a Minetest con el segundo con el mod Carbone petado de módulos.
Que no, que se dejen de magufadas, que en la vida alcazarán a C++. En un i7 con un SSD no lo notas casi, pero un Core Duo maximiza la ventana del MC contra Minetest, anda, o mejor: En un P4. Ni lo intentes.
Todo el que dice que Java con JIT se acerca a C++ que baje de la nube e imagine un Unreal Engine 4 con "eso".
#95 Amen. Empiezan hablando como pajilleros. Quienes eligen java no suele buscar eficiencia sino una velocidad de desarrollo aceptable "despreocupandose" de la portabilidad y viceversa.
Esto es como un arquitecto, para elegir materiales de construcción no siempre elegirá el mismo porque piense que sea "mejor", sino porque es el mas adecuado para las condiciones que va a soportar dentro del presupuesto en cada caso.
#28 No se que sentido tiene usar C hoy en día. A no ser que estés haciendo software empotrado donde usar C++ no está permitido por temás de seguridad (Software on-board aeroespaciales, por ejemplo), C solo te lastra.
C++11 es una maravilla, el problema es que hay mucha gente que sigue anclada en el "C++ es C con clases", y no.
Lo he tenido que rehacer solo por no ponerme a hacer modificaciones.
Es que es lo que se debe hacer con la basura. Mi procedimiento habitual para tratar con ella es ese. No será la primera vez ni la última que heredo código y, tras echar un vistazo y ver que es una puta mierda, hago unos cuantos tests (que el menda de antes no ha hecho) para comprobar que cumple lo que promete y acto seguido todo fuera y a hacerlo como toca.
#14#15#35 Pues yo escribo year[19] ... Por aquello de darle un toque más internacional...
(Delirios de grandeza de pensar que tu código lo va a ver alguien más que tú mismo y puede que algún colega o jefe... si tal)
#61 En el proyecto en el que estoy trabajando ahora he visto una de las mayors aberraciones de mi vida. Un broker (cojo mensaje, distribuyo a otros brokers y si la subscripción casa, se lo mando al subscriptor) implementado con maquinas de estado, runnables por todas partes, factorias y polladas varias. Es como coger el libro de gang of four y implementar X patrones entren o no. Terrible. Lo he tenido que rehacer solo por no ponerme a hacer modificaciones.
#59 C++ sí que devuelve por defecto "return 0;" si el código no especifica un "return" en la función "main".
The body of the main function does not need to contain the return statement: if control reaches the end of main without encountering a return statement, the effect is that of executing return 0;.
#61 Bueno. Si no entiendes un código es porque es una mierda, no porque no haya suficientes comentarios.
Por cierto, en general, un programador que escribe un código que sólo entienden programadores senior es un mal programador y le está haciendo una putada a su empresa.
#90 Java como tal lo soporta perfectamente. El problema está en que tu código siguen siendo ficheros de texto que, si abre alguien con un locale/codificación regionla distinto al de tu máquina, puede decodificarse de otra forma. Vamos, que si el código no sale de tu máquina puedes nombrar las variables en cirílico si quieres, pero si vas a compartir el código no es buena idea.
#28 Ventajas de Java respecto a C hay unas cuantas: tienes orientación a objetos, contenedores genéricos, te despreocupas de punteros, hay una cantidad ingente de librerías modernas... no sé, en general es bastante más fácil de usar.
Respecto a C++ ya creo que sólo tiene que es algo más fácil de usar, pero más que nada porque tienes muchísimas menos opciones.
#5 Exacto, solo que en lugar de utilizar Java se utilizará otra lenguaje pero es lo mismico.
Lo bonito de la programación es su facilidad para hacer que te desconectes del mundo y solo pienses en como puñetas escribir el código para que el programa haga lo que tú quieres que haga.
#93 El test es un codigo extremadamente sencillo que simplemente llama al código a testear pasándole unos parámetros fijos y comprueba que se devuelven los valores esperados.
Claro que los tests podrían estar mal hechos, pero entonces te darías cuenta enseguida de que no estás testeando bien lo que quieres comprobar, porque entonces tendrías errores en vez de fallos. Los tests bien escritos tienen o éxitos o fallos, nunca errores. Por eso no es necesario hacer tests de tests, porque al ejecutarse "se testean solos": si dan error, están mal hechos.
#136Una de las cosas que más me encuentro es que todo el mundo es "muy listo" y siempre recibe código de idiotas
Yo intento no pensarlo, por que la mayor parte de las ñapas, códigos ofuscados, con baja performance, etc, no suelen ser culpa del programador. Pienso que al pobre tipo quizá le asignarón un proyecto donde desconocia la técnologia, con arquitectura inexistente, los requisites cambiando como quien cambia de bragas, estaba al 30% en otro proyecto y mientras solucionaba bugs de deliveries anteriores. Así es imposible programar bien. Es lo que me pasa a mi a veces y es lógico que les pase a los demás.
Por otro lado, mi queja en #69 va por otro lado. Conozco perfectamente cual era la situación del tipo que lo desarrollo. Era una software con unos requisitos sencillisimos pero el colega acababa de salir de la Universidad y tenia que sacarse la polla con un código ininteligible, matando moscas a cañonazos. No hablo de alguien que usa metaprogramación de una forma lógica o alguien que usa un framework que se ajusta al proyecto ante el estupor de sus compañeros.
#149Intenté tocar el código del Cataclysm DDA pero el lenguaje provee tantos conceptos de programación a la vez y tantas formas de hacer una misma cosa creando redundancia que ya casi no sabes como va a resultar una acción.
A ver si me entero.Estás juzgando la idoenidad de un lenguaje de programación para iniciar proyectos por el hecho de que no seas capaz de entender un software programado con el? Desconozco como está diseñado ese software pero quizá tambien sea por que no tengas los conocimientos necesarios para entenderlo.
En C no me pasó , de hecho adapté algunos jueguillos para el afamado blog (en el mundo linuxero) de K.Mandla al ver que unos juegos de terminal no cabían bajo 80x24 o la jugabilidad estaba mal implemetada.
Y resulta que C es major por que pudiste editar unos de terminal? Por favor...
Que me importa a mi que puedas hacer implementar soporte WebGL en un navegador X? O el codigo de Taipan? Es que me da lo mismo. Yo lo que quiero es potencia (a nivel de desarrollo) que me permita desarrollar mi proyecto de forma rápida, sostenible, escalable y con una razonble performance. C++ tiene POO, la STL con todo lo que ello implica, Boost si es que despues de C++11 lo necesitas y metaprogramación además de mantener un rendimiento similar a C.
Sinceramente, creo que no estás en tu terreno y estás diciendo sinsentidos.
#109, yo defiendo el testing desde el punto de vista que te ayuda, al pensar en el test, a afinar realmente lo que tiene que hacer un apartado, y a revisar posibles estados que no habías tenido en cuenta antes, pero discrepo del resto que comentas:
a) "es un codigo extremadamente sencillo"
Corto no es equivalente de sencillo, y según lo que testes, aumenta la complejidad a veces por encima de la complejidad del código que estás testando, añadir mocks, diseñar teniendo en cuenta la posible inyección de dependencias ( a veces esto es mejor, a veces no ). Aparte, al mockear partes de la aplicación, estás dejando fuera del test muchas de las posibilidades de error de esa parte del código ( ya sé que esto es más funcional que unitario, pero ahí está la realidad ).
b) "Claro que los tests podrían estar mal hechos, pero entonces te darías cuenta enseguida (...)"
Ahí discrepo, y mucho. Un test puede no dar error, ni fallo, y ser incorrecto desde tantos ángulos como el propio código que testa. No sería la primera ni la vigésimo-cuarta vez que veo pasar los tests a código que después ni siquiera funciona.
c) "Los tests bien escritos tienen o éxitos o fallos, nunca errores. Por eso no es necesario hacer tests de tests, porque al ejecutarse "se testean solos"
Según la misma lógica, el código bien escrito no necesita tests. Si funciona es que está correcto. Y esto sabemos que no es así. Tests sin errores pueden dejar escapar muchas posibilidades. De hecho, la mayoría de los tests que suelo ver pecan de no probar infinidad de posibilidades, de tipado, de término vacío, de valores fuera de rango, etc. Se testa un pequeño espacio de la posibilidad de error, y cuanto más pequeño sea ese espacio, más fácil es cumplir el objetivo del test, pero a la vez menos completo será el mismo.
En definitiva, salvo para apartados con mucha complejidad ciclomática, sigo pensando que es un esfuerzo bastante estéril, salvo por lo comentado al principio.
Pero es sólo mi opinión, y no es ni de lejos la más formada al respecto.
#107 Excepto los putos yankees que aseguran que con ISO 8859 se ahorra memoria. ( ¿O era inglés el puto memo que me lo dijo? No se...)
Lo que estoy seguro es que me jodio una base datos entera. Y también es seguro que el paso 3 días buscando y reemplazando marcianitos mientras yo ya había tirado de backup.
#110 Muy de acuerdo, es como comparar una navaja suiza con cada una de las herramientas que lleva, si necesitas algo a nivel "profesional" no te va a valer, para la mayoría de los casos es más que suficiente.
Aquí digo profesional, para referirme a cuando necesitas herramientas muy específicas o en este caso, acceso al hardware, especificaciones a bajo nivel, etc.
Comentarios
#8 El problema es que haya ingenieros diciendo veinteavo en vez de vigésimo. Ese es el problema.
#2 La eficiencia no es más que una forma avanzada de vagancia.
La verdad es que un ingeniero de software, cuanto mas vago, mejor codigo escribe... sin duda.
#12 Java es de lo poco que ha conseguido poner de acuerdo a Richard Stallman y Linus Torvalds.
#10 Bien dicho. Lo suyo sería referirnos al vigésimo año como anyo[19].
Puto Java...
#42 ORGIA DE NOTARIOS!!!
#4 2013 para ser más exactos, pero podía haber sido escrito ayer mismo y te hubiera dado igual. Es tecnología, no actualidad
Para lo que me pagan...
Ahora en serio, existe una tendencia absurda a hacer código overengineered. Si necesitas medir tu ego, mejor juega a ver quien mea mas lejos, que luego hay gente que tiene que leer tu código...
el año veinteavo, escribiría:
from:puto amo
mailto: becario
Pringao, hazme un programa que ponga hello world en la pantalla.Lo quiero en 10 minutos o te vas fuera.
saludos cordiales,
puto amo
#7 Qué optimista. El año veinteavo un ingeniero no será el puto amo sino que estará despedido, porque cobra mucho y la empresa puede poner en su lugar al hijo/yerno del gerente. Total, solo tiene que enviar ese mail que dices al becario.
#6 creo que no has pillado el concepto.
El ingeniero del artículo no termina haciendo "ñapas", sino que deja de sobredimensionar la solución. A medida que un programador va aprendiendo patrones, metodologías, paradigmas... trata de implementarlos en lo que hace, muchas veces sin sentido. Al final se va encontrando el equilibrio y se deja la complejidad para lo que tiene que ser complejo, y la simplicidad para lo que tiene que ser simple. El principio KISS. Te lo dice un programador con 30 años de experiencia.
https://es.wikipedia.org/wiki/Principio_KISS
#1 Doy fe de que es cierto
10 CLS
20 PRINT "¡Hola Mundo!"
30 GOTO 20
Real como la vida misma. Yo cada vez hago más ñapas directamente en código por pura desidia.
++++++++++[>+++++++>++++++++++>+++>+.
#58 Un ingeniero que dice que algo es "mejor" o "peor", no es un gran ingeniero.
criaturicas...
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Hello world!" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
#15 El código escrito en cualquier idioma que no sea el Inglés hace llorar al Niño Jesús.
#14 Yo escribo ano[19] y a tomar por culo... nunca mejor dicho
Los que no son ingenieros.
void main()
">
¿Para qué necesitas una clase para imprimir "hola mundo"?
#24 Amén.
La de salvajadas que se ven por ahí para hacer cualquier puta irrelevancia donde alguna estrellita del código ha gastado todas las opciones que le ofrecía el lenguaje. Y por supuesto, sin ni un puto test, claro. Las estrellitas del código no escriben tests porque no hacen falta. Ni documentación, que el código "se lee solo" y si no sabes lo que hacen todas esas variables monoletra y sus complicadas operaciones y llamadas a 3 funciones distintas dentro de esa función que se supone que simplemente devuelve un fichero abierto, es porque no eres tan estrellita como ellos.
#28 El secreto está en el gigantesco ecosistema que se creó en su día, perfectamente documentado y mantenido.
Aunque la mayoría de ese ecosistema sea un mamotreto de proporciones astronómicas y su documentación más infumable que la Biblia en versos arameos, es justamente lo que hace que Java siga siendo ampliamente utilizado hoy en día.
#16 Porque en Java no hay otra forma de hacerlo.
#99 si comparas dos cosas, deben de ser al menos en un campo comparable. Evidentemente C/C++ se come a Java con patatas cuando hace falta utilizar rutinas de bajo nivel optimizandolas para la cpu/gpu objetivo en tiempo de compilación. Pero te aseguro que en programación más generalista la diferencia es despreciable. Y te lo digo como alguien que hasta hace muy poco tiempo defendía tu postura hasta que me lo demostraron.
#9 #11 Tiene sus cosas buenas...
#9 ...y al séptimo día creó groovy:
println "Hello World"
y los diveros son
PROGRAM Hola Mundo;
PRIVATE fuente1;
BEGIN
fuente1 = load_fnt("help/help.fnt");
write(fuente1, 160, 100, 4, "Hola Mundo");
LOOP
FRAME;
END
END
wass... que no se quede DIV atras
#17 http://40.media.tumblr.com/7dda187737d00fc3f3221fb46272246e/tumblr_ng3o5m4gIR1s9y3qio1_1280.jpg
#16 Y el #include ?
Sin int ni return para el SO ?!?
Suspenso !! Con un 4,99
#! /bin/bash
echo "hello world"
#58 No, te voy a decir que "mejor" depende del criterio de evaluación. Y la velocidad de ejecución o el consumo de recursos no son los únicos criterios posibles.
Esto es un alegato contra la POO?
La evolución de un ingeniero de software.
Año 11: pierde el tiempo en Meneame en horario de oficina, donde se queja de que en Españistán sigue cobrando 1200€/mes.
El mejor es el LOLCODE:
HAI 1.2
CAN HAS STDIO?
VISIBLE "HAI WORLD!!!1!"
KTHXBYE
Esto es más viejo que el cagar.
#72 Pues no lo sabia . Bueeeno, tu ganas, lo subo a 4,998 .
Ésto es como muy 2014...
#50 otro que no ha salido de la universidad
#9 Amen, hermano.
Sobre el meneo, real como la vida misma, yo nunca he abandonado la doctrina KISS (https://es.wikipedia.org/wiki/Principio_KISS), y según va pasando el tiempo, creo ha sido la mejor decisión de mi vida.
Edito, en inglés viene mucho más completo: https://en.wikipedia.org/wiki/KISS_principle
#76 ", no pero casi."
Nope. Ya quisiera acercarse, por ejemplo, Minecraft a Minetest con el segundo con el mod Carbone petado de módulos.
Que no, que se dejen de magufadas, que en la vida alcazarán a C++. En un i7 con un SSD no lo notas casi, pero un Core Duo maximiza la ventana del MC contra Minetest, anda, o mejor: En un P4. Ni lo intentes.
Todo el que dice que Java con JIT se acerca a C++ que baje de la nube e imagine un Unreal Engine 4 con "eso".
Todo dicho.
#95 Amén. Nada es "mejor" ni "peor" sino que algo puede ser "más adecuado" según el caso.
#95 Amen. Empiezan hablando como pajilleros. Quienes eligen java no suele buscar eficiencia sino una velocidad de desarrollo aceptable "despreocupandose" de la portabilidad y viceversa.
Esto es como un arquitecto, para elegir materiales de construcción no siempre elegirá el mismo porque piense que sea "mejor", sino porque es el mas adecuado para las condiciones que va a soportar dentro del presupuesto en cada caso.
#7 y #8: se dice vigésimo.
#14 O agno.
#28 No se que sentido tiene usar C hoy en día. A no ser que estés haciendo software empotrado donde usar C++ no está permitido por temás de seguridad (Software on-board aeroespaciales, por ejemplo), C solo te lastra.
C++11 es una maravilla, el problema es que hay mucha gente que sigue anclada en el "C++ es C con clases", y no.
#34 ¿C no devuelve "return 0;" por defecto, en caso de omitirlo en la función "main"?
Pregunto, porque C++ sí que sé que lo hace...
#69 😭 🔫
Lo he tenido que rehacer solo por no ponerme a hacer modificaciones.
Es que es lo que se debe hacer con la basura. Mi procedimiento habitual para tratar con ella es ese. No será la primera vez ni la última que heredo código y, tras echar un vistazo y ver que es una puta mierda, hago unos cuantos tests (que el menda de antes no ha hecho) para comprobar que cumple lo que promete y acto seguido todo fuera y a hacerlo como toca.
#82 Es COBOL, y sigue siendo uno de los lenguajes más utilizados por la banca.
#90 No lo hagas. Simplemente no lo hagas.
#23 Doy fe de que has dado fe de ello.
#14 #15 #35 Pues yo escribo year[19] ... Por aquello de darle un toque más internacional...
(Delirios de grandeza de pensar que tu código lo va a ver alguien más que tú mismo y puede que algún colega o jefe... si tal)
#61 En el proyecto en el que estoy trabajando ahora he visto una de las mayors aberraciones de mi vida. Un broker (cojo mensaje, distribuyo a otros brokers y si la subscripción casa, se lo mando al subscriptor) implementado con maquinas de estado, runnables por todas partes, factorias y polladas varias. Es como coger el libro de gang of four y implementar X patrones entren o no. Terrible. Lo he tenido que rehacer solo por no ponerme a hacer modificaciones.
#58 en terminos de portabilidad, sin duda. En términos de eficiencia, no pero casi. Hace tiempo que java utiliza compilación just-in-time.
#21: ¿Y para qué necesitas Java?
#59 C++ sí que devuelve por defecto "return 0;" si el código no especifica un "return" en la función "main".
The body of the main function does not need to contain the return statement: if control reaches the end of main without encountering a return statement, the effect is that of executing return 0;.
http://en.cppreference.com/w/cpp/language/main_function
#41echo Hello world
Me encanta la simplicidad del scripting de cmd para según qué cosas :-P
#61 Bueno. Si no entiendes un código es porque es una mierda, no porque no haya suficientes comentarios.
Por cierto, en general, un programador que escribe un código que sólo entienden programadores senior es un mal programador y le está haciendo una putada a su empresa.
Ésto era simpleza:
10 PRINT "Hello World!"
END
#90 Java como tal lo soporta perfectamente. El problema está en que tu código siguen siendo ficheros de texto que, si abre alguien con un locale/codificación regionla distinto al de tu máquina, puede decodificarse de otra forma. Vamos, que si el código no sale de tu máquina puedes nombrar las variables en cirílico si quieres, pero si vas a compartir el código no es buena idea.
Si te interesa el tema -> http://stackoverflow.com/questions/2178348/should-source-code-be-saved-in-utf-8-format
#70 cat
Hello world
#16 Para qué necesitas una función?
#28 Ventajas de Java respecto a C hay unas cuantas: tienes orientación a objetos, contenedores genéricos, te despreocupas de punteros, hay una cantidad ingente de librerías modernas... no sé, en general es bastante más fácil de usar.
Respecto a C++ ya creo que sólo tiene que es algo más fácil de usar, pero más que nada porque tienes muchísimas menos opciones.
#5 Exacto, solo que en lugar de utilizar Java se utilizará otra lenguaje pero es lo mismico.
Lo bonito de la programación es su facilidad para hacer que te desconectes del mundo y solo pienses en como puñetas escribir el código para que el programa haga lo que tú quieres que haga.
#97 Tiene que ser "apasionante" programar con eso...
#21 GOTO #9
#7 > el año veinteavo
Cc #10
#56 Ahora me vas a decir que un programa en VM es mejor que compilado??
#93 El test es un codigo extremadamente sencillo que simplemente llama al código a testear pasándole unos parámetros fijos y comprueba que se devuelven los valores esperados.
Claro que los tests podrían estar mal hechos, pero entonces te darías cuenta enseguida de que no estás testeando bien lo que quieres comprobar, porque entonces tendrías errores en vez de fallos. Los tests bien escritos tienen o éxitos o fallos, nunca errores. Por eso no es necesario hacer tests de tests, porque al ejecutarse "se testean solos": si dan error, están mal hechos.
Ingenebrio.
Print 'hello world'. Python rules
#136 Una de las cosas que más me encuentro es que todo el mundo es "muy listo" y siempre recibe código de idiotas
Yo intento no pensarlo, por que la mayor parte de las ñapas, códigos ofuscados, con baja performance, etc, no suelen ser culpa del programador. Pienso que al pobre tipo quizá le asignarón un proyecto donde desconocia la técnologia, con arquitectura inexistente, los requisites cambiando como quien cambia de bragas, estaba al 30% en otro proyecto y mientras solucionaba bugs de deliveries anteriores. Así es imposible programar bien. Es lo que me pasa a mi a veces y es lógico que les pase a los demás.
Por otro lado, mi queja en #69 va por otro lado. Conozco perfectamente cual era la situación del tipo que lo desarrollo. Era una software con unos requisitos sencillisimos pero el colega acababa de salir de la Universidad y tenia que sacarse la polla con un código ininteligible, matando moscas a cañonazos. No hablo de alguien que usa metaprogramación de una forma lógica o alguien que usa un framework que se ajusta al proyecto ante el estupor de sus compañeros.
#51 que yo sepa no ... y creo que C++ tampoco ... a no ser que lo haga auto el compilador.
Aún así , excusas no me vale
#149 Intenté tocar el código del Cataclysm DDA pero el lenguaje provee tantos conceptos de programación a la vez y tantas formas de hacer una misma cosa creando redundancia que ya casi no sabes como va a resultar una acción.
A ver si me entero.Estás juzgando la idoenidad de un lenguaje de programación para iniciar proyectos por el hecho de que no seas capaz de entender un software programado con el? Desconozco como está diseñado ese software pero quizá tambien sea por que no tengas los conocimientos necesarios para entenderlo.
En C no me pasó , de hecho adapté algunos jueguillos para el afamado blog (en el mundo linuxero) de K.Mandla al ver que unos juegos de terminal no cabían bajo 80x24 o la jugabilidad estaba mal implemetada.
Y resulta que C es major por que pudiste editar unos de terminal? Por favor...
Que me importa a mi que puedas hacer implementar soporte WebGL en un navegador X? O el codigo de Taipan? Es que me da lo mismo. Yo lo que quiero es potencia (a nivel de desarrollo) que me permita desarrollar mi proyecto de forma rápida, sostenible, escalable y con una razonble performance. C++ tiene POO, la STL con todo lo que ello implica, Boost si es que despues de C++11 lo necesitas y metaprogramación además de mantener un rendimiento similar a C.
Sinceramente, creo que no estás en tu terreno y estás diciendo sinsentidos.
#63 Qué tiempos... en el fondo al menos las instrucciones en COBOL son legibles.
Aficionados, todo el mundo sabe que el mejor código está basado en patrones
https://taskinoor.wordpress.com/2011/09/21/the-abuse-of-design-patterns-in-writing-a-hello-world-program/
Justamente ayer cree un hello world son diferentes archivos todo en uno.
http://pastebin.com/TA8D1CV4
#31 te falta un:
15 LOCATE X, Y
para ya terminar de trollear a todos estos. Eso o un ";" al final del PRINT para llenar la pantalla.
Eso eran lenguajes de programación y no lo de ahora
#74 Apruebe a mi colega, que el chaval lleva todo el curso estudiando
#109, yo defiendo el testing desde el punto de vista que te ayuda, al pensar en el test, a afinar realmente lo que tiene que hacer un apartado, y a revisar posibles estados que no habías tenido en cuenta antes, pero discrepo del resto que comentas:
a) "es un codigo extremadamente sencillo"
Corto no es equivalente de sencillo, y según lo que testes, aumenta la complejidad a veces por encima de la complejidad del código que estás testando, añadir mocks, diseñar teniendo en cuenta la posible inyección de dependencias ( a veces esto es mejor, a veces no ). Aparte, al mockear partes de la aplicación, estás dejando fuera del test muchas de las posibilidades de error de esa parte del código ( ya sé que esto es más funcional que unitario, pero ahí está la realidad ).
b) "Claro que los tests podrían estar mal hechos, pero entonces te darías cuenta enseguida (...)"
Ahí discrepo, y mucho. Un test puede no dar error, ni fallo, y ser incorrecto desde tantos ángulos como el propio código que testa. No sería la primera ni la vigésimo-cuarta vez que veo pasar los tests a código que después ni siquiera funciona.
c) "Los tests bien escritos tienen o éxitos o fallos, nunca errores. Por eso no es necesario hacer tests de tests, porque al ejecutarse "se testean solos"
Según la misma lógica, el código bien escrito no necesita tests. Si funciona es que está correcto. Y esto sabemos que no es así. Tests sin errores pueden dejar escapar muchas posibilidades. De hecho, la mayoría de los tests que suelo ver pecan de no probar infinidad de posibilidades, de tipado, de término vacío, de valores fuera de rango, etc. Se testa un pequeño espacio de la posibilidad de error, y cuanto más pequeño sea ese espacio, más fácil es cumplir el objetivo del test, pero a la vez menos completo será el mismo.
En definitiva, salvo para apartados con mucha complejidad ciclomática, sigo pensando que es un esfuerzo bastante estéril, salvo por lo comentado al principio.
Pero es sólo mi opinión, y no es ni de lejos la más formada al respecto.
#1 ¿Mismo nick que Forocoches y Erepublik?
#54 A mi jefe le dio una temporada por FuelPHP. Ya no es mi jefe y yo ya no programo en PHP.
Cc. #38
Saes
True Story
#48 ¿#pragma once?
Eso no es standard!
#107 Excepto los putos yankees que aseguran que con ISO 8859 se ahorra memoria. ( ¿O era inglés el puto memo que me lo dijo? No se...)
Lo que estoy seguro es que me jodio una base datos entera. Y también es seguro que el paso 3 días buscando y reemplazando marcianitos mientras yo ya había tirado de backup.
Es exáctamente asi. Miro mis programas de c++ y me identifico totalmente. Hoy para escribir 'class' tengo que tener una buena lista de motivos
#63 Madredelamorhermoso. Pobrecitos los que tenían que programar con esto. Que es, por cierto?
#10 un ingeniero jamas se equivoca... Se referia al día 18 y pico
#110 Muy de acuerdo, es como comparar una navaja suiza con cada una de las herramientas que lleva, si necesitas algo a nivel "profesional" no te va a valer, para la mayoría de los casos es más que suficiente.
Aquí digo profesional, para referirme a cuando necesitas herramientas muy específicas o en este caso, acceso al hardware, especificaciones a bajo nivel, etc.
#6 Yo también. Ley del mínimo esfuerzo.
#12 Aparte de que es posible que te funcione en sistemas distintos... no le veo ninguna ventaja, ni a la programación ni al producto final.
C
The fifth yeaar, es puro toc.
#31 aggghhh mis ojos !!! BASIC . Nooo por favor.
Yo prefiero algo asi como:
------ HelloWorldTest.java
import org.junit.Test;
import org.mockito.Mockito;
import java.io.PrintStream;
public class HelloWorldTest Test
public void test_hello_world_is_printed() {
PrintStream output = Mockito.mock(PrintStream.class);
HelloWorld hw = new HelloWorld(output);
hw.sayPhrase();
Mockito.verify(output).println("Hello world!");
">
}
------- HelloWorld.java
import java.io.PrintStream;
private class HelloWorld
public void sayPhrase() ">
public static void main(String[] args)
}
¿Y los tests? Esperaba que el último caso fuese algo como: HelloWorldTest + HelloWorld.
HOLA MUNDO
#18 Qué recuerdos.
#79 los lenguajes son herramientas... Para algunas cosas es mejor java, para otras C++ y para otras qbasic.