• [^] # Re: V is for vapoware ?

    Posté par (site web personnel) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 5.

    Pour Julia, il me semble qu'il n'y a pas d'interpréteur?

    Non, pas besoin : tout est compilé à la volée (avec optimisations et tout). Ils ont des projets pour déployer un vrai interpréteur, mais ça ne semble pas si important.

    -leur système de typage ne permet pas de différencier les 2 types de tableaux

    Aucun problème : les tableaux standard sont des Vector, OffsetArray permet de changer les indices (pas juste commencer à zéro). Ce dont tu parles, c'est d'incompétents qui utilisent une interface trop générique pour leurs capacités de codage (AbstractVector n'indique jamais qu'un tableau commence avec l'indice 1, mais les types doivent implémenter axes s'ils ne respectent pas ce point). Ce n'est pas un problème de langage, mais d'utilisateurs... Et Julia est loin d'être le seul langage avec un problème de gens qui ne respectent pas les interfaces qu'ils implémentent ou utilisent.

    Ils auraient pas pu utiliser des tableaux avec des index de début arbitraire (à la Ada) dès le début plutôt que de reléguer ça à une librairie???

    C'est comme ça que le langage a été conçu : pas trop de choses dans la bibliothèque standard ou les types primitifs, mais laisser un maximum de liberté aux utilisateurs. Notamment, pourquoi imposer une seule manière d'implémenter cette fonctionnalité ? De ce que j'ai vu, Ada ne permet pas de surcharger l'opérateur d'indexation sur un tableau : comment implémenter quelque chose comme https://github.com/JuliaArrays/FFTViews.jl ? Je n'ai pas vu de bibliothèque proposant un type DataFrame (comme en R, Python, Julia, etc.) en Ada, alors que ces API utilisent énormément l'opérateur d'indexation.