El lenguaje de programación V: ¿vano o virtuoso?

Si se mantiene al día con las noticias de programación de nicho, es posible que sus oídos hayan flaqueado recientemente con el lanzamiento de un nuevo lenguaje de programación: V. Siempre se publican nuevos lenguajes de programación sobre proyectos de pasatiempos, argumentaría correctamente; ¿En qué se especializa este? La respuesta es una serie de opciones de proyectos que promueven la velocidad y la seguridad: V es pequeño y muy rápido. También se encuentra en un estado alfa autodeclarado, y aunque ya se ha utilizado para construir algunos proyectos interesantes, todavía se encuentra en una etapa temprana.

Dime más

El sitio web de V, vlang.io, dice que es

Un lenguaje compilado simple, rápido y seguro para desarrollar un programa mantenible.

Cada una de estas palabras clave es una piedra angular de la filosofía de V que surgirá a lo largo de este artículo.

"Software sostenible" se refiere a las elecciones de proyectos altamente intencionales de V que obligan a los desarrolladores a adoptar determinadas mentalidades. En muchos sentidos, V es similar a Go, que toma decisiones de proyectos similares que algunos considerarían audaces. (Por ejemplo, sin excepciones y sin clases / herencia tradicionales).

V afirma estar inspirado por Go e influenciado por Oberon, Rust y Swift.

Entonces, ¿qué tan rápido es?

El hecho principal de V es que puede compilar alrededor de 1.2 millones de líneas de código por segundo para un núcleo de CPU (desde i5-7500).

Debido a que el compilador V en sí es pequeño, con 400 kB, este autor obtuvo un compilador V en menos de un segundo. ¿Es ese hecho más que un truco para cualquiera que intente escribir algo con una V? No, pero demuestra un punto de simplicidad.

Git clonando V y luego ejecutando make primero compila V con un compilador de C, luego usa la implementabilidad de V resultante para compilarse a sí mismo. No tuve ningún problema para ejecutarlo en Linux, pero tuve que trabajar un poco más para obtener una compilación perfecta en Windows. Actualmente, la generación directa de código de máquina solo está disponible para x64 / Mach-O. Sin embargo, para fines de 2019, V 1.0 debería lanzarse con soporte para todos los x64, lo que puedo creer debido a la velocidad de desarrollo actual.

Funciones y opciones de proyectos

V está muy inclinado a forzarte a escribir un buen código; tan ansioso que algunos podrían argumentar que a veces puede ser impetuoso, dejaré que usted decida eso. Por ejemplo, las variables no utilizadas dan como resultado un error de compilación en lugar de una advertencia.

Debido a la simplicidad de V, los documentos son muy breves. De hecho, se afirma que es posible leerlos en media hora y absorber todo el idioma. No estoy del todo seguro de que esto sea algo de lo que presumir, debido a la clara inmadurez de los documentos debido al proyecto en sus primeras etapas. Sin embargo, leerlos aún destaca algunas características interesantes:

Seguridad

Se establecen políticas estrictas para tratar de hacer que V sea lo más seguro posible, especialmente en relación con los subprocesos. Estas políticas incluyen:

  • Sin variables globales o estado global (incluso a nivel modular)
  • Las variables siempre deben declararse con un valor inicial
  • Las variables se definen como inalterables de forma predeterminada. Tienes que usar mut para especificar explícitamente lo contrario.
  • No hay variables con nombre ya utilizado en el ámbito principal
  • Memoria

    V no es basura recolectada, una diferencia significativa con Go, ni siquiera calculada por referencia. En cambio, es más como Rust, administrando la memoria durante el tiempo de compilación. Desafortunadamente, esto solo funciona actualmente para situaciones básicas; La gestión manual es necesaria para casos más complejos que son otro WIP.

    El creador de V [medvednikov] Admite rápidamente que la gestión de la memoria aún no es lo suficientemente segura, pero que se mejora constantemente. Ciertamente es algo en lo que se puede trabajar para hacer que la gente crea en las características de "seguridad" del idioma. Y si hay algo que hemos aprendido de los últimos treinta años de seguridad informática, es que abundan los recuerdos de la gestión de la memoria.

    Manejo de errores

    V no tiene excepciones, similar a Go. Nosotros pensamos [Dave Cheney] hace un buen trabajo explicando por qué.

    En cambio, hay un tipo de Opción / Resultado combinado, tan simple como la suma ? al tipo de retorno y, opcionalmente, devolver un error. A continuación, se muestra un ejemplo de cómo podría funcionar:

fn find_user_by_id(id int, r Repo) ?User { 
	for user in r.users {
		if user.id == id {
			// V automatically wraps this into an option type  
			return user 
		} 
	} 
	return error('User $id not found') 
}

La función devuelve el tipo ?User, que podría ser un usuario o un error. Al llamar a la función, esto podría extenderse al siguiente nivel llamando find_user_by_id(id, repo)? (en este caso, la función padre debe tener Opcional como su tipo de retorno). Esto significa que la propagación de errores sigue siendo fácil y no requiere el uso del modelo excepcional de prueba y error.

Próximamente características

  • Soporte de código de unión en línea
  • Recarga en caliente: cambios de código sin recompilación (editar: ¡ahora hecho!)
  • Gerente de empaquetación
  • Todas estas parecen características triviales para implementar y lanzar rápidamente, pero la velocidad de desarrollo en el proyecto es impresionantemente rápida.

    Proyectos construidos por V

    El creador de V, [medvednikov], lo usó para construir una serie de proyectos.

    V fue creado para desarrollar Volt, un cliente de mensajería de 300 KB capaz de manejar / mover miles de mensajes sin demora. Es interesante notar que V constituye gran parte de sus capacidades de compilación de intercomunicadores existentes y afirma ser principalmente multiplataforma, pero que Volt actualmente solo está disponible para Mac.

    Vid es un editor de código de plataforma de 200 KB, otro proyecto diseñado para ser ligero y nítido. Esto debería estar abierto en julio, en cualquier momento ahora.

    Vtalk es un software de foro / blog que se utiliza para ejecutar el blog V, que también se abrirá pronto.

    Futuro

    Aquí está el gráfico de estrellas de GitHub contra el tiempo para V.

    Img cortesía de star-history.t9t.io

    Las estrellas de GitHub no son una indicación de mérito, pero ciertamente son un indicador de interés. lata conducir a aportes cualitativos de la comunidad de código abierto. Hay una gran cantidad de funciones marcadas como Trabajo en curso repartidas por la web y los documentos, y debo decir que algunas de ellas se ven realmente increíbles; se espera que la mayoría se publique en diciembre.

    Es muy fácil afirmar que su lenguaje es liviano cuando carece de características y tiene muchas correcciones esperando; en promedio, cada solución de tirón y error ingresada en un proyecto de código abierto agrega código en lugar de eliminarlo. Pero si V puede mantener sus dependencias nulas y su pequeño tamaño durante el desarrollo continuo, puede tener un lugar en el futuro.

    Conclusión

    Es fácil olvidar que todo el desarrollo de V hasta hace poco fue el resultado de un hombre: [medvednikov]. Después de algún tiempo jugando con el lenguaje, este autor no se sentiría cómodo escribiendo un nuevo proyecto en V en su estado actual. Pero si [medvednikov] Puede continuar el furioso progreso actual en el proyecto, tal vez muy pronto algo se emocionará muy pronto. No estoy listo para subirme al tren, pero definitivamente lo seguiré desde una distancia respetable.

    • pasgj dice:

      El problema con todos estos lenguajes de programación "seguros" es que la gente hará todo lo posible para reinventar las variables globales, las excepciones, etc. Y luego saldrá mal. Los lenguajes feos como Python, C o C ++ dominarán porque simplemente no les importa. ¿Quieres hacer algo estúpido? Adelante, pero no llores si te quemas.

      • Maave dice:

        Bastante genial, pero definitivamente me quedaré con Go por ahora. Go progresa y logra la mayor parte de lo que hace este proyecto

        • Maave dice:

          Si no editando: | no tenía la intención de responder

      • BastetFurry dice:

        Esta.
        Me encanta Perl como lenguaje de secuencias de comandos solo por eso, simplemente te permite hacer tu trabajo sin obstaculizarte. Te da un cable y te deja en tus propios dispositivos.

        • Ren dice:

          Para llevar tu analogía un poco más lejos ...

          Y con C, después de tocar la cuerda, automáticamente se envuelve alrededor de su cuello y hace un nudo corredizo.
          (¡Gracias a los "dispositivos" de los desarrolladores anteriores!) ¡Depende de usted no saltar de la silla o ser empujado por otra persona!
          B ^)

          • Alex Rossie dice:

            C ++ hizo arreglos para que un sicario viniera a por ti

        • JWhitten dice:

          +1000 para Perl.

      • Slartibart dice:

        El problema de ser fatalista es que siempre tienes la razón, incluso cuando estás completamente equivocado.

      • deshipu dice:

        No es que se nos permita usar un solo idioma que "dominó" al final. Cuantas más opciones, mejor.

        • Ren dice:

          ¡Eso no impedirá que Taco Bell gane la Restaurant Wars!

    • Nate B dice:

      Bien, entonces, ¿para qué sirve? ¿Cómo son las bibliotecas de E / S? ¿A qué microcontroladores puedo apuntar con él?

      • Elliot Williams dice:

        "C" y "V" están una al lado de la otra en el teclado. Sospecho de un error tipográfico.

        • deshipu dice:

          Hablando de eso, me pregunto si X ya está tomado.

          • BrilaBluJim dice:

            No sé si desea que su código fuente esté en archivos X.

        • JWhitten dice:

          "C" y "V" también están una al lado de la otra en la línea de empleo.

    • Brian dice:

      ¿Lenguaje del "proyecto de hobby"? ¿No necesitas una gestión de memoria compleja? ¿Github como métrica? ¿Los artículos WIP están programados para ser lanzados "pronto"? Caray, ustedes son tan fáciles. ¿Quiere comprar algunas propiedades soleadas, secas y cálidas en el norte de Escocia?

      Este tipo estaba un poco indeciso, consulte https://news.ycombinator.com/item?id=20229632

      Hay muchos otros buenos proyectos lingüísticos en desarrollo que son proyectos legales. Mire cada vez más lejos.

      • kosmo kramer dice:

        De hecho. Me vienen a la mente Idris y Pony.

      • no desprecies a una serpiente dice:

        Hmm, habiendo leído ese enlace, no puedo decidir si es un engaño o simplemente un vapor.

    • JRD dice:

      "Las variables se definen como inalterables de forma predeterminada".

      Realmente ... no son realmente "variables", ¿verdad? ¿Podrías incluso decir que son “constantes”?

      (¿O son todos objetos y recarga uno con un nuevo objeto cuando necesita actualizarlo, como String de Java?)

      • Palmadita dice:

        "Realmente ... no son realmente 'variables', ¿verdad? ¿Incluso podrías decir que son 'constantes'?"

        No es que no esté de acuerdo, pero "variable" no significa exactamente lo mismo que "variable". Variable implica una variable, una variable no implica una variable. Si una variable se declara como modificable de forma privada, por ejemplo, es variable fuera del módulo (* se * puede cambiar) pero no se puede cambiar fuera del módulo.

        Extraño Sin embargo, las convenciones de nomenclatura son bastante comunes en los lenguajes: declarar algo "constante" en C es ridículo. ¡Constante, pero capaz de cambiar de inmediato!

        • Lucas dice:

          Eso no es extraño en absoluto. Una palabra clave volátil de C es un calificador que le dice al compilador que el valor de la variable puede cambiar en cualquier momento, sin que el código que el compilador encuentre cerca realice ninguna acción. Significa que el compilador no debe optimizarlo reemplazando la constante con el valor declarado, sino que debe referirse a una memoria que algún otro proceso puede cambiar. Esto es extremadamente importante porque la variable en cuestión puede ser E / S mapeada en memoria.

          “Const”, por otro lado, asegura que USTED no esté intentando cambiar el valor accidentalmente porque el compilador le arroja un error cuando lo hace.

          • Lucas dice:

            https://stackoverflow.com/questions/4592762/difference-between-const-const-volatile#4597164

            Si no lo declaró constante, fácilmente podría cometer el error tipográfico:

            si (var = 1) ...

            y su compilador no sería más sabio, y su código fallaría silenciosamente.

          • Palmadita dice:

            ¿No ve el oxímoron inherente en algo que puede cambiar constantemente en cualquier momento?

            El problema no es el concepto, sino la palabra clave. "Const" en realidad significa "solo leer", no "constante". Lo mismo que las "variables de este lenguaje son inmutables".

            • Elliot Williams dice:

              Esta.

              Constante significa solo legible.
              Los recursos volátiles no me optimizan, hermano.

              Pero mientras estamos aquí, "variable" tampoco significa cómo suena. Las variables son mapas constantes de una cadena a un número, que resulta ser una dirección de memoria donde se pueden almacenar los datos. En el fondo del compilador, la variable no cambia, solo las cosas en la ubicación de la memoria a la que alude.

              ¿Algunos lenguajes "seguros" modernos tratan las variables como tales que son: ubicaciones de memoria compartida? ¿Cómo podría obviamente mutex para algo así ...

            • rubypanther dice:

              OTOH, si resulta que se permite que las palabras tengan más de un significado, entonces "const" significa exactamente lo que C define como significado. Lo mismo para volátiles.

            • Palmadita dice:

              "OTOH, si resulta que las palabras pueden tener más de un significado, entonces 'const' significa exactamente lo que C define como significado. Lo mismo para volátil".

              Y lo mismo ocurre con una variable en este idioma, y ​​ahora hemos regresado al punto original de que a veces los idiomas usan palabras clave con significados diferentes a su uso familiar.

    • Rog Fanther dice:

      Los tres puntos importantes mencionados en la parte de "Seguridad" del artículo son agradables y evitarían muchas advertencias de error / compilación. Si pudieran introducirse en un idioma "oficial" normal, tanto mejor.

      El cuarto punto, sobre las variables no variables, suena extraño ...

      • Ostraco dice:

        "El punto 4, sobre variables no variables, suena extraño ..."

        ¿Quizás son variables cuánticas?

        • Rog Fanther dice:

          ¿Tendrían un 50% de posibilidades de estar allí cuando te acerques a ellos?

          • Shannon dice:

            Oportunidad, no necesariamente un 50% de probabilidad.

          • Protagonista de Hiro dice:

            No, un booleano contendría amplitudes probables para verdadero y falso. Los rangos de probabilidad verdadero y falso son independientes [i.e. not correlated].

            Los escalares de n bits codificarían valores de 2 ^ n-1 bits.

        • Moryc dice:

          Si son variables cuánticas, cada una debe contener todos los valores posibles y, cuando se utilizan, debe tener el valor más probable. Es por eso que no necesitan ser cambiables: todos mantendrán el valor necesario en un punto dado en un continuo espacio-tiempo ...

          OTOH si fueran variables de Schrödinger, todo sería tanto variable como constante y probablemente no se declararía en absoluto al mismo tiempo ...

        • greenbit dice:

          Oh, triste, estamos en camino hacia un lenguaje donde las variables pueden declararse "involucradas". La lectura de uno establece automáticamente el valor del otro. Oh mi cabeza

          • jmdlugosz dice:

            Recuerdo un módulo de Perl que hace esto. Implementa la lógica mecánica cuántica completa (necesariamente trabajando exponencialmente más números a medida que las cosas se vuelven más complejas).

          • Ren dice:

            ¡Pero solo si no establece la bandera del Principio de incertidumbre de Heisenberg (HUP)!

          • BrilaBluJim dice:

            Algunos lenguajes funcionales hacen precisamente eso: si en algún punto de un programa dices "y = 2 * x", TODO cuando cambias x, y cambia. Las hojas de cálculo también lo hacen.

        • Nido dice:

          Puede saber cuál es ese valor o cuál es el nombre de la variable, pero no ambos al mismo tiempo.

          • BrilaBluJim dice:

            Peor que eso: ¡puede saber cuál es el valor o la velocidad a la que cambia!

        • salec dice:

          Programación Tao Te: "La variable variable no es una verdadera variable ..."

    • alksio dice:

      "Estás muy inclinado a forzarte a escribir un buen código" = inútil, entrelazado e inútil.

      • BrilaBluJim dice:

        Me perdieron por “no tener variables globales”.

    • Jonathan dice:

      Oh bien ... Otro martillo nuevo ...

      • Shannon dice:

        ¿El hombre de las cavernas habló de herramientas de hierro?

        • greenbit dice:

          "La censura le dice a un hombre que no puede comer un bistec solo porque un bebé no puede masticarlo". - Siempre que se dice que un nuevo lenguaje nos obliga a escribir un código "bueno", se siente un poco así. No es de mucha utilidad para herramientas no infectadas intencionalmente

          • rubypanther dice:

            He visto muchos lenguajes de programación, pero todavía he visto uno que puede incluso obligarte a escribir código, sin importar la calidad.

            Java tiene como objetivo intentar hacer las cosas "nerf". Esto se parece más a Golang, donde las cosas que no quieren que tengas, simplemente no las incluyeron. No es que esté "inmaduro", es que no está inmaduro, no viene con una linterna LED plegable y ni siquiera tiene un compartimento secreto con un palillo de dientes de emergencia. Es solo el adzo.

            Para mí, el problema es que depende tanto de la CPU que solo admite un subconjunto de x86; aunque primero se compila a partir de C. Eso no me da la confianza de que pueda madurar y, sin embargo, ser rápido / seguro / bueno / etc. Yo voto a Vana.

        • Jonathan dice:

          él. Más relacionado con modas efímeras en lenguajes / herramientas / metodologías / etc 🙂

    • Lou dice:

      ¿Por qué? Solo porque ??
      No se puede convertir en "bueno" a un mal programador con un cambio de idioma.
      Para citar al Sr. Gump:
      Estúpido es tan estúpido.

      • Alex Rossie dice:

        Creo que la cosa parece una mala V? Porque los malos C y C ++ son difíciles de detectar.

        Para proyectos comunitarios más grandes, es ideal que alguien pueda detectar fácilmente el código incorrecto y, cuanto menos oportunidades tenga, cuanto más lea a pie, más fácil será detectarlo.

        Esta es también la razón por la que Linus insiste en que el núcleo está escrito en C. Cuando comenzaron, pudo detectar una C mala mucho más fácilmente que una C ++ mala

        • Jonathan dice:

          Es mucho más complicado que solo la opinión de Linus. Como siempre ...

          Uno de los problemas son los límites de tiempo. En un caso anterior se estimó que sería necesario portar el kernel a C ++ mínimo de dos años.

          Los defensores de C ++ se han negado (y todavía se niegan) a aceptar esto, por supuesto, alegando que pueden hacerlo durante la mitad del tiempo. Si. Derecha ...

    • Desarrollador ansioso dice:

      Sí, otro clon "seguro" de calidad alfa de C, y este ni siquiera se basa en LLVM (lo que le permite compilar objetivos y optimizaciones de forma gratuita) ...

      "1,2 millones de líneas de código por segundo" es la peor métrica de rendimiento de compilación que he visto.

      • Adrian dice:

        Esa declaración me recordó esta vieja broma:
        Persona 1: Oye, escuché que eras extremadamente rápido en matemáticas.
        Persona 2: Sí, soy el más rápido allí
        Persona 1: ¿Qué es 13 × 29?
        Persona 2:51
        Persona 1: ¡¿¡Eso ni siquiera se acerca!?!
        Persona 2: Sí, ¡pero fue rápido!

        • Paul dice:

          int getRandomNumber ()
          {
          volver 4; // Elegido por un buen dado, garantizado por azar.
          }

          // XKCD 211.

      • Rasmus Schultz dice:

        Tiene un backend C, por lo que no es un clon de C, se dirige a C.

        Por lo tanto, se dirige a LLVM con un compilador C, lo que le permite compilar objetivos y optimizaciones cuando los desee, mientras que el compilador nativo x64 extremadamente rápido obtiene un giro rápido durante el desarrollo, la ejecución de pruebas, la recarga en caliente, etc.

        Honestamente, es algo que otros idiomas podrían aprender. Los compiladores de hoy son extremadamente lentos en comparación con los compiladores de hace 15-20 años; esto es tan rápido como deberían ser los compiladores si su rendimiento no se ha deteriorado tanto a lo largo de los años.

        A pesar de todo el valor que aporta LLVM, es en parte culpable del drástico rendimiento de los compiladores modernos: las computadoras son mil veces más rápidas que en la época de Turbo Pascal, y la compilación actual es * más lenta * que en los años 90.

        Me alegra ver que alguien, al menos, intente que volvamos a las velocidades de compilación que deberíamos ver hoy.

        • Alex Rossie dice:

          ¿La compilación es realmente más lenta que en los 90? ¿O quiere decir que no es tan rápido como lo sería un compilador moderno compilado de los 90 en el mismo hardware?

          Estoy seguro de que los compiladores son más rápidos en tiempo sin procesar de lo que recuerdo de los 90

      • rubypanther dice:

        Anteriormente, medíamos a los compiladores por la cantidad de días que tomaba compilar el sistema X-Window.

    • Perro James dice:

      Si no se ha roto, no lo arregles. C hace todo lo necesario, ¿por qué nuevo? ¿Qué se esconde en él que no se nos dice?

      • Ostraco dice:

        Fugas de memoria, desbordamientos de búfer, tales cosas.

        • tekkieneet dice:

          En otras palabras, C no puede arreglar la estupidez.

          • greenbit dice:

            Así es, C no pierde memoria *, ¡maldito código de hecho!

            * .. cancelar ptrons nulos, borrar dos veces, devolver mierda de la pila, inf recurse, etc.

        • Alex Rossie dice:

          Sin mencionar algunas oportunidades de orientación a objetos.

    • ciudadano dice:

      sí, yo no llamaría a esto un "ritmo furioso". según el autor, el lenguaje se ha desarrollado durante casi 2 años, y si miras el código publicado, es básicamente un preprocesador de sintaxis pendiente para C que depende de gcc para realizar una gran cantidad de trabajo de compilación. Si ves la primera demostración de Jon Blow de su lenguaje favorito, después de un mes de trabajo paralelo, tenía muchas más cosas de las que tiene este proyecto ahora.

    • Greg A. dice:

      En general, esto simplemente me recuerda lo disgustado que estoy por mi breve exposición a Rust, un lenguaje cuya completa falta de virtud se ve oscurecida solo por su falta de implementación. Pero esto realmente lo lleva a un nuevo nivel: "las variables no utilizadas dan como resultado un error de compilación en lugar de una advertencia". Me refiero a -Wall y -Werror de gcc, por así decirlo. Dios sabe que me encuentro con advertencias que representan errores reales. Pero esto solo te da una pesadilla mientras trabajas. Solo otro maldito conjunto para omitir si necesita comentar un código grande mientras está depurando algo. Tan malo como la regla de Java "booleano constante es un error". Honestamente, no creo que ningún idioma valga la pena restringir severamente su entorno (Rust en ARM sigue siendo un truco de una sola vez, por ejemplo), pero realmente hace una farsa cuando las únicas personas que quieren inventar un nuevo idioma. si la gente no tiene suficiente experiencia para saber por qué todos los idiomas anteriores apestaban.

      • Alex Rossie dice:

        Sí, el compilador tiene un indicador -prod, que sería el momento ideal para cambiar el comportamiento de advertencia a error (¿realmente quieres eso?).

      • rv6502 dice:

        Esta.

        Pero primero, lamento si fuera genial "hey, acabo de leer el (antes rojo) Dragon Book y creé mi propio proyecto de compilador de juguetes / verificación de idioma" para contarlo, pero el sitio funciona de manera grandiosa e ingenua OMI, reclamaciones, ke:

        xkcd.fetch ("Un estándar más");

        Quiero agregar cosas teóricas de buenas ideas como errores sobre la conversión constante de entero a flotante (inofensivo) (float v = 0;) o doble a flotante (float f = 2.5;) y arrojar error en un idioma mientras escribir el mismo sufijo en otro idioma de la familia c es un error.

        Intente pasar su día laboral escribiendo en cuatro o más lenguajes similares mientras maneja diferentes reglas de seguridad / sintaxis completamente incompatibles (por ejemplo, C # para Unity, GLSL / HLSL / CG para sombras, C ++ / C para microcontroladores, JavaScript para servidor / página nodeJS, todas las partes se comunican entre sí y funcionará después de una semana).

        Puede * casi * pero no completamente cortar y pegar ese paquete de / serializador, esa verificación de validación, ese código de interpolación de curva de animación, esa fórmula de difusión / colisión, + varios otros fragmentos.

        ¿Sabes lo que necesita mi día? ¡Otro lenguaje de programación más!

        Si dedica tiempo y mercado para resolver algún problema de lenguaje informático inventando otro, asegúrese de que no cause más problemas prácticos de los que resuelve.

        Y Sudos señaló esto: https://christine.website/blog/v-vaporware-2019-06-23
        Un buen análisis de las extravagantes afirmaciones.

        No afirma que su lenguaje realice buenas prácticas de programación y ASIGNA ESTATUTAMENTE UNA TABLA GRANDE FIJA en el compilador para su tabla de declaración de función, lo que proporciona un límite de declaración codificado para cada función.

        No es de extrañar que sea "rápido".

    • tilk dice:

      Soy investigador de lenguajes de programación. Un comentario que me recuerda cuando leo sobre una compilación rápida es que ciertamente no optimiza mucho. Los compiladores actuales pasan la mayor parte del tiempo de compilación en su optimizador. Lo que obtenemos de esto es el rendimiento del código compilado, que, para lenguajes tipo C, suele ser tan bueno o mejor que un conjunto escrito a mano. Dudo que el compilador V, en su modo directo a código de máquina, obtenga puntos por compilar el rendimiento del código; y si / cuando esté hecho, no será tan rápido (y probablemente reinvente LLVM en el proceso).

      • Daños severos a los neumáticos dice:

        ¡Más rápido que el lenguaje ensamblador! Hace una buena copia publicitaria.

        • tilk dice:

          Esto puede parecer incorrecto, pero en realidad es cierto. Las arquitecturas informáticas actuales son tan complejas, con todos los problemas de caché y coherencia, ejecuciones extraordinarias, especulaciones, etc., que la gente tiene MUY difícil predecir el rendimiento de su código. Los buenos compiladores de optimización son mucho mejores en esto.
          Incluso para arquitecturas más antiguas, ya no es útil escribir un ensamblado para la acción. Tengo un amigo que es profesor universitario y codificador de demostraciones y crea demostraciones galardonadas para computadoras Amiga. Escribe en C y lee el ensamblado resultante para configurar su código.

          • Artenz dice:

            E incluso si un programador humano puede producir un ensamblaje más rápido, no siempre tiene el motivo para hacerlo. Esto es especialmente cierto si ya ha terminado un proyecto grande, y todo funciona, y luego se le ocurre una idea mejor que es un 5% más rápida, pero cuesta reescribir por completo una gran cantidad de código ensamblador.

      • Murray dice:

        Quizás la velocidad neta de compilación está ahí para permitir la compilación continua en tiempo real, lo que permite mientras codifica reacciones erróneas. Cuando se requiere una compilación que genera un binario, se aplica la optimización completa.

        • rv6502 dice:

          En mis casos de uso, cuando el tiempo de compilación se convierte en un problema, es porque alguien incluyó Boost en el proyecto.

          Todo ese tiempo del compilador se dedica a analizar miles de patrones creados en exceso, muchos de los cuales son recursivos.

          Sobre aquellos proyectos que activan optimizaciones, apenas registran una compilación a tiempo.

          En proyectos más razonables, las optimizaciones pueden duplicar el tiempo de compilación; si actualiza un archivo de comportamiento de IA de 1 juego, el tiempo de compilación pasa de 1/8 de segundo a 1/4 de segundo.

          Todo lo demás involucrado en el proceso de habilitar la compilación continua en tiempo real y la aplicación de parches en vivo lleva mucho más tiempo.

          La velocidad de construcción me parece inédita, al menos en lo que respecta al compilador en sí.

    • Daños severos a los neumáticos dice:

      Que el cielo nos ayude. No es otro nuevo lenguaje de programación con todas las afirmaciones y el coraje habituales. Dispárales ahora antes de que se reproduzcan. ¿Nunca terminará? ¿Java no hizo las mismas promesas?

    • Sur dice:

      https://christine.website/blog/v-vaporware-2019-06-23 me parece que este lenguaje de programación es un montón de mentiras después de leer esto.

      • stevojo dice:

        Ojalá pudiera votar por ti.
        Leí ese artículo hace unos días, es una lectura bastante interesante.
        Me gusta especialmente esta pelota:
        "Más de 50.000 reclamaciones en función principal"
        Por lo tanto, el reclamo de 1.2 millones no es factible ya que se detiene en 50000.

        • Bs dice:

          Obviamente, se trata de estandarizar a la unidad completa más cercana. Usted toma un programa de x líneas de código, calcula cuántos milisegundos se necesitan para compilar y luego calcula cuántas líneas puede compilar por segundo. Nadie necesita que un automóvil conduzca durante una hora para calcular su velocidad, es lo mismo para calcular la velocidad de un compilador.
          Peor aún, el autor usa un programa con 1.2 millones exactamente de las mismas líneas de código. Esta es una muy mala forma de medir la velocidad, no representa en absoluto la compilación de un programa real.

    • TM dice:

      El formateo de K&R en el código de muestra es una mala señal. Es una desagradable restauración de BCPL> B> C> C ++> Java e indica una falta de respeto por la estructura de bloques (y generalmente una falla para definir la sintaxis LL1).

      YYMV (pero si es así, es un agricultor analfabeto) (-:

      • jmdlugosz dice:

        ¿Puedes profundizar en eso? ¿Qué pasa con el formato (en la parte superior de este artículo?) ¿Indica una estructura de bloques incorrecta y una gramática no simple?

        • TM dice:

          El 90% de la semántica de un bloque se trata de variables amplias. El resto, las condiciones y los rizos, son insignificantes en comparación. El uso de paréntesis para limitar los bloques es un consuelo maravilloso, y no me gustaría volver a Pascal ..., pero tiende a hacer que los desarrolladores subestimen la importancia de los bloques. El formateo de K&R empeora las cosas.

          C era una fea versión reducida de B, que era un BCPL reducido, que era un lenguaje desagradable para empezar.
          No es una gran base para un idioma del siglo XXI.

          El problema gramatical con LL (1) se pasa por alto ahora que tenemos CPU para quemar y la eficiencia del analizador no es un problema, pero el contexto depende de la basura, ya que la sobrecarga de "*" de C hace que la lectura de código sea una tarea para los humanos.

          Esperemos que los diseñadores de V hayan aprendido de los errores del pasado y no se hayan sentido obligados, por ejemplo, a limitarse a los símbolos del juego de caracteres PDP-8.

          Veo en el ejemplo que resolvieron la cuestión del "finalizador" o "separador" eliminando el punto y coma por completo. Un comienzo brusco.

    • Dylan Turner dice:

      La gente odia tanto esto simplemente por lo que dice. ¿A quién le importa lo que algo pretende hacer? Todo es completamente absurdo. La única forma real de juzgar un idioma es realmente usarlo.

      De hecho, tratar de programar en esto es realmente bastante bueno (excepto por todas las bibliotecas rotas que, con suerte, serán reparadas a tiempo, jajaja). Como un carajo, pruébalo al menos, chicos. No lo elimine por lo que está tratando de hacer; criticarlo por lo que realmente hace.

      Mi opinión caliente es que, honestamente, realmente me gusta. No pensé que haría eso porque realmente soy un gran tipo C, pero en realidad creo que es un lenguaje bastante agradable una vez que empiezas a hacer algo en él.

    • Rasmus Schultz dice:

      Compare este idioma con Skew, por favor:

      http://skew-lang.org/

      Tiene muchos de los mismos valores e ideales, pero Skew tiene una base de código estructurada y mucho más limpia, un conjunto completo de funciones de lenguaje avanzadas que funcionan, excelentes mensajes de error y compatibilidad con IDE.

      Sin embargo, este lenguaje casi nunca ha visto la luz. No creo que la mayoría de los desarrolladores presten atención a estos 5 minutos cuando se anunció por primera vez.

      ¿Cómo o por qué ese lenguaje rudo, incompleto y desordenado recibe tanta atención?

      Metu backend x64 en Skew para obtener tiempos de compilación rápidos, y ya tendría un lenguaje mucho más elegante y útil, con una base de código agradable y conservable.

    • Amurallar dice:

      Oh no otro, por favor ...

    • deshipu dice:

      Entonces no tenemos excepciones, en cambio nos hemos dado cuenta mal de un mecanismo idéntico a las excepciones por la declaración de retorno y mónadas. Sí, eso suena mucho mejor. Ah, y hemos agregado los "lanzamientos" tardíos de Java, disfrazados de un signo de interrogación, excepto que no mejora mientras aún es desagradable, porque todas nuestras excepciones son las mismas. Espléndido.

      • Artenz dice:

        Sin excepción, ¿cómo se trata esto?

        mut s: = "hola"

        por {
        s + = "mundo"
        }

    • Ren dice:

      ¿Y cuántos pensaron en la serie de televisión “V” cuando leyeron este blog?

      https://www.imdb.com/title/tt0086822/

      • rubypanther dice:

        ¡Cerca, el original!
        https://www.imdb.com/title/tt0085106/

        La primera razón por la que hice clic. Tantos idiomas intentan atraer a las masas, o atraer a la élite, estuve muy brevemente entusiasmado con un idioma que quiere alimentar a sus usuarios. Pero no.

    • dz2304194 dice:

      Muchísimas gracias

    • Daniyal Usmani dice:

      Escribe una publicación sobre el lenguaje de programación Dragon.
      https://www.dragon-lang.org

      • aurel dice:

        Sí, apesta, el dragón es un poco mejor ...

    • Brian Oh dice:

      Guau. No todos, pero qué montón de aldabas.

      Todavía se necesita un buen lenguaje multiplataforma de bajo nivel y alternativas a Rust y C ++ (sin GC). Aunque es una tarea enorme, deseo éxito a los desarrolladores de "V". Lo comprobaré.

Manuel Gómez
Manuel Gómez

Deja una respuesta

Tu dirección de correo electrónico no será publicada.