Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > Articoli

Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
A distanza di circa 8 mesi arriva l’importante aggiornamento dei MacBook Air: nessun cambiamento estetico, ma una revisione hardware interna con l’upgrade al processore M3. Le prestazioni migliorano rispetto alle generazioni precedenti, e questo fa sorgere una domanda spontanea: a chi è rivolto oggi questo laptop? Cerchiamo di capirlo nella nostra recensione 
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 10-03-2021, 12:12   #61
biffuz
Senior Member
 
L'Avatar di biffuz
 
Iscritto dal: Jul 2001
Messaggi: 3462
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Togli pure il forse. Comunque con questi linguaggi di programmazione (soprattutto C++, ovviamente) la produttività scende, e i bug sono dietro l'angolo (sempre C++ in primis). Con Java s'impenna l'impiego di risorse del sistema. Insomma, scelta peggiore non potevano fare...
--
In un'applicazione del genere non servono le prestazioni in primis, ma le funzionalità (e la comodità). Le sezioni critiche si possono sempre ottimizzare a parte.
--
E non servono le "basi di algoritmi e linguaggi di programmazione" per capirlo: si tratta di ingegneria del software e di esperienza.
Scusa ma non ti capisco più, parli di produttività vs prestazioni ma ti lamenti del consumo di risorse e finisci col dire che qualcosa che consuma ancora più risorse alla fine va bene, parli di prestazioni dei linguaggi senza aver la benché minima idea di come misurarle, affermi che servono ingegneria del software ed esperienza servono ma le basi di algoritmi no, anche se dovrebbero essere la prima cosa che si impara dopo hello world...

Quote:
Molto probabilmente erano in assembly già negli anni '80, quando Word ed Excel sono nati (non ricordo quando arrivò PowerPoint), ma erano altri tempi ed era comprensibile (viste le poche risorse dell'epoca).

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;
Ricordo la presentazione di Office 95 dove si vantavano che gli engine erano stati completamenti riscritti in assembly 32 bit. E Office c'era anche per Mac 68k e PPC.

Quote:
- 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.
Congratulazioni, hai appena linkato il manuale ufficiale Microsoft che spiega come sviluppare in assembly (x86, x64 e ARM) in Visual Studio 2019 e usarlo in progetti C/C++, e poi hai detto che non si può fare.
Vediamo se trovi da solo il problema...

Quote:
I problemi delle ALTRE applicazioni coi formati Office, per la precisione.

Perché... lo sono? Il vecchio formato di Office '97 è ben descritto da anni e le specifiche le trovi nel sito di Microsoft (o su web archive, visto che è roba del paleozoico informatico), e OpenXML è addirittura uno standard ISO.
Abbiamo già discusso abbondantemente di questo, insistere non ti darà ragione.

Quote:
Perché non t'informi prima di riportare informazioni false?
Io? Ok...
__________________
www.biffuz.it | Thou shall not follow the NULL pointer, for chaos and madness await thee at its end.
Powered by: M1 @ Sonoma | 3770k @ W10 | C2Q @ XP | P!!! @ W98+BeOS | 286 @ W3.1 | C64 | iP8+ | iPad8 | rPi4 | and more...
biffuz è offline   Rispondi citando il messaggio o parte di esso
Old 10-03-2021, 14:34   #62
biffuz
Senior Member
 
L'Avatar di biffuz
 
Iscritto dal: Jul 2001
Messaggi: 3462
Quote:
Originariamente inviato da cavaliereombra Guarda i messaggi
A parte un braccio di ferro e utilizzo di termini generici, non vedo altro; nessuna argomentazione ben illustrata. Volete entrare nel tecnico? Tecnico serio, intendo. Non frasette da forum qualunque.

A citare nomi sparsi di esami del primo anno di Informatica non ci vuole niente. E qui siamo tutti informatici programmatori esperti, giusto?
Ma questo è un forum qualunque.

Chiedo scusa ma non ho né tempo né voglia di scrivere saggi dettagliati per ogni post su ogni forum.

Se lo fai, il 99% delle persone non lo legge e il restante 1% si mette a dibattere sulle virgole (senza fonte). O comincia a chiedere la dimostrazione che 1 più 1 fa 2.

Se qualcuno ci tiene, può cercarsi tutte le fonti che vuole su Google, Wikipedia, Stack overflow (lo usano tutti - senza fonte - e non dite che non è vero), documentazione ufficiale, libri scolastici e via dicendo.
__________________
www.biffuz.it | Thou shall not follow the NULL pointer, for chaos and madness await thee at its end.
Powered by: M1 @ Sonoma | 3770k @ W10 | C2Q @ XP | P!!! @ W98+BeOS | 286 @ W3.1 | C64 | iP8+ | iPad8 | rPi4 | and more...

Ultima modifica di biffuz : 10-03-2021 alle 14:37.
biffuz è offline   Rispondi citando il messaggio o parte di esso
Old 10-03-2021, 14:57   #63
andy45
Senior Member
 
Iscritto dal: Mar 2008
Messaggi: 12259
Quote:
Originariamente inviato da cavaliereombra Guarda i messaggi
A parte un braccio di ferro e utilizzo di termini generici, non vedo altro; nessuna argomentazione ben illustrata. Volete entrare nel tecnico? Tecnico serio, intendo. Non frasette da forum qualunque.

A citare nomi sparsi di esami del primo anno di Informatica non ci vuole niente. E qui siamo tutti informatici programmatori esperti, giusto?
A me sembra la solita lotta tra i programmi open e quelli microsoft, lotta senza ne vincitori ne vinti, office continuerà a essere il programma di riferimento per l'ambito lavorativo, libreoffice continuerà a non essere un buon sostituto perché non compatibile al 100% con i formati microsoft, quindi di fatto se devi collaborare con delle persone che usano office lascia stare, comunque non è un forum tecnico, non siamo tutti programmatori, io sono un analista numerico figurati, le interfacce grafiche per noi andrebbero abolite, consumano risorse inutilmente...e comunque per l'uso che ne faccio io fanno pena entrambi, latex tutta la vita .
__________________
Desktop: Phenom II x6 1055T, AsRock 890FX Deluxe 4, 4x4 Gb 1600 Mhz, NVidia GeForce GTX 960 2 Gb GDDR5, SB X-FI Fatal1ty Pro, 1 Tb ssd + 500 + 320 Gb 7200 Rpm, Windows 10 Home 64 Bit Notebook: Asus X551CA-SX024D Xubuntu 20.04 LTS 64 Bit Tablet: Asus Nexus 7 32 Gb Wifi Smartphone: Redmi Note 9 Pro 6/128
andy45 è offline   Rispondi citando il messaggio o parte di esso
Old 10-03-2021, 15:25   #64
biffuz
Senior Member
 
L'Avatar di biffuz
 
Iscritto dal: Jul 2001
Messaggi: 3462
Mi correggo da solo, Office nell'ultimo decennio è stato sviluppato in C++. E stavolta mi sento buono e vi metto pure una fonte.
https://channel9.msdn.com/Shows/Goin...-C-Renaissance
Il porting su mobile e persino sul web sono basati su questo (webassembly). Le fonti ve le lascio da trovare come compito per casa.
__________________
www.biffuz.it | Thou shall not follow the NULL pointer, for chaos and madness await thee at its end.
Powered by: M1 @ Sonoma | 3770k @ W10 | C2Q @ XP | P!!! @ W98+BeOS | 286 @ W3.1 | C64 | iP8+ | iPad8 | rPi4 | and more...
biffuz è offline   Rispondi citando il messaggio o parte di esso
Old 10-03-2021, 21:31   #65
andy45
Senior Member
 
Iscritto dal: Mar 2008
Messaggi: 12259
Quote:
Originariamente inviato da cavaliereombra Guarda i messaggi
Assolutamente d’accordo con te. Tranne su latex. L’ho odiato troppo ai tempi dell’università e da allora (2004) non lo tocco più.
Quando buona parte di quello che scrivi sono formule o simboli matematici è l'unica opzione, l'equation editor di word è una follia, va bene per piccole cose, ma niente di più, libreoffice/openoffice molto meglio visto che ci si può affidare al codice, ma i risultati finali dal punto di vista "visivo" non sono gran che, insomma va bene per uso personale, ma niente che si possa presentare a qualcuno.
__________________
Desktop: Phenom II x6 1055T, AsRock 890FX Deluxe 4, 4x4 Gb 1600 Mhz, NVidia GeForce GTX 960 2 Gb GDDR5, SB X-FI Fatal1ty Pro, 1 Tb ssd + 500 + 320 Gb 7200 Rpm, Windows 10 Home 64 Bit Notebook: Asus X551CA-SX024D Xubuntu 20.04 LTS 64 Bit Tablet: Asus Nexus 7 32 Gb Wifi Smartphone: Redmi Note 9 Pro 6/128
andy45 è offline   Rispondi citando il messaggio o parte di esso
Old 11-03-2021, 07:12   #66
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da unnilennium Guarda i messaggi
i problemi dei formati office sono noti, e in molti ci hanno sbattuto contro. parliamo di interoperabilità tra le varie versioni di office, dalla preistoria ad oggi, perchè microsoft evolve le funzionalità senza tenere conto del formato, che resta lo stesso. purtroppo è una realtà oggettiva. le varie alternative, libreoffice in primis, soffrono dello stesso problema con i loro formati, un odf su openoffice potrebbe essere letto diversamente su una edizione più recente di libreoffice, e viceversa...
Quello che riporti non è un problema dei formati di Office, visto che tu stesso riporti problematiche simili con altre applicazioni.

E aggiungo che si tratta di una cosa perfettamente naturale e comune per qualunque applicazione: quando vengono aggiunge nuove funzionalità a un formato, è ovvio che ci saranno problemi con le precedenti versioni dell'applicazione.
Quote:
certo, odf poteva diventare uno standard iso, e allora magari avremmo avuto qualche speranza di vedere qualcosa di buono,
Veramente OpenDocument E' uno standard ISO:
"OpenDocument Format (or ODF for short) is the worlds leading document standard as maintained by the Organization for the Advancement of Structured Information Standards (OASIS), and was first adopted as an international standard in 2005 by ISO/IEC JTC1 SC34."
Quote:
ma microsoft ha fatto il suo solito gioco sporco...
https://www.wired.com/2007/08/micros...onal-standard/

https://www.networkmiddleeast.com/51...-foul-play?amp

chissà perchè?
FUD e campagna contro, come al solito quando si parla di Microsoft.

Infatti, come puoi leggere dal secondo link, l'approvazione è fallita la prima volta, e OpenXML è stato approvato soltanto dopo. Peraltro con la Norvegia a favore, quando prima s'era scagliata duramente contro.
Quote:
forse per continuare a mantenere la sua posizione dominante?
Mi pare ovvio che faccia i suoi interessi. OpenXML è un formato che si adatta perfettamente all'implementazione di Office, per cui è più facile da implementare e mantenere per Microsoft.
Quote:
la soluzione a tutti i problemi, comprarsi una licenza microsoft, o un abbonamento a office 365. però almeno diciamo la verità, è una porcata.
Ma proprio no. Vatti a vedere cos'hanno fatto con OpenDocument, quando è stato standardizzato: non avevano nemmeno specificato il formato delle formule! Sì, proprio delle formule! Incredibile, eh? Il bello che veniva spacciato come il formato per eliminare i problemi di interoperabilità... lasciando assoluta libertà a chiunque di definire le formule come volevano.

Questa come al chiameresti tu? Porcata?
Quote:
Originariamente inviato da biffuz Guarda i messaggi
Scusa ma non ti capisco più, parli di produttività vs prestazioni ma ti lamenti del consumo di risorse e finisci col dire che qualcosa che consuma ancora più risorse alla fine va bene, parli di prestazioni dei linguaggi senza aver la benché minima idea di come misurarle, affermi che servono ingegneria del software ed esperienza servono ma le basi di algoritmi no, anche se dovrebbero essere la prima cosa che si impara dopo hello world...
Se non capisci è un problema tuo, a questo punto: ho scritto quali siano le problematiche con quei due linguaggi, e usandoli assieme su un prodotto come quello hanno realizzato un pastrocchio.
Quote:
Ricordo la presentazione di Office 95 dove si vantavano che gli engine erano stati completamenti riscritti in assembly 32 bit.
Mai sentito. E immagino che tu non abbia alcuna fonte, visto che successivamente ne hai riportato soltanto una che afferma che usino C++ per Office.
Quote:
E Office c'era anche per Mac 68k e PPC.
Spero ti renda conto che ciò deponga a sfavore di ciò che avevi scritto prima, che ti riporto per comodità:
"Il fatto che gli engine di Office sono scritti in assembly è riportato in molti articoli, anche scritti da dirigenti MS, che leggo sin dagli anni '90. Per questo ci mettono una vita a portarlo sulle nuove architetture."


A giudicare dalla storia di Office, e dei porting che ne sono fatti nel tempo, Microsoft non ha proprio avuto problemi con architetture diverse.

Il che lascia pensare che l'uso dell'assembly fosse decisamente ridotto.
Quote:
Congratulazioni, hai appena linkato il manuale ufficiale Microsoft che spiega come sviluppare in assembly (x86, x64 e ARM) in Visual Studio 2019 e usarlo in progetti C/C++, e poi hai detto che non si può fare.
Vediamo se trovi da solo il problema...
Con ciò è evidente che NON usi Visual Studio e quindi lo sconosci del tutto. Soprattutto è evidente che non solo non ti sia preso la briga di leggere una paginetta che già all'inizio avrebbe dovuto farti capire come stiano le cose, ma neppure leggere l'estratto che avevo riportato per comodità.

Infatti quella parte del manuale riguarda, sì, l'inclusione di codice assembly nel codice C/C++, ma ciò è possibile SOLTANTO per IA-32/x86:

"The following topics explain how to use the Visual C/C++ inline assembler with x86 processors"

e NON per x64 e ARM, come avevo già riportato:

"Inline assembly is not supported on the ARM and x64 processors."

Per la serie: non ho la minima idea di quello di cui parlando, ma lo faccio lo stesso.
Quote:
Abbiamo già discusso abbondantemente di questo, insistere non ti darà ragione.
Standardization of Office Open XML:
"he Office Open XML file formats were standardised between December 2006 and November 2008, first by the Ecma International consortium (where they became ECMA-376), and subsequently, after a contentious standardization process, by the ISO/IEC's Joint Technical Committee 1 (where they became ISO/IEC 29500:2008)."

Ancora una volta, non hai la minima idea di ciò di cui parli.
Quote:
Io? Ok...
Direi proprio di sì, e l'ho pure provato.
Quote:
Originariamente inviato da cavaliereombra Guarda i messaggi
A parte un braccio di ferro e utilizzo di termini generici, non vedo altro; nessuna argomentazione ben illustrata. Volete entrare nel tecnico? Tecnico serio, intendo. Non frasette da forum qualunque.
Io sul tecnico ci sono già entrato e ho illustrato le problematiche note dei linguaggi citati.
Quote:
A citare nomi sparsi di esami del primo anno di Informatica non ci vuole niente. E qui siamo tutti informatici programmatori esperti, giusto?
Non direi proprio.
Quote:
Originariamente inviato da biffuz Guarda i messaggi
Mi correggo da solo, Office nell'ultimo decennio è stato sviluppato in C++. E stavolta mi sento buono e vi metto pure una fonte.
https://channel9.msdn.com/Shows/Goin...-C-Renaissance
Sei buono a smentire te stesso? Bravo.

Quando porterai fonti su Office scritto in assembly ne riparliamo.
Quote:
Il porting su mobile e persino sul web sono basati su questo (webassembly). Le fonti ve le lascio da trovare come compito per casa.
Il che, ancora una volta, proverebbe che Office NON sia affatto difficile da portare su architetture diverse, come falsamente avevi attestato prima.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 11-03-2021, 08:50   #67
radeon_snorky
Senior Member
 
Iscritto dal: Mar 2003
Messaggi: 1924
chi ha voglia di tornare in topic?


vabbè, oggi che ho poco da fare proverò questo OnlyOffice, prendo il docx originale che mi ha creato tanti problemi e lo apro sui diversi programmi poi scelgo quale tenere

p.s. giusto per mettere un piede off topic, 365 è solo in abbonamento?
radeon_snorky è offline   Rispondi citando il messaggio o parte di esso
Old 11-03-2021, 09:50   #68
andy45
Senior Member
 
Iscritto dal: Mar 2008
Messaggi: 12259
Quote:
Originariamente inviato da radeon_snorky Guarda i messaggi
p.s. giusto per mettere un piede off topic, 365 è solo in abbonamento?
Si, è solo in abbonamento, quelli aziendali sono al mese, ma puoi fare solo sottoscrizioni annuali mi sembra, quelli domestici possono essere anche solo mensili, ma hanno delle buone offerte per l'abbonamento annuale.
__________________
Desktop: Phenom II x6 1055T, AsRock 890FX Deluxe 4, 4x4 Gb 1600 Mhz, NVidia GeForce GTX 960 2 Gb GDDR5, SB X-FI Fatal1ty Pro, 1 Tb ssd + 500 + 320 Gb 7200 Rpm, Windows 10 Home 64 Bit Notebook: Asus X551CA-SX024D Xubuntu 20.04 LTS 64 Bit Tablet: Asus Nexus 7 32 Gb Wifi Smartphone: Redmi Note 9 Pro 6/128
andy45 è offline   Rispondi citando il messaggio o parte di esso
Old 11-03-2021, 14:51   #69
biffuz
Senior Member
 
L'Avatar di biffuz
 
Iscritto dal: Jul 2001
Messaggi: 3462
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Se non capisci è un problema tuo, a questo punto: ho scritto quali siano le problematiche con quei due linguaggi, e usandoli assieme su un prodotto come quello hanno realizzato un pastrocchio.
--
Io sul tecnico ci sono già entrato e ho illustrato le problematiche note dei linguaggi citati.
A dire il vero non hai dimostrato un bel niente, e sembra che ritieni che gli stessi problemi non si avrebbero con altri linguaggi "più produttivi", ma vabbé.

Quote:
Mai sentito. E immagino che tu non abbia alcuna fonte, visto che successivamente ne hai riportato soltanto una che afferma che usino C++ per Office.
--
Spero ti renda conto che ciò deponga a sfavore di ciò che avevi scritto prima, che ti riporto per comodità:
"Il fatto che gli engine di Office sono scritti in assembly è riportato in molti articoli, anche scritti da dirigenti MS, che leggo sin dagli anni '90. Per questo ci mettono una vita a portarlo sulle nuove architetture."

--
A giudicare dalla storia di Office, e dei porting che ne sono fatti nel tempo, Microsoft non ha proprio avuto problemi con architetture diverse.
--
Il che lascia pensare che l'uso dell'assembly fosse decisamente ridotto.
--
Quando porterai fonti su Office scritto in assembly ne riparliamo.
--
Il che, ancora una volta, proverebbe che Office NON sia affatto difficile da portare su architetture diverse, come falsamente avevi attestato prima.
Mi secca ammetterlo ma non trovo fonti online, dopo ben quindici minuti di ricerche. Tutto quello che posso dire è che leggevo parecchie riviste negli anni '90/'00 e questo fatto era riportato più volte. Visto che non sei il mio capo o un mio cliente, e questo non è uno studio scientifico o un articolo di giornale, e nemmeno c'è rischio che su questa affermazione nasca un culto come quello della terra piatta, io mi fermo qui.

A voler essere pignoli, nemmeno tu hai riportato alcuna fonte che spiegasse in quale linguaggio è scritto Office, hai solo dato per scontato che non fosse assembly.

Quote:
Con ciò è evidente che NON usi Visual Studio e quindi lo sconosci del tutto. Soprattutto è evidente che non solo non ti sia preso la briga di leggere una paginetta che già all'inizio avrebbe dovuto farti capire come stiano le cose, ma neppure leggere l'estratto che avevo riportato per comodità.

Infatti quella parte del manuale riguarda, sì, l'inclusione di codice assembly nel codice C/C++, ma ciò è possibile SOLTANTO per IA-32/x86:

"The following topics explain how to use the Visual C/C++ inline assembler with x86 processors"

e NON per x64 e ARM, come avevo già riportato:

"Inline assembly is not supported on the ARM and x64 processors."

Per la serie: non ho la minima idea di quello di cui parlando, ma lo faccio lo stesso.
Se lo dici tu...

http://www.biffuz.it/tmp/Immagine.png (non si carica inline perché non ho https)

Sicuro di aver capito di cosa parla la paginetta che mi hai linkato?

Potrei farti un esempio più completo, in cui chiamo codice assembly da C++ e viceversa, ma ho già sprecato abbastanza pausa pranzo. Se vuoi approfondire sentiti libero di cercare ulteriori fonti online.

Quote:
Quello che riporti non è un problema dei formati di Office, visto che tu stesso riporti problematiche simili con altre applicazioni.

E aggiungo che si tratta di una cosa perfettamente naturale e comune per qualunque applicazione: quando vengono aggiunge nuove funzionalità a un formato, è ovvio che ci saranno problemi con le precedenti versioni dell'applicazione.

Veramente OpenDocument E' uno standard ISO:
"OpenDocument Format (or ODF for short) is the worlds leading document standard as maintained by the Organization for the Advancement of Structured Information Standards (OASIS), and was first adopted as an international standard in 2005 by ISO/IEC JTC1 SC34."

FUD e campagna contro, come al solito quando si parla di Microsoft.

Infatti, come puoi leggere dal secondo link, l'approvazione è fallita la prima volta, e OpenXML è stato approvato soltanto dopo. Peraltro con la Norvegia a favore, quando prima s'era scagliata duramente contro.

Mi pare ovvio che faccia i suoi interessi. OpenXML è un formato che si adatta perfettamente all'implementazione di Office, per cui è più facile da implementare e mantenere per Microsoft.

Standardization of Office Open XML:
"he Office Open XML file formats were standardised between December 2006 and November 2008, first by the Ecma International consortium (where they became ECMA-376), and subsequently, after a contentious standardization process, by the ISO/IEC's Joint Technical Committee 1 (where they became ISO/IEC 29500:2008)."

Ancora una volta, non hai la minima idea di ciò di cui parli.

Direi proprio di sì, e l'ho pure provato.
Francamente hai provato che leggi solo le parti che ti interessano dei link che tu stesso riporti.
__________________
www.biffuz.it | Thou shall not follow the NULL pointer, for chaos and madness await thee at its end.
Powered by: M1 @ Sonoma | 3770k @ W10 | C2Q @ XP | P!!! @ W98+BeOS | 286 @ W3.1 | C64 | iP8+ | iPad8 | rPi4 | and more...

Ultima modifica di biffuz : 11-03-2021 alle 14:59.
biffuz è offline   Rispondi citando il messaggio o parte di esso
Old 12-03-2021, 07:27   #70
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da biffuz Guarda i messaggi
A dire il vero non hai dimostrato un bel niente, e sembra che ritieni che gli stessi problemi non si avrebbero con altri linguaggi "più produttivi", ma vabbé.
Direi proprio di sì. C# è più produttivo, più veloce, e mediamente molto più parco di risorse rispetto a Java, tanto per fare un esempio di due linguaggi/piattaforme similari.

Ecco qualche benchmark.
Quote:
Mi secca ammetterlo ma non trovo fonti online, dopo ben quindici minuti di ricerche. Tutto quello che posso dire è che leggevo parecchie riviste negli anni '90/'00 e questo fatto era riportato più volte. Visto che non sei il mio capo o un mio cliente, e questo non è uno studio scientifico o un articolo di giornale, e nemmeno c'è rischio che su questa affermazione nasca un culto come quello della terra piatta, io mi fermo qui.
Anch'io leggevo riviste dell'epoca nonché BBS, e non ho mai letto roba del genere.
Quote:
A voler essere pignoli, nemmeno tu hai riportato alcuna fonte che spiegasse in quale linguaggio è scritto Office,
Non ne avevo bisogno: non ho mai proposto tesi del genere, e dunque non avevo alcun onere da sostenere.
Quote:
hai solo dato per scontato che non fosse assembly.
Continui ad avere problemi di lettura: mai detto nulla del genere.

Ecco qui ciò che avevo scritto in merito: "Dubito fortemente che abbiano mantenuto il core in assembly, se non eventualmente per piccole sezioni critiche per IA-32/x86"

Che è ben diverso da quanto vorresti appiopparmi.
Quote:
Se lo dici tu...

http://www.biffuz.it/tmp/Immagine.png (non si carica inline perché non ho https)

Sicuro di aver capito di cosa parla la paginetta che mi hai linkato?
Continui ad avere problemi di lettura. Ecco cosa riporta quella paginetta:
"Inline Assembler
[...]
You can use the inline assembler to embed assembly-language instructions directly in your C and C++ source programs without extra assembly and link steps. The inline assembler is built into the compiler, so you don't need a separate assembler such as the Microsoft Macro Assembler (MASM)."
Quote:
Potrei farti un esempio più completo, in cui chiamo codice assembly da C++ e viceversa, ma ho già sprecato abbastanza pausa pranzo. Se vuoi approfondire sentiti libero di cercare ulteriori fonti online.
Non ne ho bisogno, grazie. Il tuo esempio dimostra che devi ricorrere a un assembler esterno, come riporta la suddetta documentazione Microsoft. Cosa ovvia, e che peraltro puoi fare anche con linguaggi di programmazione diversi, ma è un'altra cosa rispetto a poter avere assembly inserito direttamente nel codice C/C++, che è di gran lunga più comodo, semplice, e non richiede salti mortali quando hai a che fare con applicazioni complesse, soprattutto se OOP.
Quote:
Francamente hai provato che leggi solo le parti che ti interessano dei link che tu stesso riporti.
Cercare di cambiare discorso è perfettamente inutile. Avevi detto questo:
"I problemi dei formati di Office sono stranoti, non capisco perché insisti a dire che sono aperti e documentati"
che è palesemente falso, come ho dimostrato.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 12-03-2021, 10:19   #71
biffuz
Senior Member
 
L'Avatar di biffuz
 
Iscritto dal: Jul 2001
Messaggi: 3462
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Direi proprio di sì. C# è più produttivo, più veloce, e mediamente molto più parco di risorse rispetto a Java, tanto per fare un esempio di due linguaggi/piattaforme similari.
Ma cosa c'entra C# adesso?
Java e C# a mio parere sono talmente simili che la produttività è questione di gusti e abitudini, e gli IDE aiutano molto, ma meglio che non scendo nei dettagli prima che mi chiedi le prove.

Quote:
Non ne avevo bisogno: non ho mai proposto tesi del genere, e dunque non avevo alcun onere da sostenere.

Continui ad avere problemi di lettura: mai detto nulla del genere.

Ecco qui ciò che avevo scritto in merito: "Dubito fortemente che abbiano mantenuto il core in assembly, se non eventualmente per piccole sezioni critiche per IA-32/x86"

Che è ben diverso da quanto vorresti appiopparmi.
Credo che tu abbia ragione, d'ora in poi penso che inizierò ogni frase con "dubito fortemente", "sono ragionevolmente sicuro", "a mio modesto parere" o locuzioni simili, così se qualcuno mi smentisce posso sempre uscirne con "la mia non era un'affermazione, stavo solo esponendo un'opinione".
Mi pare anche che molti politici con gran seguito facciano la stessa identica cosa, dopotutto...

Quote:
Continui ad avere problemi di lettura. Ecco cosa riporta quella paginetta:
"Inline Assembler
[...]
You can use the inline assembler to embed assembly-language instructions directly in your C and C++ source programs without extra assembly and link steps. The inline assembler is built into the compiler, so you don't need a separate assembler such as the Microsoft Macro Assembler (MASM)."
Ti quoto quello che hai scritto tu

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
- 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.
Da "non supporta la sintassi inline" "non supporto assembly" mi sembra un bel salto logico.

Quote:
Non ne ho bisogno, grazie. Il tuo esempio dimostra che devi ricorrere a un assembler esterno, come riporta la suddetta documentazione Microsoft. Cosa ovvia, e che peraltro puoi fare anche con linguaggi di programmazione diversi, ma è un'altra cosa rispetto a poter avere assembly inserito direttamente nel codice C/C++, che è di gran lunga più comodo, semplice, e non richiede salti mortali quando hai a che fare con applicazioni complesse, soprattutto se OOP.
A me pare che il mio esempio abbia smentito la tua affermazione. Il "tool esterno" è un componente della suite che viene installato assieme a tutti gli altri se selezioni il supporto C/C++ nel setup.
E se non sei un folle che scriveva assembly inline in ogni file, e hai dato una struttura decente al tuo progetto, rinunciare a questa piccola comodità non lo ritengo un gran lavoro.

Quote:
Cercare di cambiare discorso è perfettamente inutile. Avevi detto questo:
"I problemi dei formati di Office sono stranoti, non capisco perché insisti a dire che sono aperti e documentati"
che è palesemente falso, come ho dimostrato.
A me pare invece che la pagina di Wikipedia che tu stesso hai linkato dice esattamente quello che io e molti altri abbiamo detto: quello standard è farlocco.


E adesso basta, chiudo qui la discussione.
__________________
www.biffuz.it | Thou shall not follow the NULL pointer, for chaos and madness await thee at its end.
Powered by: M1 @ Sonoma | 3770k @ W10 | C2Q @ XP | P!!! @ W98+BeOS | 286 @ W3.1 | C64 | iP8+ | iPad8 | rPi4 | and more...
biffuz è offline   Rispondi citando il messaggio o parte di esso
Old 13-03-2021, 07:57   #72
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26107
Quote:
Originariamente inviato da biffuz Guarda i messaggi
Ma cosa c'entra C# adesso?
C'entra perché se scrivi questo:
"sembra che ritieni che gli stessi problemi non si avrebbero con altri linguaggi "più produttivi"
ti ho fatto un esempio in merito.
Quote:
Java e C# a mio parere sono talmente simili che la produttività è questione di gusti e abitudini, e gli IDE aiutano molto, ma meglio che non scendo nei dettagli prima che mi chiedi le prove.
Ovviamente te le chiederei: non siamo mica al bar dello sport.
Quote:
Credo che tu abbia ragione, d'ora in poi penso che inizierò ogni frase con "dubito fortemente", "sono ragionevolmente sicuro", "a mio modesto parere" o locuzioni simili, così se qualcuno mi smentisce posso sempre uscirne con "la mia non era un'affermazione, stavo solo esponendo un'opinione".
Mi pare anche che molti politici con gran seguito facciano la stessa identica cosa, dopotutto...
No, sarebbe sufficiente utilizzare la lingua italiana in maniera appropriata. Tutto qui.
Quote:
Ti quoto quello che hai scritto tu

Da "non supporta la sintassi inline" "non supporto assembly" mi sembra un bel salto logico.
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:
"Il fatto che gli engine di Office sono scritti in assembly è riportato in molti articoli"
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:
"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."

che parla per l'appunto di "inline assembly".
Quote:
A me pare che il mio esempio abbia smentito la tua affermazione. Il "tool esterno" è un componente della suite che viene installato assieme a tutti gli altri se selezioni il supporto C/C++ nel setup.
Come già detto sopra, è a dire poco OVVIO che questi strumenti includano un assemblatore.
Quote:
E se non sei un folle che scriveva assembly inline in ogni file, e hai dato una struttura decente al tuo progetto, rinunciare a questa piccola comodità non lo ritengo un gran lavoro.
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.
Quote:
A me pare invece che la pagina di Wikipedia che tu stesso hai linkato dice esattamente quello che io e molti altri abbiamo detto: quello standard è farlocco.
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.
Quote:
E adesso basta, chiudo qui la discussione.
Per me puoi fare quello che vuoi.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 30-03-2021, 15:08   #73
Giulio92
Junior Member
 
Iscritto dal: Mar 2021
Messaggi: 21
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!
Giulio92 è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Apple MacBook Air M3: chi deve davvero comprarlo? La recensione Apple MacBook Air M3: chi deve davvero comprarlo...
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
NIO inizia la produzione del sistema a 9...
Microsoft Edge consentirà di limi...
I driver NVIDIA crashano al torneo milio...
Rinviato l'ultimo lancio del razzo spazi...
CMF Buds by Nothing: gli auricolari econ...
Accordo di intesa firmato, saranno di SK...
iPhone, il supporto alla messaggistica R...
Una GeForce RTX 3080 a meno di 800 euro ...
Ecco le migliori offerte sui processori ...
Polestar presenta Polestar Charge, il se...
PyPI bersagli di un attacco malware: reg...
Putin ha chiesto al governo russo di pen...
Un display AMOLED curvo su un dissipator...
Speciale sedie da ufficio e gaming in of...
Aggiornamenti per Sony Alpha 1, Alpha 9 ...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 14:14.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www3v
1