15.000 desarrolladores responden en Twitter cuál es su lenguaje de programación favorito, cuál odian y cuál recomiendan

192 meneos

10217 clics

15.000 desarrolladores responden en Twitter cuál es su lenguaje de programación favorito, cuál odian y cuál recomiendan

Quizás te encontraste con alguno de estos tuits o quizás no, pero miles de desarrolladores se unieron a una tendencia en Twitter en la que listaban lenguajes de programación según seis parámetros distintos bastante simples e interesantes:

91 101 2 K 401 tecnología

218 comentarios

91 101 2 K 401 tecnología

«123 »

#101 llorencs

#83 A mi me pones el código sin sangrías y me vuelves loco. Me cuesta un huevo leerlo. El código para mi necesita tener sangrías para poder claramente a que corresponde cada bloque.

0 11
#102 RubiaDereBote

#99 ActionScript se usa hoy en día

0 11
#103 mirav

#101 si si, la indentacion tiene que ser perfecta, completamente de acuerdo. Personalmente soy muy tiquismiquis con el formateo.
Pero que un nivel de indentado mas o menos rompa el codigo es lamentable.

1 14
#104 woopi *

#101 Bueno, pero es que java también usas sangrías además de las llaves. La ventaja es que si cambias de lugar parte del código, por ejemplo de una función o un método dentro de un bloque a una zona distinta del código, dentro de unos if o repeticiones o una clase, todo encaja sin problemas (por las llaves). En el peor de los casos usas un editor que le de formato a la sangría automáticamente y queda todo ordenado (que no hace falta, se puede hacer fácil "a mano")... Pero en python siempre se me complican ese tipo de operaciones

0 10
#105 juande

#79 En mi humilde opinión, aconsejaría un lenguage fácil, si puede que sea orientado a objetos y que el que no te den ganas de quitarte la vida,

Smalltalk...

1 16
#106 --540651--

#14 así quede yo inútil...
Pero a modo de curiosidad, hay intérprete de basic de los 80 para Linux, bwbasic se llama

0 6
#107 crafton

#78 Vaya frase de abuelete.

2 19
#108 --540651--

#58 el basic de microcomputadora tenía acceso directo a las características ofrecidas por el hardware.

Por algún motivo, todos los estudiados dicen que no vale para nada.

2 29
#109 --540651--

#72 como dije en un comentario anterior, hay intérprete de basic de los 80 para Linux.
Como desconoces cuántos programas en basic generan html5 a dia de hoy, igual tú afirmación es un poco exagerada

0 6
#110 --569461--

#107 La verdad.

0 8
#111 FooDev

#68 Yo diría que se parece mucho más a PHP.

0 6
#112 frankiegth *

#108. Es los PCs el tema trata de mantener la compatibilidad entre un amplio abanico de hardware realmente incompatible entre sí. Pero mira la reciente evolución del estandar 'OpenGL' hacia 'Vulkan' que como principal 'novedad' ofrece un acceso más directo al hardware de las tarjeta gráficas.
_{(CC #58)}

0 11
#113 --540651--

#112 de aquella había lo que hoy será gl_arb_draw y poco más
Pero... Aquellos microcomputadores tenían acceso directo al hw, te digan lo que te digan

1 17
#114 mcfgdbbn3 *

#68: Por eso no me gusta Python, porque programar con indentados me parece una chapucísima.

Estoy de acuerdo en que JS podría ser mejor, pero Python con su indentación como método para estructurar el código (y no para mejorar la legibilidad) nunca me gustará.

1 19
#115 tranki

#6 Totalmente de acuerdo.
La estructura de C ha sido copiada por un montón de lenguajes.
Además con C puedes programar desde un pequeño uP hasta donde llegue la imaginación.
Está el tema de los punteros que cuesta un poco de pillar, pero ayuda muchísimo a entender como se gestiona la memória y como se almacenan las variables.

Y sobre todo, no es un lenguaje interpretado.

1 15
#116 PacoJones

#109 ¿Cuántos ofertas de trabajo piden hoy BASIC como requisito? Quitando el legacy code ¿Quién trabaja hoy en BASIC?
Como anécdota y si te gusta trastear, muy bien, para uso actual, muy poco.

0 10
#117 --540651--

#116 aquí nadie habló de trabajar de informático

0 6
#118 numero

#48 Me he logueado solo para votarte negativo

1 25
#119 JohnSmith_

#1 Cualquiera de .NET (el Visual Basic es mas "sencillito", aunque yo te recomendaria C#). Te puedes descargar el Visual Studio en su version Express que es gratis y asi podrias desarrollar cosas para web, para escritorio y, si me apuras, hasta apps para movil desde un entorno unificado.

Para empezar de cero creo que no encontraras nada mejor, eso si, si empiezas de cero coma cero ... te recomiendo que leas algun libro antes de pretender escribir codigo por simple que sea.

1 17
#120 PacoJones

#117 En eso tienes razón , era por recomendarle algo que se utilice más a menudo en la actualidad y no lo vea como una antigualla.

0 10
#121 JohnSmith_

#43 Seguimos el mismo camino. Aunque yo no prevengo a la gente sobre los punteros en C. Y es que casi toda la gente que conozco, mas tarde o mas temprano, ha tenido un "momento de iluminacion" con los punteros en el que ha dicho: "Coño!!, ya lo entiendo!!, esto es asi y asi!!" ... y a partir de ahi ya no hay mas problema nunca mas. Es cuestion de esperar ese momento en que el cerebro hace "click!"

2 31
#122 JohnSmith_

#1 Ah!!. Y si lo que quieres es un pasatiempo y no algo que te pueda ser util algun dia (temas laborales por ejemplo), pues te recomiendo la plataforma Arduino ... programacion de microcontroladores para hacerte tus cacharritos electronicos y tal. Si te gustan esos temas es extremadamente divertido

1 16
#123 --540651--

#120 ahora el consejo en serio, si vas a aprender BASIC en 2019 mejor aprende BASH
Sirve como lenguaje de programación para cosas caseras y luego sirve para muchas más cosas y se utiliza y se seguirá haciendo mucho tiempo

0 6
#124 tremolantepenacho

#121 Sí, el click es importante, sin duda. Pero hasta que llegua lo pasas mal

0 10
#125 elgranmago

Es interesante ver cómo nadie nombra SQL, no es un lenguaje de programación per se, pero es el que antes o después usas para acceder a las bases de datos relacionales y éstas van a seguir existiendo unos cuantos años más.

0 7
#126 --560335--

C#. Es un orgasmo trabajar en ese lenguaje.

0 6
#127 --560335--

#119 Ya no existen las versiones Xpress, desde hace por lo menos 7 años. Ahora existe la version "Community" que tiene toda la funcionalidad de la versión completa (Ultimate), con la limitación de solo poder utilizarse para producción en entornos de, como máximo, 5 personas dedicadas al proyecto. A la hora de instalar puede seleccionar los lenguajes y plataformas con las que quiere trabajar.

1 15
#128 squanchy

#9 Funciones lambda. Tampoco, gracias.

0 10
#129 vickop *

#128 Mi queja del tipado dinámico no es una cuestión de gustos. No chequear los tipos supone trasladar problemas que resolverían en tiempo de compilación a tiempo de ejecución. O sea, vas a tener mayor cantidad de errores en tu programa.

Ahora, ¿cuál es tu queja con las funciones lambda?

0 9
#130 maloconocido *

#55 en back puedes usar cualquier lenguaje que quieras, incluso varios a la vez, en front estás más limitado en principio, porque hay que adaptarse a lo que soporta el navegador, aunque raro es el desarrollo web de hoy en día que transpila, y puedes hacer front en js, Dart, typescript,... incluso go!

0 7
#131 maloconocido

#24 agree 100% basic es de juguete.

0 7
#132 maloconocido

#28 totalmente, llevo 6 años haciendo servicios web en go y es una gozada, consumo de recursos mínimo, rinde bastante bien (en el orden de c y java sin frameworks) y es muy fácil manejar concurrencia. Y buena experiencia también con alguna web tipo SPA con ciertas páginas renderizados en back —por tema de seo– con el paquete de templates (muy bien pensado, por cierto)

0 7
#133 maloconocido

#52 transpila

1 14
#134 maloconocido

#53 el navegador puede ejecutar lo que sea, los errores no dependen de eso.

0 7
#135 Fran.DLG *

Era prececible. Javascript, amorodio.

0 8
#136 maloconocido

#121 a partir de ese momento la gente te ve diferente, te empiezan a meter en un saco con diferentes denominaciones

0 7
#137 maloconocido

#105 orientado a objetos para empezar... No se me ocurre nada más antinatural ahora mismo

0 7
#138 maloconocido

#115 con asm también puedes programar hasta donde llegue la imaginación

0 7
#139 maloconocido

#69 por favor, intenta no pensar en una persona de 50 años como un ente sin cerebro.

#62 para la gran mayoría de situaciones será una mierda, pero hay un nicho potente ahí para hacer pequeñas soluciones para pymes basadas en aplicaciones de MS que ya tienen millones de usuarios por todo el mundo.

2 30
#140 maloconocido

#65 la curva de aprendizaje de angular es una pared básicamente, por no hablar de que montar un sistema de build ya es un proyecto en sí mismo, todo ello para acabar con un código que en un par de años estará depreciado.

0 7
#141 maloconocido

#100 lo más preocupante no me parece la declaración de variables en sí misma, sino la memoria dinámica, no se sabe si se está usando memoria del stack o del heap para las variables, ni se ve por ningún sitio el recolector de basura. Por no hablar de que justamente la implementación de Python no soporta paralelismo (aunque sí concurrencia)

0 7
#142 maloconocido

#40 un pequeño apunte, que se ejecuten sobre la JVM no significa que el lenguaje se base en Java. Podrías tener un compilador de c a bytecode JVM y C no está basado en Java

0 7
#143 maloconocido

#70 recuerdo volver a C++ para hacer cosas de opengl después de estar unos añitos con Java y volver a flipar con la velocidad a la que se ejecutan cosas

1 19
#144 maloconocido

#33 me encanta js porque prácticamente puedes usarlo en cualquier sitio hoy en día, abres la consola del navegador y a programar.

1 15
#145 Tannhauser

#128 Ahí le has dao.

0 6
#146 maloconocido

#44 A mí java no me ha dado mucho de comer pero me parece un lenguaje bastante ingenioso. Otro tema son las aberraciones que se pueden llegar a hacer con él, es muy fácil acabar con aberraciones institucionalizadas en el equipo de desarrollo. No quiero decir que en otros lenguajes no se pueda hacer código degenerado, pero unos te lo ponen más fácil que otros.
Por otro lado, el gran problema de Java, y de la mayoría de tecnologías que tiene un éxito aplastante, es que están condenadas a mantener compatibilidad hacia atrás a la vez que evolucionan, lo que en la mayoría de las ocasiones no resulta en una extensión muy elegante del lenguaje. Un ejemplo muy claro es la carencia de paso de funciones para usarlas como callbacks (otra forma muy potente y sencilla de reutilizar código) algo que existe en lenguajes como js, Python, go, c, etc desde hace décadas pero que en Java han podido incorporar recientemente haciendo una extensión importante del lenguaje. Han llegado a desarrollarse lenguajes nuevos más modernos como scala y kotling que compilan directamente al bytecode de la JVM. Cómo último punto negativo a destacar, es la propiedad del lenguaje, que pertenece a una empresa privada con ánimo de lucro, y estás sujeto en mayor o menor medida de lo que un equipo de marketing y abogados decidan hacer con el lenguaje y la JVM para obtener el máximo beneficio económico, es decir, se pierde libertad.
Por otro lado, una de sus principales ventajas es que se ha invertido mucho en optimizar la JVM, es sorprendente ver cómo rivaliza con lenguajes compilados. Además tiene una base de librerías brutal, que encajan muy bien en el entorno empresarial más clásico. Como guinda, es el lenguaje en el que se suelen desarrollar aplicaciones Android.

1 17
#147 maloconocido

#57 aunque te generen la función por detrás, ejecutar eso siempre es una llamada a función, bastante ineficiente. La ventaja de los getters/setters es que puedes cambiar el comportamiento al leer o escribir atributos, ocultas la representación, sin necesidad de modificar los usuarios de esa clase. Pero en una gran cantidad de ocasiones solo se necesita una clase con atributos públicos sin métodos.

0 7
#148 maloconocido

#83 y el TOML ya es la complejidad absurda por amor al arte, es tan complejo que no siquiera hay una gramática definida a día de hoy. (Lo siento Tom, pero no estoy seguro si crear GitHub compensa el daño hecho con el TOML)

0 7
#149 maloconocido

#101 creo que estamos de acuerdo, pero eso no excluye la cagada de los espacios: si mueves un trozo de código a otro sitio con otro nivel de indentación no es suficiente.

0 7
#150 maloconocido

#107 totalmente, puedes programar en C toda la vida y no saber cómo se pasan los datos las funciones en el stack. Uno no aprende a programar hasta que no diseña su propia CPU y un lenguaje con su compilador y además con ese lenguaje crea otro lenguaje interpretado que se ejecuta sobre una máquina virtual también escrita con el lenguaje compilado.

0 7
#151 maloconocido

#89 la principal razón es la libertad que quita al desarrollador y a los usuarios al no ser un lenguaje libre, ni compilador libre, ni una implementación de la JVM libre.

0 7
#152 fanchulitopico

#119 también tienes la community edition

0 6
#153 llorencs *

#149 Cierto, que a veces las identaciones son un problema. Alguna que otra vez me ha dado problemas. Como por ejemplo tener un return dentro de un for y no darme cuenta. Ya que lo último que sospechaba era que había colocado mal el return. Y me llevó un buen tiempo encontrar el error.

1 18
#154 Remenad0r

#2 Clojure en lugar de Javascript o si prefieres algo más duro C++, Go. Pero como lenguaje Python claramente si ya conoces Java o C#.

0 9
#155 squanchy

#129 A una función con nombre la puedes llamar para aplicarle una serie de test unitarios y comprobar que la salida es correcta. A una función lambda que se suele especificar dentro de una llamada de otra función, no.

A una función con nombre puedes documentarla, indicando qué hace y qué significa cada uno de sus parámetros. Casi todos los editores permiten recopilar esa información si sigues un formato y crear la documentación. Con una función lambda, no.

En una función con nombre pones un break point y ves en qué entorno se está ejecutando (el valor de la pila y de todas las variables). En una función lambda sólo ves la propia función (aunque esto depende del depurador).

Cuando estás depurando y se llama a una función con nombre, sabes qué función es y dónde se encuentra. Cuando es una función lambda que se ha pasado a través de varias clases y módulos, y se ha ido renombrando en cada llamada, no tienes ni idea de por dónde te está llegando. Ponte a mirar por la pila, y si estás en un framework de javascript date por jodido.

0 10
#156 vickop

#155 Estoy de acuerdo contigo en parte. Creo que no se debe abusar de las lambdas por algunos de los motivos que comentas. Por otro lado, las funciones lambda dan cierta versatilidad. A veces es interesante tener punteros a funciones, de manera que puedas almacenarlas dinámicamente. Quitan complejidad ciclomática al código y muchas veces aporta legilibilidad.

Por lo menos, en Java 8 resultan útiles muchas veces.

En cualquier caso, comparto bastante lo que dices.

0 9
#157 vickop *

#134 No es cierto. Lo errores dependen completamente de lo restrictivo que sea el compilador o intérprete. Si en un lenguaje orientado objetos, el compilador te permitiera sin rechistar que ejecutes código privado de una clase a la que no perteneces, estaría fomentando los errores.

Del mismo modo, mientras un navegador ejecute código que tiene mal el tipado, estará fomentando que no te des cuenta de los errores hasta que la ejecución pase por ahí.

La evolución de los lenguajes de programación a lo largo de la historia ha pasado por ir añadiendo mecanismos que eviten que el programador la cague.

0 9
#158 tranki *

#138 Pozí. Antes de C el assembler era mi lengua de programación, soy capaz aún de programar en assembler lo que quiera y donde quiera.
Eso si es programar, lo demás son "apaños", excepto c

0 7
#159 Cazatrolls

#48 Te voto positivo, no porque recomiende VBA, sino porque me parece indecente que en este foro frían a negativos a una persona por dar su opinión (y encima intentando ayudar).

3 44
#160 maloconocido

#157 creo que no has entendido por donde iba mi comentario. Tienes otros lenguajes que transpilan a JavaScript, por ejemplo Dart y TypeScript.
La afirmación que dijiste es como decir que ningún lenguaje es bueno para controlar errores porque al final todo es código binario y es muy fácil cometer errores escribiendo código binario.

0 7
#161 vickop *

#160 Yo solo digo que mientras el navegador siga interpretando JavaScript en vez de solo TypeScript, seguiremos teniendo webs plagadas de errores.

0 9
#162 maloconocido

#158 madre mía lo que hay que leer. El assembler es totalmente dependiente de la arquitectura, si hace tiempo que programabas en assembler lo que te acuerdes solo servirá para la arquitectura que aprendiste, pero tienes bastantes arquitecturas vigentes hoy en día, x86, amd64, arm, PowerPC, mips, sparc... Además cada una añade extensiones del juego de instrucciones. Por no hablar de los microcontroladores tipo Arduino, Texas Instruments y similares, que cada uno es de un padre y una madre.

0 7
#163 maloconocido

#161 no tiene que ver tío. Con lo de "solo TypeScript" no arreglas nada ya que es un superconjunto de js, es decir, si interpretarse solo TypeScript podria ejecutar también cualquier código JavaScript.

0 7
#164 vickop *

#163 A ver si te lo dejo claro. Quiero que el intérprete me haga un chequeo de tipos de todo el puñetero código. Como en cualquier lenguaje compilado, y cuando haya un error, me lo diga.

Mientras el intérprete no se queje porque deje un fallo en un punto por donde la ejecución no pasa en ese momento, estaremos trasladando los problemas. ¿Dices que TypeScript soluciona eso? Pues quiero que el intérprete sea lo único que permita.

0 9
#165 maloconocido

#164 ¿sabes que los errores en tiempo de compilación no son los únicos verdad? Incluso con tipos y análisis estático te puede petar en ejecución. Java igual crees que es la perfección, con su tipado pero todos hemos visto null pointer exceptions como usuarios.

0 7
#166 vickop *

#165 ¿sabes que los errores en tiempo de compilación no son los únicos verdad? Incluso con tipos y análisis estático te puede petar en ejecución

Oye, que no empecé a programar ayer. Algún error sí he tenido algún día

Nadie está diciendo que sean los únicos posibles errores que puedes tener a la hora de programar. Lo que estoy diciendo es que es una fuente habitual de errores, y si tienes una herramienta del lenguaje que te lo evita, y te impide cometerlos, mucho mejor. Y no es una herramienta tonta. La fase de análisis semántico de un compilador es algo que evita infinidad de posibles casos de error por los que, por mucho énfasis que pongas, no podrás cubrir en el testeo.

Java igual crees que es la perfección

Tío, no gasto de creencias políticas o religiosas a la hora de debatir temas técnicos. El hecho de criticar una tecnología no me hace amante de otra. Estoy criticando temas objetivos.

0 9
#167 tranki *

#162 Pues sí, todos los uP son lo mismo, algún registro por aquí y otro por allá, ¿8, 16, 32, 64 bits?
Y no es que haga tanto tiempo, sigo programando en assembler, ¿qué va a variar? ¿el set de instrucciones? ¿qué aportará un set de un uP a otro? ¿poder mover y comparar memoria?, ¿instrucciones matemáticas?
¿Qué tan diferente es un uP de otro? Métodos de direccionamiento, directos, indexados. relativos, absolutos?
Dame una hoja de datos, un set de instrucciones y en una tarde te programo lo que quieras.
Todos los juegos de instrucciones son lo mismo con diferentes mnemónicos.
Vectores de reset, interrupciones con o sin máscara, ¿qué diferencia hay un uP de otro?
No, no es difícil, es una tecnología muy clara y repetitiva. Eso si, dependerá del hardware que quieras asociar a ese circuito, pero el uP esta chupao!

0 7
#168 maloconocido

#167 te tomo la palabra! Hacemos un hackathon una tarde y de paso aprendo algo.
De assembler solo he trasteado un poco con un arm en la carrera y con un procesador muy básico que tuve que diseñar y construir, con su traductor de assembler a máquina.

0 7
#169 maloconocido

#166 buenas noches

1 16
#170 tranki *

#168 Challenge accepted.
Dame un un chip (marca y modelo) y un circuito no muy complejo (no vamos a hacer un SO) hago el circuito y lo programo.
Piensa que podría ser...

0 7
#171 maloconocido

#170 El que lleva la Raspberry Pi 3B+ que lleva un Broadcom ARM Cortex‑A53 de 64 GHz y 64 bits
Podríamos hacer algo que use varios cores, por ejemplo leer un archivo de disco, ordenarlo con merge sort y volver a escribirlo.

0 7
#172 tranki

#171 No está mal, me mola, me has metido acceso a archivos que no es fácil, pero acepto.
Déjame un par (o tres) de días para hacerme con la info. y el material.
Cuando lo tenga todo preparado te aviso y me das la señal de salida.
Te aviso sobre el jueves-viernes proximo (esta semana que viene tengo un viaje del curro)

Palabrita del niño jesús.

0 7
#173 maloconocido

#172 tranquilo, no hay prisa tío esto es por pura diversión y por aprender.
Para el acceso a archivos si prefieres le instalamos un linux y lo hacemos llamando al kernel. O también se puede ir en plan hard contra la controladora y en vez de sistema de archivos se lee de un rango de bytes y se escribe en otro.

0 7
#174 Conde_Lito

#45 No por dios, punteros no, todo menos punteros.
Es lo que más odio del C y C++

1 23
#175 fanchulitopico

#140 Lo que dices sobre los frameworks es una obviedad stackoverflow.blog/2018/01/11/brutal-lifecycle-javascript-frameworks/
Por qué te ha resultado difícil aprender angular?

0 6
#176 Conde_Lito

#79 Pues depende de para qué el ensamblador puede venir muy bien y ser mucho más fácil programar lo que sea que con un lenguaje más alto.
E incluso en código máquina, ya que el ensamblador no es más que la traducción literal del código máquina, es más fácil memotécnicamente de recordar los opcodes y mucho más rápido de escribir, no tienes que intruducir por ejemplo una instrucción en el micro diciendo por que pata vas a introducir el dato, por esta pata temeto un 1, por esta otro 1, por esta un 0, y por esta un 1, dar la orden de lectura y así sucesivamente.

2 29
#177 Conde_Lito

#88 OT

1 23
#178 Conde_Lito

#1 Sin duda Fortran

1 23
#179 U5u4r10

#1 Ederly

0 9
#180 RubiaDereBote *

#99 Y actionscript, se sigue usando y va a dejar de evolucionar
Txori se usa, se usa hoy en día tanto como cuando fue creado y para lo mismo que fue creado. Simplemente no hay necesidad de cambiarlo.

No es más fácil decir (si quieres meter con calzador que "evolucionan"), algo del estilo?: los poquitos lenguajes que yo uso siguen evolucionando.

0 11
#181 dameAbrazos

#132 Yo he probado go, y lo que me resultó super incómodo es trabajar con el JSON

¿Algún consejo?

0 7
#182 mirav

#151 Mira tu si no hay jvms libres a dia de hoy: en.wikipedia.org/wiki/List_of_Java_virtual_machines#Free_and_open_sour esto te incluye compilador y la propia implementacion de la jvm.

Lo mejor es que existen lenguajes libres que compilan sobre la jvm, con lo que puedes escribir por ejemplo scala y correrlo sobre openjdk.

0 7
#183 maloconocido

#175 dónde he dicho eso?

1 14
#184 maloconocido

#182 y que le pasó a Google que se implementa su propio compilador, su propia máquina virtual y aún así estuvo en un juicio con Oracle?
Tienen los derechos de todo, el lenguaje, compilador, bytecode, JVM, librería estándar... Da igual lo que uses, si quieren denunciarte, te denuncian

0 7
#185 fanchulitopico

#183 "todo ello para acabar con un código que en un par de años estará depreciado"
Es un hecho, obvio. Y tienes razón. El ciclo de vida no es largo.

0 7
#186 maloconocido

#181 gobyexample.com/json
Para ser un lenguaje tipado, la serialización/deserializacion en json la resuelven bastante bien.
En resumen, usa tags json, puedes deserializar sobre cosas que son structs (como por ejemplo map[string]interface{} ) pero tendrás que tirar de casting, y por último puedes sobreescribir los métodos marshaljson y unmarshaljson para un struct concreto.
Como extra, go te permite leer json en streaming, lo que te permite ahorrar memoria y reducir latencia.

0 7
#187 --569461-- *

#150 Diseñar una cpu o un lenguaje no es lo mismo que programar pero oye, si a ti lo que te mola es hacer comparaciones absurdas, por mí no pares...

0 8
#188 maloconocido

#187 andywarroll menudo troll eres. No sé si sabes que hacer un compilador implica programar, hacer una máquina virtual implica programar, hacer una CPU también implica programar (VHDL por ejemplo) y escribir un programa en un lenguaje de programación que has inventado también implica programar.

0 7
#189 --569461-- *

#188 hacer un compilador implica programar

¿Dónde he dicho lo contrario? Y perdona pero diseñar una CPU no tiene por que hacerse en VHDL.

y escribir un programa en un lenguaje de programación que has inventado también implica programar.

Ahhh otra vez poniendo palabras en mi boca que yo no he dicho. Puedes hacer todos los hombres de paja que quieras y seguir pegándote con ellos si eso es lo que te mola, eh?

0 8
#190 maloconocido

#189 troll

0 7
#191 --569461--

#190 Dijo, cuando no le quedaban argumentos.

0 8
#192 maloconocido

#191 pero qué argumentos si no entiendes de qué estamos hablando. Mira que tienen razón, no alimentes a los putos troles, pero a veces me dan tanta pena que les echo de comer.

0 7
#193 --569461--

Que no entiendo dice

Dime una sola cosa que haya dicho que no sea cierta.

0 8
#194 --516070--

#53 Bueno, si quieres rizar el rizo, siempre puedes programar en Kotlin transcompilando a JS.

Conozco una empresa que usa Kotlin para backend y para móviles y front con Nativescript.

0 8
#195 --516070--

#119 Esta es la respuesta correcta.

No quieres líos, quieres simplificar lo máximo posible porque estás empezando. Con Visual Studio Express y C# lo tienes todo para hacer pequeñas aplicaciones de escritorio con las que trastear y probar mientras aprendes.

Al fin y al cabo necesitas algo que simplemente bajándotelo y dándole a un botón, funcione. Hay millones de libros de C# por ahí que te ayudarán paso a paso y que, cuando lo termines con sus ejercicios, te da la experiencia necesaria como para poder seguir por ti mismo.

0 8
#196 --516070--

#40 #142 Nada está basado en Java, si acaso en Ecmascript 6

Utilizan la JVM, que es muy diferente.

Yendo un poco más lejos, desde hace muchos años Java siempre ha ido a remolque, cogiendo los aspectos interesantes de otros lenguajes.

0 8
#197 --516070--

#83 A mi utilizar indentacion en lugar de llaves me parece un infierno respecto a la legibilidad

Es un infierno. No te lo parece.

Por definición, depender de algo invisible es una mala idea de diseño.

Por supuesto, a todo se acostumbra uno.

0 8
#198 --516070-- *

#146 Kotlin.

Por otro lado, el lenguaje oficial Android es Kotlin, no Java. Aunque se puede usar Java 6, claro.

0 8
#199 --516070--

#50 C# , para hacer aplicaciones Windows que puedas subir a su misma tienda.
Pero el desarrollo windows se ve mucho menos que antes, pudiendo tenerlo en un navegador.

0 8
#200 --516070--

#107 #78 He escuchado la misma frase sobre ensamblador.

1 15