OnlyOffice: l'alternativa open source e on premise a Microsoft 365

C'entra perché se scrivi questo:
[INDENT]"sembra che ritieni che gli stessi problemi non si avrebbero con altri linguaggi "più produttivi"[/INDENT]
ti ho fatto un esempio in merito.

Ovviamente te le chiederei: non siamo mica al bar dello sport.

No, sarebbe sufficiente utilizzare la lingua italiana in maniera appropriata. Tutto qui.

Gli assembler esistono da una vita e tutt'oggi non se ne può fare a meno. Dovresti sapere che i compilatori C/C++ e di diversi altri linguaggi ad alto livello generano sorgenti assembly, che vengono poi compilati dall'assembler per generare i file oggetto, e infine al linker per ottenere l'eseguibile finale. Dunque è ovvio che ci sia un assemblatore in questi strumenti di sviluppo, perché altrimenti non potresti farci niente (a parte sviluppare interamente in assembly, che lascia il tempo che trova).

D'altra parte il contesto avrebbe dovuto essere chiaro. Ecco qui quello che avevi scritto:
[INDENT]"Il fatto che gli engine di Office sono scritti in assembly è riportato in molti articoli"[/INDENT]
Se l' "engine" fosse scritto in assembly, vuol dire che il resto NON lo sarebbe, logica elementare alla mano. Dunque l'avranno scritto in un ALTRO linguaggio di programmazione, e siccome a parte Visual Basic Microsoft supporta da tantissimi anni C e C++ e mette a disposizione anche librerie/framework allo scopo, mi pare scontato che la scelta sia stata questa.

Ora, il punto è che se passi a C/C++, e specialmente se poi utilizzi classi et similia (che col tipo di applicazioni che sono quelle Office mi pare una naturalissima scelta. E questo senza nemmeno tirare in ballo i design pattern), continuare a usare l'assembly 8086 (perché è questo che è stato usato inizialmente con le prime applicazioni del pacchetto Office) non sarebbe stato possibile, visto che già all'inizio degli anni '90 aveva preso piede l'80386 come ISA di riferimento (8086 era già destinata all'oblio, pur con tutta la base software esistente), lanciata dai famosi DOS-extender e dall'arrivo di Windows 3.0.

Dunque quando Microsoft avrà deciso di riscrivere Office in C++ non poteva più utilizzare il codice originale 8086, e se avesse voluto continuare a mantenere l'engine o, in generale, una parte del codice in assembly, avrebbe dovuto riscriverlo da capo per 80386. E la maniera migliore (ossia comoda, veloce, produttiva, ossia più facile da integrare e testare) di farlo è usare l'assembly inline, per l'appunto, i cui vantaggi sono innegabili rispetto all'avere blocchi di codice isolati in file assembly esterni.

Quindi se questa è la strada scelta, e di cui ho ben pochi di dubbi da sviluppatore, si giustifica la frase che ho poi scritto in risposta alla tua:
[I][INDENT]"Dubito fortemente che abbiano mantenuto il core in assembly, se non eventualmente per piccole sezioni critiche per IA-32/x86, per le seguenti motivazioni:
- l'assembly 8086 (di moda dagli anni '80 fino a circa la metà degli anni '90) è diverso da quello di 80386, e quindi avrebbero dovuto riscrivere tutto;
- Visual Studio (col quale è compilato Office) NON supporta l'assembly x64 e ARM: "Inline assembly is not supported on the ARM and x64 processors", ma Office è già disponibile da tempo per queste architetture."[/INDENT][/I]
che parla per l'appunto di "inline assembly".

Come già detto sopra, è a dire poco OVVIO che questi strumenti includano un assemblatore.

Non è questione di rinunciare a qualcosa: da sviluppatore valuto i pro e contro di ogni strumento, ed eventualmente lo uso (in toto o in parte) a seconda del problema che ho da risolvere. Cosa scontata per un professionista, e non credo sia necessario chiedere se si sia d'accordo oppure no.

E da professionista la mia valutazione sull'opportunità di usare codice assembly te l'ho illustra sopra: quelle sono le scelte che avrei fatto, e ho pochi dubbi che gli sviluppatori di Microsoft abbiano fatto diversamente quando hanno riscritto Office in C++, EVENTUALMENTE mantenendo porzioni in assembly.

Per il resto, sì: fino a circa metà anni '90 scrivevo codice quasi interamente in assembly.
Quando ho dovuto lavorare col PC per la scuola (ITIS) all'epoca si usava il Turbo Pascal 3.0, e l'UNICO supporto all'inline era... quello in linguaggio macchina. Dunque i miei sorgenti erano pieni di inline in esadecimale che derivavano da parti assembly (8086) compilate e di cui avevo poi fatto il dump per inserirlo, appunto, come inline in mezzo al codice Pascal. Alcuni moduli li ho mantenuti in assembly, da linkare all'occorrenza. Ma la via prediletta era l'inline, anche se limitato al solo linguaggio macchina, perché rispetto a un assemblato esterno da linkare mi forniva una notevole flessibilità (ossia poter passare parametri in mezzo ai byte, nonché inserire espressioni che venivano calcolate dal compilatore).
Con l'arrivo dell'inline assembly, col TP 4.0 se non erro, ho progressivamente abbandonato i moduli assembly esterni, e scritto il mio codice assembly direttamente in mezzo a quello Pascal, grazie agli innegabili vantaggi.

Dovresti controllare meglio: ci sono critiche contro e a favore.

Ma in ogni caso il formato è aperto e documentato, contrariamente a ciò che avevi falsamente affermato.

Altra cosa di non poco conto, è la storia di questo formato: è stata l'UE a chiedere Microsoft di standardizzare il formato XML dei file prodotti da Office, e non il contrario. Inoltre è un processo che non avvenuto in poco tempo, ma ha richiesto due anni di lavoro.

Così si smonta un altro falso mito che circola da tempo.

Per me puoi fare quello che vuoi.

Premetto che non ho provato OnlyOffice, ma resto dell'idea che la miglior soluzione siano i servizi di Google (Google Documents, Google Sheets...): 100% online, zero spazio su disco, accessibile ovunque ci sia una connessione internet. Nel complesso puoi fare tutto, io lo uso per scopo sia privato sia lavorativo dal mio account Google, penso che questa sia la soluzione migliore in assoluto!