 |
Samedi 28 juin 2025 - 05:07 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Dans une vie antérieure, en tant que responsable du système d'exploitation de Commodore, Carl Sassenrath
a conçu et mis en oeuvre le noyau multitâche du système d'exploitation Amiga. Insatisfait des langages de
programmation existants qu'il qualifie de non intuitifs et inutilement complexes, il a utilisé son expérience
pour concevoir un nouveau dialecte de programmation. Le résultat est REBOL - un langage avec une cause.Notre invité aujourd'hui est Carl Sassenrath, fondateur et PDG de REBOL Technologies et innovateur de premier plan dans le domaine des technologies logicielles depuis plus de 15 ans. Il a travaillé notamment chez HP et Apple, et il est probablement plus connu comme le concepteur et l'implémenteur du noyau d'AmigaOS.
Lorsque l'Amiga original est sorti en 1985, il s'agissait du premier ordinateur personnel multimédia sur le marché, doté de fonctions multimédias à une époque où les PC IBM étaient limités à 16 couleurs. Il était doté d'une interface utilisateur graphique, d'un sous-système graphique rapide et d'une gestion des animations et du son.
Et tout cela était rendu possible par un système d'exploitation modulaire, multitâche et très efficace, avec des besoins en mémoire réduits. Un système d'exploitation doté d'un système de fichiers chargeables, de bibliothèques partagées et, plus important encore, ouvert et conçu pour être extensible. Carl, bienvenue dans le programme.
C'est génial
de vous avoir à l'antenne. De toute évidence, l'Amiga est le domaine où vous avez passé la plus grande partie
de votre vie jusqu'à ce que vous lanciez REBOL. Comment avez-vous été impliqué dans l'Amiga ?Eh bien, l'Amiga était une entreprise en phase de démarrage en 1983. A cette époque, j'étais chez Hewlett-Packard et j'avais travaillé sur un système d'affichage bitmap avec Hewlett-Packard pour implémenter une interface utilisateur graphique. Et c'était sur un prototype de la station de travail Sun que nous avons obtenu directement de l'Université de Stamford.
J'étais très impliqué dans les affichages bitmap et je pensais que leur avenir était prometteur. Et j'eus une proposition pour m'impliquer dans la société Amiga qui disait que si je venais y travailler, je pourrais écrire le système d'exploitation que je voulais.
Quels étaient
les produits proposés par Amiga à l'époque ?Eh bien, Amiga était une entreprise déguisée. C'était l'une de ces premières tentatives d'auto-commercialisation. Ils fabriquaient des contrôleurs de jeu pour l'Atari. Ce n'était qu'une façade pour l'ordinateur Amiga sur lequel ils travaillaient en coulisse. Jay Miner et Dave Morris ont fondé la société. Jay était l'employé numéro trois chez Atari, il avait donc une grande expérience des machines de jeux vidéo.
Donc ils vous
engagent et vous avez un chèque en blanc pour écrire un système d'exploitation. Aviez-vous de l'expérience
dans l'écriture de systèmes d'exploitation auparavant ? Quelle était votre expérience en programmation
logicielle à ce moment-là ?À ce moment-là, j'étais très impliqué dans les systèmes d'exploitation et les langages. Avant Amiga, j'avais travaillé sur le noyau MPE, le système d'exploitation des ordinateurs HP3000, chez Hewlett-Packard. C'est un système d'exploitation commercial très robuste et il est toujours utilisé aujourd'hui. Pendant que j'y étais, j'ai étudié pratiquement tous les systèmes d'exploitation qui existaient. J'étais en quelque sorte un fanatique des systèmes d'exploitation.
Donc, vous
étiez la personne idéale pour ce travail.Eh bien, j'en rêvais depuis tant d'années.
Quelles étaient
les contraintes de conception qui ont guidé vos décisions lorsque vous avez commencé à construire ce nouveau
système d'exploitation ?Eh bien, les contraintes étaient assez extrêmes car le premier objectif de l'Amiga était à l'origine d'être une machine de jeu vidéo. C'est pourquoi la société a été créée. A l'époque, la plupart des programmeurs de jeux vidéo allaient droit au but. Ce que je voulais faire, c'était mettre en place un système d'exploitation aussi efficace, tout en permettant le multitâche, par exemple.
L'exercice d'équilibriste consistait à essayer de créer un système d'exploitation qui serait utile aux programmeurs de jeux, mais qui serait également multitâche et disposerait de bibliothèques et de périphériques partagés dynamiquement, c'est-à-dire d'une architecture de système d'exploitation. Il serait suffisamment efficace pour que la plupart des jeux l'utilisent.
Je suppose
que le multitâche est essentiel pour une plate-forme qui gère des animations, des graphismes, des sons,
et tout ce qui se passe en même temps.C'est exact.
Comment avez-vous
procédé pour implémenter le multitâche dans le noyau d'AmigaOS ?Eh bien, à l'époque, la plupart des systèmes multitâches étaient assez volumineux. Ils étaient sur des machines IBM, DEC, etc. Ce que nous devions faire était de créer quelque chose de très efficace. J'ai donc créé ce qui était, je pense, l'un des tout premiers concepts de micro-noyau pour un noyau multitâche. C'est un noyau très léger, très sobre et très efficace pour faire le travail rapidement.
Les micro-noyaux
font maintenant fureur, mais à l'époque, c'était vraiment un nouveau concept.Oui, c'est vrai.
Quelles sont
les caractéristiques d'un micro-noyau par rapport à un noyau de système d'exploitation qui comprend tout,
sauf l'évier de cuisine ? :-)Eh bien, l'idée est que le noyau d'un système d'exploitation peut être spécifiquement orienté vers la fourniture d'un nombre relativement restreint de services sur lesquels vous pouvez construire des couches.
Ce que vous voulez faire au coeur d'un système d'exploitation, c'est partager des ressources : des ressources de mémoire ou des ressources de profit ou des ressources IR ? Ce que vous cherchez vraiment, c'est à organiser, gérer et partager ces ressources. Donc, plus le code pour cela est petit, mieux c'est en termes de micro-noyau. Et ensuite, vous construisez des couches autour de tous les autres éléments.
Vous aviez
des contraintes de mémoire que les grands systèmes n'avaient pas. Quelles étaient les conditions dans lesquelles
vous travailliez en ce qui concerne la mémoire ?L'Amiga était une machine intéressante car c'était une machine 32 bits. Elle avait 25 canaux DMA (Direct Memory Access) qui se faisaient tous simultanément. Il y avait un Blitter et un Copper qui fonctionnaient quasiment en parallèle avec le processeur.
Des morceaux de mémoire devaient être utilisés, par exemple pour le son ou pour les graphismes à l'écran, etc. Le système d'exploitation devait orchestrer tout cela.
Quel processeur
était utilisé dans la machine originale ?La machine d'origine avait un Motorola 68000.
Un processeur 32 bits ?Oui, c'était une machine 32 bits. Et nous avions une auto-configuration, essentiellement ce qu'on appelle aujourd'hui le "plug and play". Il n'y avait aucune configuration d'interruption nécessaire. Et les graphismes accélérés, comme je l'ai dit, étaient en bitmap 4096 couleurs.
C'était une
quantité énorme à l'époque.Oui, oh oui, à cette époque, il y avait quatre couleurs sur le PC.
Comment était le
sous-système vidéo ? Y avait-il une mémoire vidéo dédiée ?Non, la mémoire vidéo était organisée de telle sorte qu'elle sortait de la mémoire principale, un tampon divisé pour que la machine fonctionne en parallèle. Le processeur pouvait fonctionner dans une zone de la mémoire tandis que, par exemple, la vidéo fonctionnait dans une autre zone de la mémoire. Et tout cela était hautement multiplexé avec les canaux DMA qui étaient en cours.
Maintenant,
Carl, vous avez également mentionné, pour revenir au côté logiciel, les bibliothèques partagées, comment
cela fonctionnait ?Lorsque nous avons commencé à construire le système, d'autres personnes travaillaient sur la partie graphique, l'interface graphique et la bibliothèque audio.
La manière traditionnelle de faire cela à l'époque était de lier statiquement le tout dans une seule ROM. Et il est devenu clair pour moi que les projets étaient si différents et si désynchronisés qu'il n'y avait aucun moyen de se réunir et de faire simplement une ROM statique.
De plus, cela aurait ralenti l'ensemble du processus de développement. J'ai donc commencé à réfléchir à la façon dont nous pourrions utiliser un mécanisme permettant de séparer tous ces modules en morceaux qui pourraient être chargés dynamiquement. Et en fait, la ROM n'est même pas liée statiquement sur l'Amiga.
Quand la machine démarre, elle scrute toute la ROM, trouve toutes les différentes bibliothèques et modèles qui sont dans la ROM et les lie tous ensemble. Et ce même modèle se produit après, essentiellement à partir d'une disquette, vous savez qu'il scrute une disquette et recherche d'autres types de bibliothèques, etc. qui s'y trouvent.
Ces bibliothèques
en ROM étaient-elles écrites en C ou en assembleur ?Le micro-noyau est totalement écrit en code assembleur.
Comment ces
bibliothèques étaient-elles chargées dynamiquement ? A quoi ressemblait l'interface entre le noyau et ces
bibliothèques ?Chacune des bibliothèques disposait d'un ensemble de vecteurs standard qui étaient normalisés par le système d'exploitation. En outre, chaque bibliothèque pouvait avoir des vecteurs supplémentaires, des points d'entrée essentiellement, dans la bibliothèque. Et chaque bibliothèque pouvait aussi avoir sa zone de données privée, donc si elle avait besoin de garder une trace des informations.
Des informations
statiques ?Oui, des informations sur ce qu'elle a alloué, ce qu'elle fait tourner, elle peut le faire. Elle avait son propre segment de données pour cela aussi. Et le modèle de périphérique a en fait été construit au-dessus du modèle de bibliothèque et la seule différence entre le modèle de bibliothèque et le modèle de périphérique est que le modèle de périphérique était un modèle asynchrone. Il était basé sur les messages plutôt que sur la bibliothèque qui était plus un mécanisme d'appel de fonction C. Vous aviez besoin d'un modèle asynchrone.
Vous aviez
besoin d'un modèle asynchrone pour gérer la latence. Les pilotes fonctionnaient-ils en mode noyau ?Non, tout fonctionnait en mode utilisateur. Seule une très petite partie du noyau fonctionnait en fait en mode superviseur - l'ordonnanceur central répartissant les tâches. Le traitement des interruptions, par exemple, s'exécutait également en mode superviseur, comme on l'appelait à l'époque. Tout le reste fonctionnait en mode utilisateur, ce qui permettait d'utiliser d'autres ressources et non celles du noyau pour ce qu'elles faisaient.
Le code
source était-il disponible pour ces éléments internes ?Eh bien, pas à cette époque. En fait, je ne pense pas que le code source du noyau soit encore disponible à ce jour. Il était propriétaire.
J'ai vu des
messages d'utilisateurs qui recompilaient le noyau. Ces sources sont-elles des variantes du système
d'exploitation Amiga original ?Je pense que ce qui s'est passé, c'est que les gens l'ont réellement désassemblé, l'ont pris, l'ont démonté et l'ont décortiqué au cours des 13 ou 14 années qui ont suivi sa création.
Rétrospectivement,
quel a été le succès de cette architecture de bibliothèque partagée extensible ? A-t-elle fonctionné comme vous
l'aviez envisagé lors de sa conception ?C'était bien plus que ce que j'avais imaginé. Quand on conçoit quelque chose comme ça, quand on conçoit n'importe quoi, surtout quand on est à la pointe du progrès, on n'est pas tout à fait sûr et on a des doutes ici et là sur certains éléments de sa conception.
Et vous savez que seule l'histoire dira si c'était les bonnes décisions à prendre. Et, oui, l'histoire a prouvé que l'Amiga était une très bonne conception.
Quelles étaient
les autres caractéristiques majeures du système d'exploitation de l'Amiga ?L'une des choses qui me tenait à coeur était que le noyau était basé sur les messages. En d'autres termes, les pilotes de périphériques étaient des tâches distinctes auxquelles on envoyait des messages avec leurs exigences en matière d'entrée/sortie. Il y a généralement 20 ou 30 tâches indépendantes qui tournent juste après le démarrage d'un Amiga par exemple.
Même en 1985, les Amiga utilisaient des périphériques d'impression, des pilotes graphiques et sonores, et des entrées/sorties de disque, tous séparés. Faire circuler ces messages était très important.
Comment le
passage des messages a-t-il été implémenté ? Je pense que la première exigence était qu'il soit très rapide.La charge des messages était très, très faible, ce qui permettait à la machine de fonctionner efficacement. Sur la toute première machine, un 68000 à 7 MHz, le noyau traitait environ 10 000 messages par seconde.
Il existait une interface de messages standard et une structure standard pour communiquer avec les pilotes de périphériques.
Passons au
niveau supérieur. A quoi ressemblait l'interface utilisateur ? Si j'étais un programmeur Amiga, quelle API
utiliserais-je sur l'Amiga original ?L'Amiga original avait une interface graphique avec des menus déroulants. Il avait également des écrans multiples et c'est un concept que le reste du monde n'a pas encore vraiment vu. Vous pouviez utiliser plusieurs résolutions en même temps sur l'Amiga, et avoir des écrans déroulants avec différentes résolutions.
Si vous jouez à un jeu vidéo en plein écran, vous pouvez aussi avoir par-dessus votre éditeur de texte ou votre compilateur et vous pouvez basculer entre ces fenêtres de différentes résolutions assez facilement.
Quelle était
la résolution originale ?À l'origine, la résolution maximale était de 720x480 pixels. C'était nécessaire pour réaliser une sortie vidéo avec suraffichage sur les téléviseurs.
Évidemment,
l'une des caractéristiques les plus attrayantes de l'Amiga était son interface graphique. A quoi ressemblait-elle ?
Était-elle également un descendant de ce qui se passait chez Park Xerox et de ce qu'Apple utilisait également ?Oui, en grande partie. Nous avons étudié le travail de Xerox. Nous avons également étudié à cette époque le Lisa. Le Macintosh n'avait pas encore été abandonné. Nous avions des avis différents sur diverses choses. Nous devions également nous occuper de la couleur et la plupart de ces systèmes n'en avaient pas. C'était donc une nouvelle considération.
Nous avons également choisi d'utiliser une souris à deux boutons, ce qui est aujourd'hui la norme pour les PC, du moins. Et cela était basé sur la possibilité de pointer quelque chose à l'écran et de faire apparaître des menus à l'écran.
Je suis sûr
qu'il y a eu de nombreuses réunions de conception qui ont conduit à cette décision ?Oui.
C'est l'une
des guerres saintes de l'informatique personnelle, la souris à un bouton contre la souris à deux boutons ?Nous étions très doués pour discuter de ces questions et les résoudre. Et nous sommes arrivés à de très bonnes décisions consensuelles sur des choses comme la souris à deux boutons.
Est-ce la
raison pour laquelle l'Amiga a connu un tel succès - du moins sur le plan technique au début - grâce à cette
synergie entre des personnes travaillant dans un petit groupe ?Oui, je pense que cela y est pour beaucoup. C'était une toute petite équipe de personnes qui s'asseyaient toutes dans la même pièce et communiquaient constamment entre elles sur la conception de la machine. Il y avait aussi l'esprit de ce que nous faisions. C'est juste un grand sentiment de savoir que vous faites un nouvel ordinateur et nous avions de grands rêves.
Revenons au
développement de logiciels. Comment était-ce d'écrire des logiciels pour l'Amiga à ses débuts ? Existait-il des
outils de développement pour les programmeurs ? Devaient-ils écrire directement avec un compilateur C sur l'API ?
Quels compilateurs étaient disponibles ?Avec toute nouvelle machine, il y a cette étape de démarrage avec les outils de développement. Amiga a initialement acheté le compilateur C de Green Hill et l'a porté sur l'Amiga.
Quels outils
avez-vous utilisés pour votre propre développement ?J'ai développé le noyau sur une station de travail émulateur Hewlett-Packard qui me permettait de tester le code avant même que le processeur et le matériel ne soient prêts.
Tout cela était fait en code assembleur. Nous avons également utilisé des ordinateurs Sage à base de 68000 qui étaient disponibles à l'époque. Nous avons utilisé les compilateurs Sage pendant un certain temps, puis nous avons porté le compilateur Green Hills.
Et à un moment donné, Lattice a fait un compilateur C pour le PC, ils ont été impliqués et ils ont fait un compilateur C Lattice pour l'Amiga. Puis, après cela, Manx s'est également impliqué et a produit un compilateur C encore meilleur. Un effet de saute-mouton a commencé avec la concurrence sur le marché pour faire un meilleur compilateur C pour l'Amiga.
Et rapidement,
l'Amiga gérait un certain nombre de langages différents.Oui, oh oui. L'ensemble traditionnel à peu près.
Je veux m'éloigner
de l'Amiga. Mais avant de quitter le sujet, je dois vous interroger sur ce qui se passe actuellement avec
l'Amiga. L'année dernière, Gateway, je crois, a acheté la technologie Amiga. Que se passe-t-il dans la communauté
Amiga en ce moment ?Gateway a créé une division de la société qui était indépendante de Gateway afin de poursuivre la vision de l'Amiga pour ce type de produit - un ordinateur multimédia de haute performance, mais toujours disponible à des prix de niveau grand public. La popularité de l'Amiga était si forte qu'elle les a vraiment poussés dans cette direction.
Ils étaient principalement intéressés par la technologie propriétaire lorsqu'ils ont acheté l'Amiga. Le portefeuille de brevets de l'Amiga est assez large puisqu'il a fait beaucoup de ces choses en premier. Mais après avoir reçu quelques centaines de milliers de courriels de passionnés du monde entier qui ont commencé à croire fermement en l'Amiga, ils ont commencé à penser qu'il y avait peut-être un bon marché pour tous ces penseurs indépendants.
Ils ont
acheté plus qu'un simple ensemble de brevets. Ils ont acquis un mouvement. Il y a un effort de développement
en cours au moment où nous parlons pour sortir un nouveau système d'exploitation pour Amiga.Oui. Il y a un effort de développement en cours en ce moment même. C'est chaud et furieux, ça avance et c'est plein d'énergie. Et ils ont de grandes idées. Je n'y participe pas quotidiennement. Je leur ai parlé à quelques reprises et les ai conseillés sur certaines décisions. Mais je pense qu'ils prennent de très bonnes décisions, en suivant les traces de la vision ou du rêve d'Amiga sur ce que peut être un ordinateur.
Que pensez-vous
de Be ? La vision de Be est en grande partie la vision originale d'Amiga pour un ordinateur personnel véritablement
multimédia, à haute performance et sans compromis. Nous avons discuté à plusieurs reprises avec les ingénieurs
de Be à Menlo Park et ils sont enthousiastes à propos de l'Amiga. Ils le considèrent comme un précurseur de ce
qu'ils font actuellement. Savez-vous quelque chose de leur technologie ?Oh oui, oui. Je suis allé les voir, j'ai parlé à Jean-Louis Gassée, j'ai vu ce qu'ils faisaient et j'aime ce qu'ils font. Ils ont beaucoup de très bonnes idées. Beaucoup de leurs idées sont très similaires à celles de l'Amiga. C'est en quelque sorte la prochaine génération en termes de performances et de structure.
Suivez-vous de
très près les systèmes d'exploitation ? Le mouvement derrière Linux prend de l'ampleur. Que pensez-vous des
systèmes d'exploitation Unix, par exemple ?J'ai étudié Unix pendant de très nombreuses années, en remontant jusqu'à l'époque de Hewlett-Packard, avant Amiga. J'ai étudié les Unix qui étaient disponibles à l'époque. À l'époque, il s'agissait plutôt de projets de recherche, de produits universitaires et de produits de base. Au fil des ans, ils ont évolué et sont devenus bien plus que cela.
Linux est un système d'exploitation très intéressant à observer parce qu'il a cet élan d'ouverture de code source derrière lui. Bien sûr, il a une saveur très Unix, mais il a aussi la capacité d'évoluer très rapidement. Et il semble être incroyablement efficace. Et vous savez que c'est un vrai plaisir de travailler avec ?
Pensez-vous
que ses performances sont meilleures que celles d'autres saveurs d'Unix ?D'après ce que j'ai vu, oui. Nous avons un certain nombre d'ordinateurs ici parce que nous portons REBOL sur de nombreuses plates-formes. Je pense que Linux est notre meilleure performance. Je ne me suis pas assis et je n'ai pas fait de mesure précise, mais d'après ce que j'ai vu, il est très performant.
Bien que
cela puisse être difficile à croire en raison de la taille du logiciel, Windows NT est construit sur un
micro-noyau. Certaines personnes diraient qu'il y a "trop de couches", mais c'est un système d'exploitation
en couches.Oui, c'est un système d'exploitation en couches et je pense que son noyau est probablement assez bon. Je n'ai jamais vu le code source du noyau mais l'API semble être assez raisonnable par rapport à d'autres produits de la même société. Je pense donc que sa base est assez solide.
Mais comme vous l'avez dit, par-dessus cela, il y a des couches et des couches et des couches d'autres API et d'autres abstractions, dont beaucoup ont des objectifs et des visions différents. La complexité globale de Windows NT est assez élevée. Il existe au moins dix mille, probablement plus de vingt mille interfaces API pour ce système d'exploitation. Une personne ou une petite équipe de programmeurs a du mal à gérer ce genre de complexité.
Et cela va
probablement empirer avec Windows NT 5 qui est significativement plus grand que Windows NT 4.0. Vous avez
mentionné la complexité. La complexité est l'un de vos sujets favoris, et cela nous amène à REBOL.
L'un des objectifs de REBOL est de rendre la programmation plus facile et de cacher certaines de ses complexités.
Est-ce exact ?Oui, c'est exact. Nous recherchons la productivité ici. Je suis impliqué dans les langages informatiques depuis 20 ans et j'ai principalement inventé REBOL. Je n'ai jamais trouvé un langage dans lequel je me sentais pleinement productif, un langage qui semblait vraiment bien adapté pour faire le travail.
Vous savez,
il semble que la complexité de l'apprentissage d'un langage et de son utilisation interfère avec le
développement de solutions. Les programmeurs passent la plupart de leur temps à se battre avec le langage
plutôt que de se battre avec le domaine du problème.C'est pourquoi l'un des principes fondamentaux de REBOL est de s'éloigner du langage et d'être à un pas du langage informatique réel, pour parler en termes ou écrire votre solution en termes de domaine de problème.
Comment REBOL
réalise-t-il cela ?Nous appelons cela la dialectique. Il s'avère que ce n'est pas un concept entièrement nouveau. Forth l'utilise, bien que REBOL ne ressemble en rien à Forth en termes d'implémentation et de fonctionnement. L'un des concepts de Forth qui était très bon était que si vous vouliez contrôler un télescope, vous deviez le faire en termes d'astronomie, en termes d'étoiles et de leurs emplacements, d'azimuts, etc. Vous écriviez un sous-langage dans Forth pour contrôler les télescopes.
Ou si vous voulez contrôler un moteur de voiture, vous parlez de bougies, de cylindres et de boîtes de vitesses et vous voulez écrire votre solution en fonction de ces éléments.
Ce n'est pas vraiment différent de l'anglais. Si vous êtes avocat, vous parlez en termes juridiques. Si vous êtes médecin, vous parlez en termes médicaux. Vous avez votre propre vocabulaire et même votre propre grammaire, la façon dont vous réarrangez les mots pour les rendre plus spécifiques à ce domaine. Et c'est l'une des façons dont les humains ont évolué pour faire face à la complexité.
Si les humains avaient les mêmes problèmes de communication par le langage que les ordinateurs, notre société s'arrêterait net. Mais nous sommes capables de les contourner et d'adapter notre langage au domaine du problème. Cette adaptabilité est l'essence même de REBOL.
Comment les
utilisateurs de REBOL peuvent-ils construire des vocabulaires ou des grammaires spécifiques à leur
domaine ? Doivent-ils enseigner le langage ?Oui. Il y a une grammaire prédéfinie dans REBOL, un langage fonctionnel lui-même qui est à la base de tout. Et dans ce langage fonctionnel, il y a la capacité de gérer ce dialecte. Nous sommes encore en train de travailler sur beaucoup de ces idées.
Dans de nombreux cas, vous pouvez construire une grammaire très simple sans même savoir que vous le faites. En d'autres termes, des combinaisons de mots et de valeurs, de nombres, de chaînes de caractères, ce genre de choses. Et vous pouvez construire une manière ad hoc d'interpréter ces éléments.
Mais nous travaillons également sur un moyen de formaliser ce processus, de manière que vous puissiez spécifier les types de choix et la grammaire, d'une manière similaire aux expressions régulières ou à la notation de la grammaire B & F. Cela rendra les choses beaucoup plus faciles pour les utilisateurs. Il sera ainsi beaucoup plus facile pour les gens de développer leur propre grammaire.
Je ne pense pas que tout le monde développera sa propre grammaire. Les spécialistes de la médecine, par exemple, développeront une grammaire qui sera très utile à certains types de médecins dans la recherche et ils la fourniront comme une sorte de couche à tous ces médecins. Ainsi, ces médecins n'écriront pas directement en REBOL, ils écriront dans ce dialecte de REBOL qui leur est destiné.
Je voudrais
lire une citation de vous que j'ai trouvée sur Internet. Elle fait le lien entre la discussion que nous
avons eue sur les systèmes d'exploitation et votre projet actuel, REBOL : "Une fois que le langage sera
complètement distribué, la deuxième phase consistera à développer un système d'exploitation petit et
flexible qui sera intégré de manière unique au langage". Avez-vous toujours l'intention d'aller de l'avant
et d'intégrer REBOL dans un système d'exploitation ?Eh bien, c'est une chose à long terme. Je pense que de nos jours, on ne se lance pas dans l'écriture d'un nouveau système d'exploitation. Ce que vous faites, c'est de rendre les choses plus productives, ou de les rendre plus simples.
Ou bien vous vous basez sur ces idées de messagerie distribuée ou de communication interne, une des choses que fait REBOL. Et vous obtenez cette capacité là-dedans. Vous avez tout compris. Et ce qui finit par arriver, c'est que vous vous retrouvez avec toutes sortes de nouvelles applications, des choses qui existent aujourd'hui mais aussi des choses que les gens n'ont pas encore imaginées.
Et vous construisez d'abord ça, toute cette base d'applications. Et puis les systèmes d'exploitation qui fonctionnent en dessous deviennent insignifiants par rapport au système d'exploitation que vous utilisez. À ce moment-là, lorsque vous n'avez plus besoin d'un système d'exploitation particulier, vous pouvez le retirer du tableau. Et vous savez que cela peut arriver.
Les applications REBOL ne sont pas liées au système d'exploitation. Toutes les applications REBOL sont envoyées au-dessus de REBOL. Elles sont isolées de tous les éléments internes du système d'exploitation et nous rendons REBOL indépendant de la machine.
REBOL serait
à la fois le langage et la plate-forme.Eh bien, je ne veux pas vraiment faire cette déclaration maintenant. Vous savez que les gens penseraient que vous êtes fou si vous disiez que vous allez sortir et écrire un autre système d'exploitation.
Ou une
abstraction d'un système d'exploitation.Oui. Et je ne veux pas que les gens pensent à REBOL de cette façon. Je veux que les gens pensent à REBOL en termes de messagerie, de dialectique et d'intercommunication, bref des moyens plus faciles de créer des logiciels.
L'indépendance
vis-à-vis de la plate-forme, le langage et la plate-forme, ces questions sont centrales pour Java.
Que pensez-vous de Java ?Eh bien, c'est une question assez large. Je pense que Java a bénéficié de quelques très bonnes idées. J'ai rencontré son concepteur il y a quelques années et j'ai observé son travail. J'ai toujours aimé le travail de James Gosling.
Mais le problème de Java, c'est que je ne pense pas que ce soit suffisant. A bien des égards, c'est très traditionnel. Bien sûr, il est indépendant du grand empire du logiciel. C'est aussi un pas dans la bonne direction en termes de style orienté objet et il élimine certains des dangers que C et C++ ont apportés.
Êtes-vous
un adepte de l'orientation objet ?J'ai commencé à m'intéresser à la technologie orientée objet en 1982. Hewlett-Packard était l'un des premiers sites de test alpha pour le langage Smalltalk de Xerox. Et j'ai tout simplement dévoré ce truc. J'ai été très profondément impliqué dans la technologie orientée objet. Pendant de nombreuses années, j'ai suivi la technologie orientée objet.
J'ai été impliqué dans l'implémentation de divers langages orientés objet. Vous savez, j'avais l'habitude d'aller à toutes les conférences sur la programmation orientée objet, etc. Je pense que les objets sont un outil de plus à ajouter à votre trousse à outils pour résoudre les problèmes. Mais à bien des égards, ils ne sont pas la panacée. Le monde n'est pas aussi orienté objet que chacun voudrait le croire. Par exemple, je ne dis pas à la table sur laquelle je suis assis de se déplacer sur le sol. Il faut une personne pour la soulever et la transporter sur le sol.
Ces types de relations et d'interactions ne sont pas toujours bien exprimés dans la programmation orientée objet. Et ce qui finit par arriver, c'est que les choses commencent à devenir fragiles au bout d'un moment, ça commence à craquer. Ce qui finit par arriver, c'est que les gens commencent à réutiliser le code, non pas en pilotant leurs objets, mais en copiant le code source sur les objets et en ajoutant ensuite ce qu'ils veulent à ce code source. Donc les piloter n'est pas la façon dont le modèle objet est configuré.
Eh bien, un
problème avec C++ est que le modèle objet n'est pas dynamiquement extensible. Il n'y a pas de liaison entre
les objets au moment de l'exécution.C'est exact. On l'a vu très tôt aussi. Quand C++ est sorti, j'étais chez Apple Advanced Technology. Et il y avait beaucoup de gars de Xerox qui étaient encore chez Apple Advanced Technology à cette époque. Et nous avions l'habitude de plaisanter en disant que c'était C+- parce que ces gens de Smalltalk regardaient la chose sans la dynamique. Sans objets dynamiques, vous ne pouvez pas faire ce que vous devez faire avec des objets.
Et c'est ce qu'était le C++. Et ils ont essayé de nombreux trucs pour essayer de contourner ça. Mais toutes ces astuces ont été une corruption du langage et de la conception du langage.
C'est peut-être
la raison pour laquelle les modèles de composants-objets ont du succès en ce moment. Ils apportent une solution
à ce problème.C'est vrai.
Vous avez
mentionné Apple. Quelle a été votre implication avec Apple ?Apple m'a associé à un projet de processeur parallèle qui était très secret à l'époque. Ce n'est pas très connu mais ils développaient un processeur parallèle qui tournait très, très vite, à peu près à la vitesse d'un Cray. Et ils avaient besoin d'un système d'exploitation orienté objet pour le faire fonctionner. Et donc ils m'ont engagé pour construire ce système d'exploitation orienté objet.
Il semble
qu'il y avait beaucoup de projets de système d'exploitation en cours chez Apple à la fin des années 1980 ?Oui, c'était dans les années 1986, 1987, 1988.
Est-ce le
projet qui a évolué vers l'accord avec Taligent ?Oui. La première partie de cette conception a évolué vers Taligent et ce qui se passait là-bas. Mais c'était très en amont, c'était avant cela.
À ce jour,
il n'existe pas de nouveau système d'exploitation Apple, bien qu'Apple ait très tôt identifié le besoin
d'un système d'exploitation moderne et performant pour prendre en charge le type d'applications qu'elle
souhaitait exécuter.Oui, et c'est ironique. C'est en fait très frustrant parce que je suis un grand fan d'Apple et je pense que le Macintosh est aussi une machine très bien faite.
Et vous savez, mon sentiment - et c'est probablement un blasphème - est qu'ils auraient dû porter tout leur système d'exploitation sur l'architecture Intel et le laisser entrer en concurrence directe avec Microsoft. Le monde serait meilleur aujourd'hui.
Que pensez-vous
de l'évolution de la technologie et du développement des logiciels depuis cette période ? Quels sont les
commentaires que vous vous faites à vous-même ?Je pense que nous en sommes encore aux premiers jours. Avant les ordinateurs, je m'intéressais à la neurologie. Le cerveau est très lent. La propagation des signaux à travers les neurones est incroyablement lente.
Mais vous regardez tout ce que le cerveau fait et vous devez vous demander, "Pourquoi est-ce tellement plus adaptatif ?" D'où vient cette puissance ? Eh bien, elle vient du parallélisme. Et nous n'avons même pas encore commencé à exploiter la puissance du parallélisme dans les ordinateurs.
L'un des
problèmes est la complexité des algorithmes impliqués.Mais il n'y a pas que cela. Il s'avère qu'il y a des questions de largeur de bande. Le cerveau est directement connecté. Les neurones font synapse à d'autres neurones dans une connexion directe. La plupart des ordinateurs utilisent des bus, où toutes les données doivent être transférées via un tampon qui devient un goulot d'étranglement pour l'ensemble du processus.
Pensez-vous
que les neurosciences puissent fournir un modèle à l'informatique, pour le développement de systèmes informatiques ?Oui, je le pense. À l'époque de l'intelligence artificielle, une grande partie de cette réflexion était appliquée à la conception des ordinateurs et de l'intelligence artificielle. Nous y reviendrons toutes les quelques années. Je ne peux pas prévoir quand nous serons réellement en mesure de concevoir ce type d'ordinateur neuronal. Mais je pense que cela arrivera probablement.
|
