[*]: Bloccare l'orologio di Windows

[billiejoex]

Anch'io!
Comunque non vedo come un linguaggio di livello più alto avrebbe potuto snellire questo codice

Malfidente... =)

import win32api
import time
from datetime import datetime, timedelta

wait_time = 2

while 1:
    first_time = win32api.GetSystemTime()
    (year, month , dayOfWeek , day , hh , mm , ss , ms) = first_time
    dtA = datetime(year, month, day, hour=hh, minute=mm, second=ss) - timedelta(seconds=0)
    time.sleep(wait_time)
    second_time = win32api.GetSystemTime()
    year, month , dayOfWeek , day , hh , mm , ss , ms = second_time
    dtB = datetime(year, month, day, hour=hh, minute=mm, second=ss) - timedelta(seconds=wait_time)
    if dtB != dtA:
         print "A time difference was found!"
         print "Resetting system clock to original time state of %s secs ago." %wait_time
         (year, month , dayOfWeek , day , hh , mm , ss , ms) = first_time
         win32api.SetSystemTime(year, month , dayOfWeek , day , hh , mm , ss , ms)

Il programma checka l'orologio di sistema ogni 2 secondi. Se passatato tale tempo l'ora è diversa da "ora precedente" + 2 secondi, il programma setta l'orologio di sistema a "ora precedente".
Non ho implementato le mailslot (che roba è?) e registrato il processo come servizio come hai fatto tu, ma penso che si evinca lo stesso chiaramente la maggiore produttività rispetto a C/C++ di cui ti parlavo prima.

[MItaly]

Guarda il mio codice corrispondente a quello che hai scritto: poche righe in più (qualcosa tipo 8), che, tra parentesi, sono dovute alle graffe e alle dichiarazioni che amo tenere su una riga singola e al fatto che il mio programma scrive direttamente sullo schermo, il che richiede l'apertura e la chiusura del Device Context. Inoltre la mia versione C è molto più veloce ed efficiente, sia perché le funzioni sono linkate al momento della compilazione sia perché il C è compilato (mentre il Python è interpretato).

Non ho implementato le mailslot (che roba è?) e registrato il processo come servizio come hai fatto tu

Adesso però io sono curioso di vedere un codice analogo scritto in Python

Appunto, lì sta la potenza del C e soprattutto la comodità di avere tutti gli header con già i riferimenti a tutte le API necessarie...
Una mailslot è una "casella di posta" aperta da un programma, in cui qualunque processo può "imbucare messaggi" ma che solo il proprietario può aprire e recuperarne le "lettere". Detto più tecnicamente, si tratta di un metodo di IPC (InterProcess Communication) particolarmente adatto al mio programma.
Infatti se il programma viene lanciato senza parametri crea la sua "casella di posta" e quindi avvia il ciclo di controllo dell'orologio; tuttavia, a differenza del tuo codice, nel mio il ciclo non è infinito, ma è governato dalla funzione ReadMessages, che legge i messaggi contenuti nella MailSlot e, se ce n'è uno che dice al programma di uscire (messaggio "terminate") restituisce false, in modo da far terminare il ciclo.
Se invece il programma viene lanciato con parametri il programma apre in scrittura la MailSlot e invia molto brutalmente i parametri dati sulla linea di comando come messaggi per l'istanza del programma lanciata in precedenza (ovviamente se il programma non è già stato avviato la mailslot non esisterà e quindi si verificherà un errore).
Tutto questo consente di disattivare il programma in questione qualora si volessero effettuare modifiche all'orologio "autorizzate": infatti trattandosi di un programma che viene lanciato all'avvio del sistema e che si nasconde dal task manager di Windows 9x non esisterebbe altrimenti un modo comodo di disattivarlo.

ma penso che si evinca lo stesso chiaramente la maggiore produttività rispetto a C/C++ di cui ti parlavo prima.

Scrivimi un programma con le identiche caratteristiche del mio, compresa la gestione della mailslot e la registrazione come servizio del processo (lavoraccio, bisogna anche controllare che la funzione RegisterServiceProcess sia presente in kernel32.dll perché c'è solo sotto Windows 9x) in meno codice e meno tempo ("maggiore produttività" significa questo, a casa mia) e ti darò ragione.

[MItaly]

P.S.: il tuo codice non implementa una tolleranza del 10% sul controllo della differenza di tempo, il che a mio avviso è molto importante, considerato che il sistema può sempre bloccarsi per qualche attimo e non far ripartire il thread dopo l'esatto tempo specificato nella funzione Sleep.

[billiejoex]

Guarda il mio codice corrispondente a quello che hai scritto: poche righe in più (qualcosa tipo 8), che, tra parentesi, sono dovute alle graffe e alle dichiarazioni che amo tenere su una riga singola e al fatto che il mio programma scrive direttamente sullo schermo, il che richiede l'apertura e la chiusura del Device Context.

Come sarebbe 8 righe in più? D'accordo che hai aggiunto mail slot, registrato il processo come servizio ecc... ma anche se non avessi fatto queste cose non avresti cmq mai raggiunto un codice della stessa lunghezza, a partire dal fatto che in Python ho una tipizzazione dinamica mentre tu in C, avendola statica, sei obbligato a dichiarare i tipi.
Il punto di forza per eccellenza di linguaggi interpretati come Py e Ruby è proprio la più elevata produttività nello scrivere codice. Se manco quello vuoi riconoscergli, siamo a posto! =)

Inoltre la mia versione C è molto più veloce ed efficiente, sia perché le funzioni sono linkate al momento della compilazione sia perché il C è compilato (mentre il Python è interpretato).

Sono d'accordo, ma in un programma come questo serve che un ciclo si completi in 0.0001 ms (C) anzichè 0.01 (Python)? Direi di no...
A questo punto se lo avessi scritto in assembly il ciclo si sarebbe completato 1000 ms in anticipo, e con questo? Avrebbe avuto utilità? Sarebbe valsa la pena scrivere un migliaio di righe di codice in più e aver perso centinaia di ore di vita su dei libri per acquisire le conoscenze tecniche per giungere ad un simile risultato? Serve che una message box compaia 0.01 secondi prima?
Sono queste le domande che, secondo me, si dovrebbero porre i puristi che vogliono per forza i linguaggi ultra veloci (non mi sto riferendo a te, beninsteso).

P.S.: il tuo codice non implementa una tolleranza del 10% sul controllo della differenza di tempo, il che a mio avviso è molto importante, considerato che il sistema può sempre bloccarsi per qualche attimo e non far ripartire il thread dopo l'esatto tempo specificato nella funzione Sleep.

E' senza dubbio importante. Il mio codice, infatti, è puramente dimostrativo.

Scrivimi un programma con le identiche caratteristiche del mio, compresa la gestione della mailslot e la registrazione come servizio del processo (lavoraccio, bisogna anche controllare che la funzione RegisterServiceProcess sia presente in kernel32.dll perché c'è solo sotto Windows 9x) in meno codice e meno tempo ("maggiore produttività" significa questo, a casa mia) e ti darò ragione.

Guarda, sinceramente non me la sento di mettermi a fare questo lavoraccio per un programma del genere, senza contare che cmq non ho mai lavorato con le mailslot e non ho tempo/voglia sufficienti per documentarmi (ovviamente vi è anche la possibilità che non lo riesca tecnicamente a fare, beninteso...).
Ciò non toglie che linguaggi come C, C++ e Java sono da 2 a 10 volte meno produttivi, nel senso che un codice analogo scritto in tali linguaggi è da 2 a 10 volte più lungo rispetto al corrispettivo Python.
Ma questo non lo dico io: lo dicono voci molto più autorevoli della mia, nonchè, ben più importante, i dati di fatto nudi e crudi.
Se tu hai dubbi sul fatto che un linguaggio interpretato, e in particolare Python, non sia tanto più produttivo dei sopra citati, come affermo da 2 o 3 post, senza offesa, ma penso che dovresti documentarti decisamente meglio a riguardo...
...perchè un sorgente C sarà praticamente quasi sempre più lungo di un corrispettivo scritto in Python. Ma non di poco... di tanto, tanto, proprio!

Scrivimi un programma con le identiche caratteristiche del mio, in meno codice e meno tempo ("maggiore produttività" significa questo, a casa mia) e ti darò ragione

Qualunque pythoniano ti direbbe che è una sfida persa in partenza.

[billiejoex]

PS - Il primo esempio che mi è capitato con un search:
http://forum.html.it/forum/showthrea...ghlight=Python
Qui hai una risoluzione ad un problema sia in C che in Python.
Qui penso che si adatti perfettamente l'affermazione di prima ("Python è produttivo da 2 a 10 volte in più rispetto a C/C++/Java"). In questo caso lo è stato 10.

[MItaly]

Originariamente inviato da billiejoex
Come sarebbe 8 righe in più? D'accordo che hai aggiunto mail slot, registrato il processo come servizio ecc... ma anche se non avessi fatto queste cose non avresti cmq mai raggiunto un codice della stessa lunghezza, a partire dal fatto che in Python ho una tipizzazione dinamica mentre tu in C, avendola statica, sei obbligato a dichiarare i tipi.

Parlo di 8 righe in più riferendomi al mio codice corrispondente a quello che hai scritto, ossia il solo ciclo infinito più le dichiarazioni. E, per favore, non parlarmi di tipizzazione dinamica, che è uno dei peggiori obbrobri che io abbia mai visto e che è caratteristica solo dei linguaggi più fecciosi, soprattutto di quelli di scripting; non serve assolutamente a NIENTE, è uno spreco di memoria e di tempo di CPU inutile perché costringe l'interprete a continui cast interni e nascosti al programmatore ed è fonte di errori difficilmente individuabili.

Il punto di forza per eccellenza di linguaggi interpretati come Py e Ruby è proprio la più elevata produttività nello scrivere codice. Se manco quello vuoi riconoscergli, siamo a posto! =)

Il mio punto di vista è che sono linguaggi più verso lo scripting che la programmazione vera e propria. Chiaro che se devo automatizzare un'operazione ripetitiva o simili scriverò un file batch o un VBS o uno script della shell (sotto Linux), ma se devo scrivere un programma vero ci tengo al fatto che sprechi il minimo di risorse.

Sono d'accordo, ma in un programma come questo serve che un ciclo si completi in 0.0001 ms (C) anzichè 0.01 (Python)? Direi di no...
A questo punto se lo avessi scritto in assembly il ciclo si sarebbe completato 1000 ms in anticipo, e con questo? Avrebbe avuto utilità? Sarebbe valsa la pena scrivere un migliaio di righe di codice in più e aver perso centinaia di ore di vita su dei libri per acquisire le conoscenze tecniche per giungere ad un simile risultato? Serve che una message box compaia 0.01 secondi prima?
Sono queste le domande che, secondo me, si dovrebbero porre i puristi che vogliono per forza i linguaggi ultra veloci (non mi sto riferendo a te, beninsteso).

È ottima norma di programmazione risparmiare le risorse, in particolare in un programma che come questo deve essere in esecuzione dall'avvio all'arresto del sistema. Nel caso del Python si sarebbe dovuto caricare l'interprete e il runtime di Python, di un peso non indifferente su sistemi meno recenti (come è il caso probabilmente del PC su cui andrà eseguito questo programma, visto che sarà dell'epoca di Windows ME); non bisogna MAI pensare che tutto il mondo vada con un Athlon 64 3800+ con 1 GB di RAM, ed è scrivendo programmi per sistemi tipo Pentium 1 con 32-massimo 64 MB di RAM che ho sviluppato la tendenza a scrivere codice efficiente. Sempre a questo proposito bisogna considerare che l'interprete, oltre che essere un peso in memoria, va anche installato, una seccatura per l'utente che richiede anche i diritti di amministratore sugli OS NT. Ultima precisazione di natura prestazionale: non siamo più al tempo di MS-DOS, in cui il programma aveva tutto il sistema per sé e poteva buttare le risorse nel cesso come gli pareva, Windows è a tutti gli effetti un sistema multitasking in cui il tuo programma deve convivere con il resto del sistema; lo spreco di risorse si ripercuote sulla velocità del proprio programma come su quella degli altri: ad esempio, se si consuma tanta memoria da costringere il sistema operativo a continuare ad effettuare lo swapping di pagine di memoria sul disco la velocità dell'intero sistema crollerà a livelli da 386DX.

Guarda, sinceramente non me la sento di mettermi a fare questo lavoraccio per un programma del genere, senza contare che cmq non ho mai lavorato con le mailslot e non ho tempo/voglia sufficienti per documentarmi (ovviamente vi è anche la possibilità che non lo riesca tecnicamente a fare, beninteso...).

Neanch'io lo farei (se il problema è già stato risolto da un altro perché perderci dietro altro tempo?) .

Ciò non toglie che linguaggi come C, C++ e Java sono da 2 a 10 volte meno produttivi, nel senso che un codice analogo scritto in tali linguaggi è da 2 a 10 volte più lungo rispetto al corrispettivo Python.

Qui è necessaria un'importante distinzione: C e C++ sono una cosa, Java un'altra. C e C++ sono da sempre linguaggi compilati, particolarmente veloci, pensati per essere comodi per il programmatore esperto (consentono cast di ogni genere, maneggi con i puntatori e simili); Java invece è super type safe, dispone di una libreria di classi molto più astratta dalla piattaforma e soprattutto è un linguaggio pseudo-compilato e multipiattaforma. A mio parere è molto più vicino al Python rispetto al C, di cui condivide la sintassi e poco più.

Ma questo non lo dico io: lo dicono voci molto più autorevoli della mia, nonchè, ben più importante, i dati di fatto nudi e crudi.
Se tu hai dubbi sul fatto che un linguaggio interpretato, e in particolare Python, non sia tanto più produttivo dei sopra citati, come affermo da 2 o 3 post, senza offesa, ma penso che dovresti documentarti decisamente meglio a riguardo...
...perchè un sorgente C sarà praticamente quasi sempre più lungo di un corrispettivo scritto in Python. Ma non di poco... di tanto, tanto, proprio!

Posso preferire un linguaggio di più alto livello (nel senso tecnico del termine, beninteso) quando mi può far risparmiare un bel po' di tempo, magari semplificandomi il lavoro con le finestre (in C/C++ è un macello, anche se le MFC aiutano molto) e con le stringhe (idem, ma come già detto anche in C++ esistono ottime classi che fungono alla perfezione), ma per il resto credo che il C++ sia tuttora un'ottima scelta. Chiedi alla Microsoft, alla Apple, a Linus Torwald o a qualunque ditta seria perché tutti i loro programmi o quasi, in primis i loro sistemi operativi, sono scritti in C o in C++; chiedi alla Microsoft o alla Sun perché ora hanno puntato tutto su Microsoft .NET o su Java, che sono linguaggi (o nel caso di .NET, tecnologie) pseudo-compilati (e) ma particolarmente attenti al consumo delle risorse e orientati verso uno stile di programmazione pulita: ad esempio, né l'uno né l'altro impongono l'uso di variabili a tipizzazione automatica, al massimo si può usare il tipo object e il late bound, ma è una pratica scoraggiata.

Qualunque pythoniano ti direbbe che è una sfida persa in partenza.

Qui ci affidiamo a fonti faziose...

[MItaly]

Originariamente inviato da billiejoex
PS - Il primo esempio che mi è capitato con un search:
http://forum.html.it/forum/showthrea...ghlight=Python
Qui hai una risoluzione ad un problema sia in C che in Python.
Qui penso che si adatti perfettamente l'affermazione di prima ("Python è produttivo da 2 a 10 volte in più rispetto a C/C++/Java"). In questo caso lo è stato 10.

In quel problema Python andava ovviamente molto meglio come compattezza del codice, ma si tratta appunto di un mestiere da script, non da programma stand-alone. D'altra parte quel codice C non era un granché scritto bene (se non sbaglio c'è una funzione di libreria che consente di saltare tutti i caratteri di uno stream fino ad arrivare ad un delimitatore specificato), e la maggior parte del codice era dedicata alla gestione degli errori (completamente assente nello script Python).

[billiejoex]

non parlarmi di tipizzazione dinamica, che è uno dei peggiori obbrobri che io abbia mai visto e che è caratteristica solo dei linguaggi più fecciosi, soprattutto di quelli di scripting; non serve assolutamente a NIENTE, è uno spreco di memoria e di tempo di CPU inutile perché costringe l'interprete a continui cast interni e nascosti al programmatore ed è fonte di errori difficilmente individuabili.

Beh, che non serva a niente mi pare una affermazione azzardata, ma come al solito qui ci sono sempre differenti correnti religiose.
Che sia inutile non credo sia vero: serve, appunto, a migliorare il linguaggio in termini di produttività, ovvero quel parametro che fa scrivere al programmatore 5 righe di codice anzichè 20: esso non dovrà perdere tempo a dichiarare il tipo prima di assegnare un valore all'oggetto e potrà cambiare tipo di oggetto a runtime in qualunque momento. Ovvio che questo si paga in prestazioni ma è innegabile che il carico sul programmatore è minore (da qui ritengo abbastanza azzardata la tua affermazione).
Anche il discorso degli errori è semmai mitigato dalla tipizzazione statica, non incoraggiato.

Il mio punto di vista è che sono linguaggi più verso lo scripting che la programmazione vera e propria.

Non mi pare che linguaggi quali Python, Ruby e Java siano evitati in produzione.
Anzi, Java stesso è ormai da tutte le parti. In Java ci hanno fatto freenet, in Python bittorrent e persino dei web server, giusto per dire.
Non credo che con un mero linguaggio di scripting tu riesca a sviluppare queste cose, ed è altrettanto errato catalogare Python come mero linguaggio di scripting.

È ottima norma di programmazione risparmiare le risorse, in particolare in un programma che come questo deve essere in esecuzione dall'avvio all'arresto del sistema. Nel caso del Python si sarebbe dovuto caricare l'interprete e il runtime di Python, di un peso non indifferente su sistemi meno recenti (come è il caso probabilmente del PC su cui andrà eseguito questo programma, visto che sarà dell'epoca di Windows ME)

Accidenti che sforzo caricare l'interprete! Saranno si è no 3000 kb in memoria!
Su Windows 95 ci gira Office e tu vai a fare storie per un programma del genere? Ma andiamo...

non bisogna MAI pensare che tutto il mondo vada con un Athlon 64 3800+ con 1 GB di RAM, ed è scrivendo programmi per sistemi tipo Pentium 1 con 32-massimo 64 MB di RAM che ho sviluppato la tendenza a scrivere codice efficiente.

Sono d'accordo ma che efficienza vuoi pretendere da un programma come questo? Cercare di rendere un programma il più efficiente possibile è sicuramente un bene. Quando si cerca l'efficenza anche per stampare a video un 'hello world', però, mi sembra si esageri.
Stiamo parlando di un programma che monitora e modifica l'ora, non di un password cracker che deve provare milioni di combinazioni al secondo.

Sempre a questo proposito bisogna considerare che l'interprete, oltre che essere un peso in memoria, va anche installato, una seccatura per l'utente che richiede anche i diritti di amministratore sugli OS NT.

E' sicuramente una seccatura. Questo è uno degli svantaggi dei linguaggi come Java & co.
Dall'altra, però, hai il vantaggio che scrivi il codice una volta e poi lo fai girare senza modifiche sia su Windows che su AmigaOS che, addirittura, su Symbian.
I pro e i contro ci sono in tutte le cose, dopo tutto...
Ad ogni modo è possibile generare eseguibili anche in Python, eseguibili runnabili su macchine senza interprete installato.

Ultima precisazione di natura prestazionale: non siamo più al tempo di MS-DOS, in cui il programma aveva tutto il sistema per sé e poteva buttare le risorse nel cesso come gli pareva, Windows è a tutti gli effetti un sistema multitasking in cui il tuo programma deve convivere con il resto del sistema; lo spreco di risorse si ripercuote sulla velocità del proprio programma come su quella degli altri: ad esempio, se si consuma tanta memoria da costringere il sistema operativo a continuare ad effettuare lo swapping di pagine di memoria sul disco la velocità dell'intero sistema crollerà a livelli da 386DX.

Mi pare evidente che tu creda che un interprete è qualcosa di simile ad un Macromedia Dreamweaver o ad un MS Office o un drago a tre teste che utilizza il computer. Beh... non è così.

Chiedi alla Microsoft, alla Apple, a Linus Torwald o a qualunque ditta seria perché tutti i loro programmi o quasi, in primis i loro sistemi operativi, sono scritti in C o in C++

Mi pare ovvio: in quel caso stavano sviluppando un sistema operativo che di natura deve essere ottimizzato al massimo. Ma mi dici cosa cambia se una applicazione come Messanger, giusto per dire, mi si avvia 0,1 secondi dopo se la sviluppo in Python, Ruby o Java? Ha senso usare Assembler per scrivere una rubrica? Secondo me no...

chiedi alla Microsoft o alla Sun perché ora hanno puntato tutto su Microsoft .NET o su Java, che sono linguaggi (o nel caso di .NET, tecnologie) pseudo-compilati (e) ma particolarmente attenti al consumo delle risorse e orientati verso uno stile di programmazione pulita

appunto 1 - ehm... Python è meno esoso di risorse e anche leggermente più veloce di Java, se vogliamo. Se sotto gli aggiungi frameworks come Psycho diventa MOLTO più veloce di Java. Come ripeto: dovresti informarti meglio a riguardo.
appunto 2 - La programmazione di Python è pulita, molto più pulita di Java ed enormemente più pulita di C/C++. Direi anzi che è il linguaggio più compatto e pulito attualmente in giro.

ad esempio, né l'uno né l'altro impongono l'uso di variabili a tipizzazione automatica, al massimo si può usare il tipo object e il late bound, ma è una pratica scoraggiata.

Come sopra: correnti religiose.

In quel problema Python andava ovviamente molto meglio come compattezza del codice, ma si tratta appunto di un mestiere da script, non da programma stand-alone. D'altra parte quel codice C non era un granché scritto bene (se non sbaglio c'è una funzione di libreria che consente di saltare tutti i caratteri di uno stream fino ad arrivare ad un delimitatore specificato), e la maggior parte del codice era dedicata alla gestione degli errori (completamente assente nello script Python).

Ancora? Ma allora sei de coccio! =)
Come puoi minimamente disquisire su questo aspetto? Stai cercando di far passare un linguaggio nato 15 anni fa, con tipizzazione dinamica e interpretato come "leggermente" più produttivo di uno nato quasi 40 anni fa, con tipizzazione statica e compilato, che per di più verboso e complesso lo è notoriamente!
Ma andiamo!
Vuoi che ti faccia vedere l'utilizzo delle socket in Python e poi confrontiamo lunghezza e chiarezza di codice del corrispettivo C?
Ti viene qualcosa che è minimo 5 volte più lungo e verboso (nonchè NON portabile da winsocket a socket berkley senza modificare il codice)!

[MItaly]

Originariamente inviato da billiejoex
Beh, che non serva a niente mi pare una affermazione azzardata, ma come al solito qui ci sono sempre differenti correnti religiose.
Che sia inutile non credo sia vero: serve, appunto, a migliorare il linguaggio in termini di produttività, ovvero quel parametro che fa scrivere al programmatore 5 righe di codice anzichè 20: esso non dovrà perdere tempo a dichiarare il tipo prima di assegnare un valore all'oggetto e potrà cambiare tipo di oggetto a runtime in qualunque momento. Ovvio che questo si paga in prestazioni ma è innegabile che il carico sul programmatore è minore (da qui ritengo abbastanza azzardata la tua affermazione).

A mio parere non è una gran perdita di tempo dichiarare il tipo di una variabile (quanto ci metti a digitare "int" o "float"?) e oltre agli aspetti già citati aggiungo che semplifica la lettura del codice da parte di terzi.

Anche il discorso degli errori è semmai mitigato dalla tipizzazione statica, non incoraggiato.

Perdonami, ma non ho capito la frase.

Non mi pare che linguaggi quali Python, Ruby e Java siano evitati in produzione.
Anzi, Java stesso è ormai da tutte le parti. In Java ci hanno fatto freenet,

Hai appena paragonato Java al C e al C++ in quanto a bassa produttività, mentre io nel mio post precedente l'ho difeso... ma forse ho capito male io .

in Python bittorrent e persino dei web server, giusto per dire.
Non credo che con un mero linguaggio di scripting tu riesca a sviluppare queste cose, ed è altrettanto errato catalogare Python come mero linguaggio di scripting.

Ok, in questo ti do ragione.

Accidenti che sforzo caricare l'interprete! Saranno si è no 3000 kb in memoria!
3000 KB+la memoria allocata dallo script contro i 1100 del mio programma compilato; sulla già citata macchina con 64 MB di RAM non è indifferente.
Su Windows 95 ci gira Office e tu vai a fare storie per un programma del genere? Ma andiamo...

Office=programma usato quando serve e quasi esclusivamente da solo (non ho mai visto nessuno scrivere una lettera mentre giocava a Quake ).
StopTime (il programma in questione)="pseudo-servizio" che è SEMPRE in esecuzione, e che non è il caso che rubi troppe risorse.
P.S.: in cosa è scritto Office? Non vorrei sbagliarmi, ma nei crash ho sempre visto degli "abnormal program termination" con sopra la scritta "C++ library"...

Sono d'accordo ma che efficienza vuoi pretendere da un programma come questo? Cercare di rendere un programma il più efficiente possibile è sicuramente un bene. Quando si cerca l'efficenza anche per stampare a video un 'hello world', però, mi sembra si esageri.

Appunto, il programma in questione non è un hello world.

Stiamo parlando di un programma che monitora e modifica l'ora, non di un password cracker che deve provare milioni di combinazioni al secondo.

Aggiungo che si tratta di un programma che quasi sempre è in attesa, per cui in realtà l'obiettivo non è tanto la velocità del codice, quanto la sua efficienza nel gestire le risorse; e sia nell'una sia nell'altra il C++ primeggia.

Mi pare evidente che tu creda che un interprete è qualcosa di simile ad un Macromedia Dreamweaver o ad un MS Office o un drago a tre teste che utilizza il computer. Beh... non è così.

Ho già detto quanto ne penso un po' più sopra.
P.S.: viva i draghi a tre teste.

Mi pare ovvio: in quel caso stavano sviluppando un sistema operativo che di natura deve essere ottimizzato al massimo.

Office, Firefox, Acrobat, ... sono sistemi operativi? E, ancora meglio: lo sai in che linguaggio è scritto l'interprete Python? In C (ho controllato scaricando il package dal loro sito)... chissà perché...

Ma mi dici cosa cambia se una applicazione come Messanger, giusto per dire, mi si avvia 0,1 secondi dopo se la sviluppo in Python, Ruby o Java? Ha senso usare Assembler per scrivere una rubrica? Secondo me no...

Non stiamo parlando di 0,1 secondi; scrivi un algoritmo di ordinamento (magari per la tua rubrica) in C o in qualunque linguaggio compilato e in un linguaggio interpretato (magari usando le tue variabili a tipizzazione automatica), quindi fai un bel benchmark, magari su 100'000 nominativi, e poi ne riparliamo.

appunto 1 - ehm... Python è meno esoso di risorse e anche leggermente più veloce di Java, se vogliamo. Se sotto gli aggiungi frameworks come Psycho diventa MOLTO più veloce di Java. Come ripeto: dovresti informarti meglio a riguardo.

Mi informerò.

appunto 2 - La programmazione di Python è pulita, molto più pulita di Java ed enormemente più pulita di C/C++. Direi anzi che è il linguaggio più compatto e pulito attualmente in giro.

Ti concedo che il C (e il C++) non sia pulitissimo, anche se a darne questa immagine è l'uso che ne fanno i programmatori: il compilatore "mangia" qualsiasi cosa come input, anche il codice più schifoso del mondo, e i programmatori abusano in maniera folle del precompilatore; tuttavia il Java è uno dei linguaggi più puliti che io conosca.

Come sopra: correnti religiose.

Concordo .

Ancora? Ma allora sei de coccio! =)

Lo so .

Come puoi minimamente disquisire su questo aspetto? Stai cercando di far passare un linguaggio nato 15 anni fa, con tipizzazione dinamica e interpretato come "leggermente" più produttivo di uno nato quasi 40 anni fa, con tipizzazione statica e compilato, che per di più verboso e complesso lo è notoriamente!

L'argomentazione non sta in piedi: non vedo assolutamente come la tipizzazione statica e il fatto che il linguaggio sia compilato e non interpretato possano essere considerati degli svantaggi (dal canto mio li vedo anzi come dei vantaggi). Posso darti invece ragione sul fatto che effettivamente un linguaggio più vecchio è certamente più complesso e più vicino al linguaggio macchina di un linguaggio più recente, e quindi per questo meno produttivo.
Tuttavia la maggiore vicinanza al linguaggio macchina ti consente di scrivere codice efficentissimo o risolvere problemi in altri linguaggi molto complessi in maniera molto più semplice (quante volte in VB avrei voluto poter operare direttamente sui puntatori!).

Vuoi che ti faccia vedere l'utilizzo delle socket in Python e poi confrontiamo lunghezza e chiarezza di codice del corrispettivo C?
Ti viene qualcosa che è minimo 5 volte più lungo e verboso (nonchè NON portabile da winsocket a socket berkley senza modificare il codice)!

Non ne dubito assolutamente, anzi ne sono certo. Resterà comunque codice meno efficiente, anche se con le connessioni di rete - notoriamente lente - l'efficienza del codice conta fino ad un certo punto.
Non credere infatti che io programmi solo in C/C++: di solito quando mi accingo a scrivere un programma o un'utility passo in rassegna i linguaggi che conosco, per trovare un compromesso tra comodità mia, efficienza del codice ed altre esigenze particolari (ad esempio, un programma che deve essere eseguito durante l'installazione di Windows non dovrà necessitare di runtimes in alcun modo). Se devo fare un uso massiccio di form, controlli "strani", connessioni di rete, richieste a server web e simili uso ad esempio .NET, per scrivere un'applet userò Java, per scrivere un'utility, un programma che fa uso massiccio di API, un programma che si dovrà integrare nel sistema (ad esempio un'estensione della shell, sfido chiunque a scriverla in tempi brevi con un altro linguaggio), un'applicazione "ultraleggera", una dll per un'altra applicazione che implementa in codice unmanaged e molto efficiente routines time-critical, userò il C++ (senza contare gli altri linguaggi che conosco, che però uso solo in casi particolari).

[billiejoex]

A mio parere non è una gran perdita di tempo dichiarare il tipo di una variabile (quanto ci metti a digitare "int" o "float"?) e oltre agli aspetti già citati aggiungo che semplifica la lettura del codice da parte di terzi.

Ok, non è una gran perdita di tempo, ma metti (esempio assurdo) che in un programma ci sono 50 variabili intere (dichiarazione int + assegnazione valore = 50 * 2 = 100 linee) e che ad un certo punto del programma tali variabili le devi trasformare da interi a stringhe (trasformazione char + assegnazione valore = 50 * 2 = 100 linee) fanno gia 200 linee.
Con la tipizzazione dinamica hai risparmiato gia 100 linee.
E' per questo che è assurdo e di parte affermare che la tipizzazione dinamica sia totalmente inutile: l'utilità c'è (a scapito di performance) ed è chiara come il sole, che poi non ti piaccia perchè non vuoi assolutamente perdere in performance è un altro paio di maniche.

Office=programma usato quando serve e quasi esclusivamente da solo (non ho mai visto nessuno scrivere una lettera mentre giocava a Quake ).
StopTime (il programma in questione)="pseudo-servizio" che è SEMPRE in esecuzione, e che non è il caso che rubi troppe risorse.

Secondo me non hai cognizione del fatto che:
* StopTime sia un programma quasi inconsistente che tu paragoni a qualcosa di simile ad Apache o ad un Exchange.
* Esistono centinaia di applicazioni utilizzate in produzione (sto parlando di SERVER, aka servizi, aka processi che stanno SEMPRE attivi) che non sono scritti in C/C++. Mi spieghi come mai? Sono quelle aziende che non capiscono nulla di informatica o sei tu che, forse, non hai ben capito che un linguaggio non deve essere il più veloce possibile ma semplicemente sufficientemente veloce a seconda del compito che deve espletare?

P.S.: in cosa è scritto Office? Non vorrei sbagliarmi, ma nei crash ho sempre visto degli "abnormal program termination" con sopra la scritta "C++ library"...

Ma che vuol dire "in cosa è scritto Office"? E' ovvio che con un linguaggio di più basso livello ottieni software più performanti! Ma è altrettanto vero che un programmatore deve fare una fatica immensamente maggiore! C'è sempre un compromesso, un pro e un contro, un bianco e un nero!
Quello che mi pare evidente ti sfugga è che ci sono linguaggi appropriati a seconda dei compiti. Se tutti ragionassero come te, allora, si scriverebbe solo più in asm...

Appunto, il programma in questione non è un hello world.

Ahahahah. No, infatti. E' un programma che monitora l'ora e la cambia! Accidenti! Era dall'epoca di Norton AV che non si vedeva un software così pesante!
Ma se un altro po' persino il task manager si rifiuta di listarne il processo, tanto è ridicolo! =)

Aggiungo che si tratta di un programma che quasi sempre è in attesa, per cui in realtà l'obiettivo non è tanto la velocità del codice, quanto la sua efficienza nel gestire le risorse; e sia nell'una sia nell'altra il C++ primeggia.

Beh potevi inserire direttamente gli I e O nel processore, gia che c'eri...
Così si che veniva veramente ottimizzato il tuo StopTime!

Office, Firefox, Acrobat, ... sono sistemi operativi?

...

E, ancora meglio: lo sai in che linguaggio è scritto l'interprete Python? In C (ho controllato scaricando il package dal loro sito)... chissà perché...

Io lo so da circa un anno in cosa è scritto. Sei tu che l'hai scoperto circa 10 minuti fa e questo la dice lunga riguardo quanto tu ne sappia di questo fantomatico linguaggio che critichi tanto.

chissà perché

Mi pare evidente: performance al top. D'altronde è ovvio che se qualcuno si prefigge di creare una base su cui far girare un linguaggio ad alto livello lo fa in un linguaggio di livello più basso per far girare al meglio la struttura che sta sopra.

Non stiamo parlando di 0,1 secondi; scrivi un algoritmo di ordinamento (magari per la tua rubrica) in C o in qualunque linguaggio compilato e in un linguaggio interpretato (magari usando le tue variabili a tipizzazione automatica), quindi fai un bel benchmark, magari su 100'000 nominativi, e poi ne riparliamo.

Nella fase precedente allo sviluppo di un progetto, infatti, si effettua uno studio e si vede cosa dovrà fare il programma.
A seconda di questo si sceglie quale linguaggio è più appropriato. Mi ri-auto-quoto:
un linguaggio non deve essere il più veloce possibile ma sufficientemente veloce a seconda del compito che deve espletare.
Per come ragioni tu, ripeto, tutti dovrebbero scrivere in asm.

L'argomentazione non sta in piedi: non vedo assolutamente come la tipizzazione statica e il fatto che il linguaggio sia compilato e non interpretato possano essere considerati degli svantaggi

Non ho detto quello, leggi meglio: ho detto che tipizzazione statica, e compilazione diminuiscono la produttività del linguaggio (e per forza).

PS - SI potrebbe spostare la discussione in "Programmazione"? Ormai siamo OT^10!